Hints and errors

Introduction to screen‐readers: Voiceover MacOS Edition

Users can move directly to an input in a few ways, for example by using the Rotor, clicking on a link in an error summary, or navigating by shortcut keys or even tabbing.

So if we have a hint or error message alongside that field we need to make sure they don't miss out on this important information. Just like labels these need to be programmatically tied to the input they refer to. We do this using the aria-describedby attribute.

Activity - how aria-describedby sounds

Use VO + Cmd + J to move directly to the input below.

When you move to the input, there should be a slight pause and then you will hear the hint and error messages.

This is 10 characters.
Error: Enter your reference number.

We relate hints and error messages by using the aria‐describedby attribute, passing it the id of the element it refers to. The order in which they are read out depends on the order the ids appear in the aria‐describedby attribute. It should be the order they are presented on screen.

Insight: Here the error message is being prefixed by the hidden content “Error:” for screen‐reader users as they might not be able to perceive the different visual styling.

For standalone inputs the aria is placed on the input itself. For grouped inputs the aria is placed on the fieldset.

Hints and error messages should not be added to the label itself as this will make the label too long (and hinder speech recognition selection) and in the case of error messages it will alter the accessible name of the input which is generally not desirable.

Once in a set of form fields, as users are likely to jump from field to field, any unassociated content which is placed between fields is likely to be missed. If you have content like this which is not an error or hint, it is best to place it before the form fields begin.

Key takeaway

Always associate hints and error messages with the relevant input so they are read out when the user moves to the input.

Next, links