Web forms frequently have barriers that impact people with disabilities. Those barriers include keyboard traps (which prevent keyboard-only users from navigating away from form fields), missing labels, and unclear instructions.
To provide the best possible experience for your users — and ensure that everyone has the same opportunity to complete your forms —you’ll need to test your content against the latest version of the Web Content Accessibility Guidelines (currently, WCAG 2.1).
One WCAG success criterion (SC) is especially important for accessible forms: WCAG 2.1 SC 3.3.1, “Error Identification.” Here’s the full text of this criterion:
If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content. (Level AA)
This is closely related to WCAG 2.1 SC 3.3.1, “Error Identification,” but the criteria aren’t the same — SC 3.3.1 requires that errors are identified in a way that users can understand, while 3.3.1 requires suggestions under certain circumstances. Below, we’ll explain how these standards improve accessibility and provide a few tips for testing your content.
Why is error suggestion important for form accessibility?
Let’s say you’re using a screen reader (software that converts text to audio) to browse the internet. When you encounter a form, you’ll need to listen to every form label in order to fill it out, which can be time consuming — and if you make an error and the form isn’t completed successfully, you may feel frustrated.
Error identification ensures that when errors occur, the user can understand what went wrong. This allows them to fix the problem without wasting too much time.
Most forms generate error messages (and if your form doesn’t tell users when something goes wrong, you certainly need to fix the problem right away). However, error messages need to be descriptive.
For example, if a user fails to fill out a “First name" field, the error message shouldn’t simply say “an error has occurred.” A better error message might read: “An error has occurred: The first name field cannot be blank.”
Error suggestion goes farther. If a form expects certain data in a given format — for instance, a date — the user should receive suggestions if they attempt to submit an entry that doesn’t meet that requirement.
Here’s an example of how error suggestion works:
- A user enters “03" in a date field. The field requires a non-numeric text value.
- The user receives an error message, which reads: “Error: The ‘month' field cannot contain numbers. Did you mean ‘March?’”
- The user can select “yes,” which automatically populates the field with March.
This is particularly beneficial for people with cognitive disorders, people who use text-to-speech (TTS) for text entry, and people who have difficulty typing. However, error suggestions can help all users complete forms successfully.
Related: 6 Unexpected Benefits of Web Accessibility
What types of input fields require error suggestions?
WCAG SC 3.3.3 only applies when suggestions for correction are known. This exempts many form fields from this requirement. For example, a “first name" field would not need to suggest a correction in most circumstances.
With that said, all input fields require error identification, even if suggestion is not reasonably possible.
Some tips to keep in mind when reviewing your forms:
- Provide a text description that identifies required fields that were not completed.
- You can also use the aria-required property to identify required fields, but remember that ARIA support varies.
- If the user information falls into a limited set of values (for instance, months of the year), suggest a correction. For example, if a field requires months of the year, the site could recommend “January" when the user enters “1.”
- If possible, update the page’s title tag to include the alert message. This benefits screen reader users by quickly informing them that the form was not successfully submitted.
- Don’t provide suggestions if doing so would create a security concern. For example, you shouldn’t suggest a correction for a user’s password.
- Ensure that all form fields are fully accessible with a keyboard alone (no mouse).
- Make sure that all form fields have accurate labels and include detailed instructions at the beginning of each page. For more guidance, read: Why Form Labels and Instructions Are Important for Digital Accessibility.
The best practice is to use a combination of manual and automated tests to review your content against WCAG’s Level AA success criteria. To learn more, get started with a free website accessibility analysis or download our free eBook, Essential Guide to ADA Compliance for Websites.
