Identifying the error for a field or that the form submission is failed is a critical part. The error validation can happen in various ways and in various stages. In some forms, as soon as the user fills in the data and navigates away from the field the validation is performed and the error message is displayed. In some forms the error validation happens only after the form is submitted.
In the second case where the validation happens after form submitting, sometimes the user is not even aware that the form submission failed as the focus still remines on the submit button. No alert is announced by the screen reader.
Even if the user is aware that the form submission is failed, it may so happen that the error messages either may display at the beginning of the form or at individual form fields. If the focus is moved persons with low vision will be clueless about the display of error messages.
How to fix it
In the first scenario where the error message is displayed immediately, use techniques to announce the error message as soon as it is displayed. Using ARIA role alerts and ARIA-live regions such messages can be informed to screen reader users.
In the second scenario where the messages are displayed after form submission, focus management (refer chapter 23) plays a vital role. Depending on how the error messages are displayed on the screen, focus should move to the most logical position of the page. It may be to the first field in error or the section where the error messages are stacked.
In any case, Associate the error message with the field using aria-describedby similar to an instruction. While navigating with the tab key of the keyboard, content that is not associated will not be announced by the screen readers.
Example:
<span id=“error1”>Date of birth cannot be a future date</span>
<label for=“dob”>Date Of Birth</label>
<input type=“text” id=“dob” aria-describedby=“error1” />