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
01 / 05

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.

02 / 05

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
03 / 05

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
04 / 05

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.

05 / 05

A code fix you can copy

aria-invalid + aria-describedby + role="alert" combine to flag the field and announce the message.

The problem

HTML
<input type="email" class="border-red-500">

The fix

HTML
<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.

Find every accessibility issue on your site in 60 seconds.

Free public scan. No card. AI-generated fixes for every issue we find.