WCAG 3.3.1 Error Identification is a Level A rule for forms. When your page automatically detects an input error, you must identify which item is in error and describe that error to the user in text. Catching a mistake silently — or marking it with color alone — does not count. The user has to be told, in words, what went wrong and where.
What 3.3.1 actually requires
The normative wording from the W3C is precise: “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.” Two obligations are bundled in that sentence, and you must satisfy both.
First, the item in error is identified — the user must tell which field failed, not just that “something” is wrong. Second, the error is described in text — a written message assistive technology can read, not a color swap or an icon.
An input error, as W3C defines it, is information the user supplied that your page does not accept: a required field left blank, or a value outside the format or range you allow. The Understanding document’s examples are concrete — a ZIP code that doesn’t exist, a birth date in the future, letters in a numbers-only field, or an auction bid below the minimum increment.
Two things 3.3.1 does not demand: it does not require you to validate as the user types — only to report the errors you do detect — and it does not require you to suggest a fix, which is the job of the stricter 3.3.3 Error Suggestion at Level AA. 3.3.1 is the floor: name the error, describe it, in text.
Who this affects
Error identification is overwhelmingly a problem for people who can’t rely on the visual cues sighted users take for granted:
- Blind screen reader users (NVDA, JAWS, VoiceOver) hear nothing from a red border or an exclamation icon. If the failure is conveyed only visually, they may submit, get bounced back, and never know why — or even that submission failed.
- Low-vision and colorblind users may not perceive a red highlight at all, so “errors are red” is invisible to a meaningful share of your visitors.
- People with cognitive and learning disabilities depend on a clear, specific text explanation. “There was a problem” is far harder to act on than “Phone number must be 10 digits.”
For all of these users, a quiet form is a dead end. The WebAIM Million report found 33.1% of form inputs on the top million home pages were not even properly labeled — a strong signal that error handling, which is harder than labeling, fails even more often.
This guide is informational, not legal advice. For your specific risk, consult a qualified attorney.
Concrete failures (and the fix)
These are the patterns we correct most often during remediation.
Failure 1 — Color-only error marking. The field turns red; no text appears. This is the classic 3.3.1 failure (it also breaks 1.4.1 Use of Color). W3C documents it as failure pattern F81: identifying errors with color or visual means alone.
Failure 2 — The form just redisplays. Submission bounces back with no message; the user is left guessing. W3C is explicit that “simply redisplaying a form without notification is insufficient.”
Failure 3 — A visible message the screen reader never reads. “Email is invalid” appears next to the field, but it isn’t linked to the input or in a live region — so a screen reader user tabbing through never hears it.
The fix links a real text message to the failed field and announces it. The W3C sufficient technique is ARIA21 (aria-invalid) combined with aria-describedby and a live region:
<label for="email">Email address (required)</label>
<input
id="email"
type="email"
aria-invalid="true"
aria-describedby="email-error">
<span id="email-error" class="field-error">
Enter a valid email address, e.g. name@example.com
</span>When validation runs, set aria-invalid="true", write the text into the aria-describedby target, and push a summary into a live region so the user is told an error occurred without searching for it:
<div role="alert" aria-live="assertive" id="form-status">
3 fields need attention. Email address is required.
</div>Two rules from the technique matter: keep aria-invalid unset or “false” until validation runs (don’t pre-mark fields as invalid), and put the description in text the screen reader can voice — not in a title tooltip or an image. A role="alert" region announces automatically the moment its content changes, which is what gets a blind user from “I pressed submit” to “I know what to fix.”
How to test for 3.3.1
You cannot confirm 3.3.1 by looking — you have to break the form and listen. Scanners catch the structural half (a missing aria-describedby, an empty error node) but never the experiential half (did the screen reader actually announce it?). The reliable workflow:
- Submit with deliberate errors — leave a required field blank and enter invalid data so validation fires.
- Listen with a screen reader. Turn on NVDA, JAWS, or VoiceOver and submit. You should be told an error happened, ideally via a
role="alert"region, without hunting for it. - Confirm each field is named in text. Every invalid field needs a visible, programmatically linked message — not just a red outline.
- Tab into a failed field and verify its error reads aloud through
aria-describedby. - Drop the page to grayscale. If you can’t tell which fields failed or why, you’re relying on color and you fail 3.3.1.
This pairing of tooling with hands-on testing is why thorough work combines an accessibility audit with manual screen reader passes — and why our accessible forms guide treats error handling as its own discipline.
Why this matters legally
Forms are where ADA web claims live. Lawsuits rarely begin on a homepage — they begin at the contact form, the checkout, or the appointment scheduler, because that’s where a real user gets blocked. According to UsableNet, over 4,000 ADA digital accessibility lawsuits were filed in 2024, with e-commerce sites representing 77% of them — and checkout is nothing but a chain of validated forms.
Error identification is also a favorite for plaintiff testers because it’s trivial to document: submit a malformed field, run a screen reader, record that nothing was announced. Courts and the DOJ point to WCAG 2.1 AA as the practical benchmark for an accessible site under ADA Title III, and the DOJ’s 2024 Title II rule formally adopted WCAG 2.1 AA as the technical standard for state and local government sites (ADA.gov web guidance). Since 3.3.1 sits at Level A — the most basic tier — a failure here is among the hardest to defend.
A note on shortcuts: the same UsableNet 2024 Year-End Report found more than 1,000 businesses were sued in 2024 despite running an accessibility widget. An overlay can’t fix 3.3.1, because the broken behavior is in your validation logic — the overlay never sees the moment your script rejects an input and fails to announce it. Curbcut is deliberately anti-overlay: we rewire the actual form code so the default experience announces every error in text, and can document that conformance in a VPAT.
Where 3.3.1 fits in the bigger picture
Error Identification is the second link in WCAG’s “Input Assistance” chain. 3.3.2 Labels or Instructions helps users understand a field before they fill it; 3.3.1 catches them when they get it wrong. Get it right and you’ve fixed one of the most common points of total failure on a website — the form that quietly refuses to work. If you’d rather not break every form by hand, start with a free scan and we’ll show you which error messages your assistive-technology users never hear — then fix them for you.