Overview of Error Identification
Purpose
When a form has been filled out incorrectly, an error message should be generated so that people can determine what is wrong. The message should be clear, concise, and specific. It should identify which required fields were not completed, and/or if any input fell outside of the required format for a given field. This can be done using client-side validation, with an alert dialog box pointing out the neglected fields. It can also be done using server-side validation, and redisplaying the form with errors identified.
Error messages should be announced in two ways:
- Visually, via text onscreen
- Programmatically, via site code
The latter ensures that a screen reader will immediately announce any errors. Without it, only people who can see the screen will immediately know that an error has been made. People who use screen readers may have to navigate through an entire page before finding the error message. They should receive the message immediately after submitting the form.
How to Test
- With a screen reader running, fill out a form, and deliberately leave a required field blank
- Make an input error on another field
- Submit the form
- If a text based error message isn’t visibly displayed OR if the screen reader does not read the visible error, then error notification is not announced by screen reader
- Navigate back to the required control that was left blank to see if error notification is not programmatically associated to the control with the error
- Navigate back to the required control that had the input error to see if error notification is not programmatically associated to the control with the error
- Refresh the page and with no errors visually present insure that the full page can be read without an error message is erroneously generated
Best Practices
- G83: Providing text descriptions to identify required fields that were not completed
- G84: Providing a text description when the user provides information that is not in the list of allowed values
- G85: Providing a text description when user input falls outside the required format or values
- G139: Creating a mechanism that allows users to jump to errors
- ARIA1: Using the aria-describedby property to provide a descriptive label for user interface controls
- ARIA18: Using aria-alertdialog to Identify Errors
Exceptions
Design option is to not enable a “Submit” button until all form controls have valid entries. This removes the requirement to have a error message announced but still requires form controls to express their invalid state if an error was identified.
References
Understanding Success Criterion 3.3.1 Error Identification