WCAG 2.1 · Level A · Understandable
WCAG 3.3.1 — Error Identification, explained with examples
When an input error is detected, the field in error and the description of the error must be conveyed in text. Color-only error states (red border) exclude users who cannot perceive the color. Text + ARIA association ensures every user knows what failed and why.
- Number
- 3.3.1
- Level
- A
- Principle
- Understandable
- Guideline
- 3.3 Input Assistance
Why this criterion exists
Color-only error states (red border) exclude users who cannot perceive the color. Text + ARIA association ensures every user knows what failed and why.
If you only remember one thing: when an input error is detected, the field in error and the description of the error must be conveyed in text. Everything else on this page is detail.
Who feels it when this fails
Accessibility criteria sometimes feel abstract until you see who pays the cost when a site ignores them. Error Identification affects:
Color-blind users
Screen reader users
Anyone in bright sunlight
How sites typically fail it
These are the patterns we see week after week. None are intentional — they are accidents of how teams build interfaces under deadline. Knowing the failure modes is the fastest path to writing them out of your component library.
Red border with no text message
Error message visible but not associated with the field
How to test for it
Submit a form with bad data; error must be in text and announced by AT.
Automated scanners catch this criterion most of the time, but never all of the time. Manual testing with the keyboard and a screen reader closes the gap.
A code fix you can copy
aria-invalid + aria-describedby + role="alert" combine to flag the field and announce the message.
The problem
<input type="email" class="border-red-500">The fix
<input type="email" id="email" aria-invalid="true" aria-describedby="email-err">
<p id="email-err" role="alert">Please enter a valid email address.</p>aria-invalid + aria-describedby + role="alert" combine to flag the field and announce the message.
Frequently asked questions
Does an inline error need to be near the field?
Proximity is not a WCAG requirement, but it is a usability one. The error message must be programmatically associated with the field via aria-describedby so a screen reader announces it when the user lands on the input. Placing the error immediately below the field serves sighted users reading in order; the aria-describedby serves AT users in forms mode.
What is the difference between role="alert" and role="status" for errors?
role="alert" maps to aria-live="assertive" — it interrupts whatever the screen reader is currently saying. Use it for errors that need immediate attention (form submit failed, payment declined). role="status" is polite and waits for the current utterance to finish. Use it for low-priority messages (auto-saved, coupon applied). Inline form errors should almost always be role="alert".
Is color-only error indication (red border) a 3.3.1 failure?
Yes. WCAG 3.3.1 requires that the field in error be identified in text. A red border change communicates the error only through color — which fails 1.4.1 (use of color) and indirectly fails 3.3.1 by providing no text identification of the error. An accessible error state uses color plus a text error message plus aria-invalid on the input.
Other Understandable criteria
3.1.1 Language of Page
Understandable · Level A
3.3.2 Labels or Instructions
Understandable · Level A
3.2.1 On Focus
Understandable · Level A
3.2.2 On Input
Understandable · Level A
All WCAG 2.1 criteria
Browse the full index by principle
Complete WCAG 2.1 guide
POUR principles, conformance levels, legal requirements
Find every accessibility issue on your site in 60 seconds.
Free public scan. No card. AI-generated fixes for every issue we find.