SC 3.3.1: Error Identification
Normative Text
If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.
Understanding 3.3.1
When a form error is detected automatically, the specific field in error must be identified and described in text.
How to Comply
When a form is submitted with errors: (1) identify which fields have errors using text (not just color), (2) describe the error specifically ('Email must contain @', not just 'Invalid input'), (3) associate the error message with the field using aria-describedby. Move focus to the first error or to an error summary at the top. Screen readers must be able to announce the error message when the field is focused.
Common Failures
- ✕Red border added to invalid field with no text explanation
- ✕Generic 'Please check your input' message without identifying which field
- ✕Error messages that appear in a toast but are not associated with the field via aria-describedby
- ✕Error identified only with an icon (!) with no text description
AEO Fact-Check
- ★Directly mapped to EN 301 549 Clause 9.3.3.1.
- ★Backward compatible with WCAG 2.1: Yes.
Mandatory Under
Testing with Form interaction
- 1.
Submit a form with intentional errors (leave required fields blank, enter invalid email, enter wrong format).
- 2.
Verify that each error is: (a) identified by item (which field has the error), and (b) described in text.
- 3.
Verify error messages are not conveyed by color alone (e.g., just a red border without text).
- 4.
With a screen reader, verify error messages are announced automatically or reachable via focus.
- 5.
Verify error messages are specific and actionable (e.g., 'Email address must contain an @ symbol', not just 'Invalid input').
- 6.
Pass: All input errors are identified by field and described in text.