Users can move directly to an input in a few ways, for example by using the element list dialog, 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
Look at the form controls dialog JAWS + F5, find the input labelled “Reference number” and move directly to it.
When you move to the input, there should be a slight pause and then you will hear the hint and error messages.
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.