Glossary / Error identification
Error identification
Accessible error identification makes it clear that an error occurred, which field or action caused it, and how the user can recover. Error handling must work visually, through keyboard focus, and through the accessibility tree. A red border or icon alone is insufficient: provide text, associate the message with the relevant control, preserve user input, and avoid making users search for a hidden cause after submission.
What to know
- WCAG 3.3.1 Error Identification (A) requires an automatically detected input error to be identified and described in text.
- WCAG 3.3.3 Error Suggestion (AA) requires known correction suggestions unless they would jeopardize security or purpose; 3.3.4 Error Prevention (Legal, Financial, Data) adds review, confirmation, or reversibility for consequential submissions.
- Use native constraints where useful (
required,type=email,min,pattern) but provide understandable application-level messages; browser-native validation UI varies. - Mark invalid controls with
aria-invalid="true"when invalid and associate an error element viaaria-describedby. Avoid setting invalid before validation when it confuses users. - Provide an error summary near the form start for multiple errors, with links to fields. Focus it after failed submit if appropriate; inline messages should still identify each field.
- Live regions can announce asynchronously inserted errors, but should not produce duplicate or overwhelming announcements.
Example pattern
<label for="postal">Postal code</label>
<input id="postal" aria-invalid="true" aria-describedby="postal-hint postal-error">
<p id="postal-hint">Use the format 12345.</p>
<p id="postal-error">Enter a 5-digit postal code.</p>
Ensure error text is visible, specific, and actionable. Do not clear valid data, rely on color, or announce only “invalid input” without saying what is wrong. For server validation, map errors to stable field IDs and handle stale/duplicate submissions safely.
Interview questions
- What must an accessible validation error communicate? That an error occurred, which input is affected, what is wrong, and—when safe—how to correct it.
- How do inline errors and summaries complement each other? Inline text helps at the field; a summary gives overview and navigation after a failed submit.
- Should invalid fields receive focus? Focus the first error or summary based on the interaction; provide a coherent way to reach all errors and preserve context.
- Is
aria-invalidenough? No. It exposes state but does not explain the error or provide correction guidance. - What should happen after server-side validation fails? Preserve values, map messages to fields, expose errors, and let users correct and resubmit without losing context.