Error Identification (WCAG 3.3.1)

What is it?

WCAG Success Criterion 3.3.1 (Error Identification) requires that 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. This means relying solely on color (red border) or icons (exclamation mark) to indicate errors is insufficient — text must be present.

Why it matters

Screen reader users may not perceive color changes or icons. Users with cognitive disabilities may not understand generic error symbols. Users with low vision may miss subtle visual cues. Text-based error messages that are specific and actionable ensure all users understand what went wrong and how to fix it. This is also a core usability principle beyond accessibility — good error messages help all users.

Best Practices

• Identify the specific field in error — "Email address is required" not just "Please correct the errors below."
• Explain what is wrong — "Password must be at least 8 characters" not just "Invalid password."
• Explain how to fix it — "Enter a date in MM/DD/YYYY format" when a date is wrong.
• Position error messages adjacent to the field they describe, not only at the top of the form.
• Use aria-describedby or aria-errormessage to programmatically associate error messages with their input fields.
• Set aria-invalid="true" on the input element when it is in an error state — screen readers announce this to users.
• Trigger validation on field blur for most errors, not just on submit — gives users earlier feedback.
• For form submission errors, move focus to the first error or to a summary at the top of the form that lists all errors.
• Do not remove error messages when the user begins re-entering data — keep them visible until the error is resolved.
• Use color AND text AND an icon for error states — never rely on any single channel alone.

Common Mistakes

• Red border only on error fields — the error is imperceptible to colorblind users and screen readers.
• Generic error messages: "An error occurred" or "Please correct the highlighted fields."
• Error summary at top of page with no association to specific fields.
• Error messages that disappear when user clicks into the field — leaves users with no guidance while correcting.
• No aria-invalid or aria-describedby on error fields — screen readers can't announce the error.
• Error messages in a font size or color with insufficient contrast.
• Validation only on form submit, not on blur — users complete the entire form before learning about errors in field 1.

Checklist

Research & Theory

Real-World Examples