3.3.1 Error Identification (Level A)
High-Level Description
This success criterion requires that when a user makes an input error, it is clearly identified and described to them in text. The aim is to ensure that users know what went wrong and where, so they can take steps to correct it.
Detailed Description
Applies to:
- All forms - login, sign-up, search, payment, and contact forms.
- Interactive processes requiring user input or decision-making.
This allows:
- Users to easily identify and correct mistakes.
- Assistive technologies to communicate what went wrong.
- A smoother, more inclusive experience for users who may struggle with memory, attention, or vision.
Indicators of Non-Compliance:
- A form submission fails but does not indicate which field is incorrect.
- Errors are shown only via color, icon, or visual styling.
- Screen readers are not informed of validation messages or error locations.
Real World Examples
Scenario | Non-Compliant | Compliant |
---|---|---|
Required field left blank | Page reloads, but no message shown. | "Email address is required" appears near the field. |
Incorrect format (e.g., phone) | Field highlights red, but no message appears. | "Please enter a valid phone number in the format (123) 456-7890”. |
Passwords dont match | Form clears with no explanation. | “Passwords do not match. Please re-enter.” |
Multiple form errors | No indication of errors or only shows one. | Each affected field displays a clear, readable message. |
Colour-only error indication | A field turns red, but screen reader users get no feedback. | Text message is present and focus moves to the first error automatically. |
Disability Impact
Disability Group | Without Compliance | With Compliance |
---|---|---|
Blind / Screen Reader Users | No verbal cue that an error occurred or where. | Clear text error read aloud with screen reader. |
Low Vision Users | Rely on colour or visual styling only. | Text message and visible error indicator help ensure understanding. |
Cognitive Disabilities | May not understand vague or missing error info. | Descriptive messages clarify next steps. |
Motor Impairments | Repeating tasks due to unclear errors wastes time and energy. | Accurate messages reduce unnecessary navigation or typing. |
Supporting Documentation
- WCAG 2.2 Success Criterion 3.3.1 - Error Identification
- G83 - Providing text descriptions to identify required fields
- ARIA Live Regions - Alerting users of dynamic changes or messages
Remediation Strategies
1 - Display Clear, Specific Error Messages Near the Problem Field
< label for="email" >Email< /label >
< input id="email" name="email" type="email" aria-describedby="emailError" >
< span id="emailError" class="error" >Please enter a valid email address.< /span >
2 - Avoid Colour-Only Indicators
Don’t rely solely on red borders or icons, always include a text explanation.
3 - Support Screen Reader Access to Errors
Use ARIA live regions or programmatic focus to alert screen reader users:
< div aria-live="assertive" >There was an error with your submission. Please correct the highlighted fields.< /div >
< div role="alert" >There was an error with your submission. Please correct the highlighted fields.< /div >
4 - Group and Summarise Multiple Errors
Consider placing a summary message at the top of the form in addition to inline messages.