Everyone makes mistakes. When completing a form, users need to know if they made a mistake, where it is, and how to fix it.
...
The following issues are always required to be addressed to ensure an accessible form validation approach.
Global Error Message
All users should be aware of the presence of errors. At minimum, a live region should provide a message indicating that there are errors. If possible, update the page’s <title> element to indicate there are errors on the page (e.g. change page title from “XXX” to "Form Errors - XXX"). The following image shows an example.
...
See the Validation Patterns section below for further discussion on when and how to provide this Global Error Message.
Error Message Design
Error messages should always appear along with the fields in error.
...
Do not place the error message above the field. Placing the error message above the field causes higher cognitive load for users. It can be easily confused with the label.
Error Message Text
Users just want to get whatever your form requires done. For most users, recent experiences with similar designs will influence their current choices with your design.
Users are best supported when your design is consistent with similar patterns found elsewhere on toronto.ca as well as the larger world wide web. Users may not understand why your form does not like whatever information they have provided. Error messages need to be concise, yet informative.
...
For more information on how to write clear error messages, see Error Message Guidelines.
Error Message Accessibility
To be accessible, an error message must be programmatically associated with the field in error using the aria-describedby attribute. This ensures that the screen reader will announce both the field label and the error message.
...
If possible, update the page’s <title> element to indicate there are errors on the page (e.g. change page title from “XXX” to "Form Errors - XXX").
Using aria-invalid
In addition to providing a visual means for users to identify and recover from form errors, the aria-invalid attribute must be used to provide this same information programmatically.
...
An example form pattern can be found at Using aria-invalid to identify failed fields.
Using aria-errormessage
In future, it is expected that accessible forms will be able to use the combination of aria-invalid with aria-errormessage to provide programmatically clear error message functionality without needing to use aria-describedby. This would allow using the aria-describedby property only for providing additional descriptive information about a form element. However, this technique is not (as of summer 2019) supported by all user agents. An example of this approach can be seen in this aria-errormessage CodePen.
...
The Validation upon submit (long form) approach is the most preferred because it supports the most users. Careful consideration must be used to determine the approach that is most appropriate for the design. This section will discuss each of these patterns and their expected behaviour.
Real-time inline validation
Using real-time inline validation is appropriate on short forms. Non-visual users will not be aware of the real-time validation as it occurs. They will only discover that a field is in error if they return focus to the field. For this reason, the real-time inline validation approach should be combined with a Global Error Message when the user activates the “Submit” button.
...
User interacts with form element and then moves focus to the next element.
Live inline validation is triggered.
If an error is present, a visible, informative, programmatically associated error message appears beneath the form element in error.
If the user returns to the form element in error:
Form element label and programmatically associated error message is announced on focus.
After user interacts with the form element and moves focus away again, old error message is removed
Live inline validation is re-triggered (see Step 3).
Client-side validation is triggered on activation of the Submit button.
If errors are present:
Global Error Message (with
role="alert") appears at the top of the forme.g., "There are errors in your form"
Visible, informative, programmatically associated error message(s) appears beneath each form element in error.
Focus is set to first field with an error.
Validation upon submit (short form)
This approach can be used on short forms that do not use real-time inline validation.
...
User interacts with form elements.
User activates Submit button.
Client-side validation is triggered.
If errors are present:
Global Error Message (with
role="alert") appears at the top of the forme.g., "There are errors in your form"
Visible, informative, programmatically associated error message(s) appears beneath each form element in error.
Focus is set to first field with an error.
Validation upon submit (long form)
This approach must be used on long and/or complex forms and can be used on any forms. This approach is the most preferred because it supports the most users.
...
User interacts with form elements.
User activates Submit button.
Client-side validation is triggered.
If errors are present:
Global Error Message, including a list of links to each form element in error, appears at the top of the form.
Message does not have
role="alert".Focus is set to the Global Error Message heading. Ensure message is announced.
e.g., "There are XXX errors in your form."
Resources
Crafting Error Messages:
Accessible Validation:
- WebAIM: Usable and Accessible Form Validation and Error Recovery
- W3C ARIA21: Using Aria-Invalid to Indicate An Error Field
Anchor errormsglist errormsglist
Error Message List:
| errormsglist | |
| errormsglist |
- Example 4: Listing errors in the W3C's tutorial on User Notifications for Forms
- "Errors on top" section of WebAIM's tutorial on Form Validation