A Practical Guide to Error Identification and Suggestions
Telling people clearly which form fields have errors and what went wrong, and suggesting how to fix them where possible.
Marcus Adeyemi
At a glance
- WCAG 3.3.1 Error Identification, A errors are identified and described to the user in text
- WCAG 3.3.3 Error Suggestion, AA suggestions for correction are provided when known
- Color alone cannot be the only indicator of an error
- Association error messages should be programmatically linked to their fields
Why it matters
Why it matters: Errors shown only with a red outline are invisible to many users, and vague messages leave everyone guessing, so WCAG requires identification at level A and suggestions at level AA.
Best practice
- Describe each error in text next to the field
- Explain how to fix it, such as the expected date format
- Show an error summary at the top with links to fields
- Link messages to fields with aria-describedby
- Move focus to the summary after a failed submit
Common pitfalls
Watch out for:
- Red borders as the only error signal
- Messages such as invalid input
- Clearing the form after an error
- Errors announced only visually
When to call in a specialist
Bottom line Bring in help when forms have high abandonment, or when error handling differs across a product's forms.
Where this comes from
- W3C Web Accessibility Initiative — Understanding SC 3.3.1 Error Identification
- W3C Web Accessibility Initiative — Understanding SC 3.3.3 Error Suggestion
- GOV.UK Design System — Error summary
The figures and practices above come from the sources listed.
Working on something like this?
We take on Performance & Accessibility work for teams who want it done once, properly. Tell us what you are building and we will tell you honestly whether we are the right studio for it. Start a project.
Where to go next
Spotted something wrong? Report an error on this page. We correct on the page and say what changed.
