What 3.3.1 requires
If an input error is automatically detected, the item in error must be identified and the error described to the user in text. A red border or an icon alone isn't enough. There needs to be a text message, and it has to be clear which field it's about. This is a plain-language summary. The normative text, including every exception, is in the W3C Recommendation, with the W3C's explanation in Understanding 3.3.1 (opens in a new tab) [1][2].
Exceptions and scope:
- Applies only to errors detected automatically (client-side or server-side validation). It doesn't require detecting errors the system can't know about.
Why it matters
A failed submit that only turns a border red tells a screen-reader user nothing, and if focus stays on the submit button and nothing is announced, the page sounds exactly the same as before. People abandon forms here, and on a checkout that means a lost order.
Common failures
Error shown only by color
The field turns red; no text explains why.
<!-- Fails -->
<input class="is-invalid">
<!-- Better -->
<input aria-invalid="true" aria-describedby="zip-err"> <p id="zip-err">Enter a 5-digit ZIP code</p>Error text not associated with the field
The message sits nearby but isn't announced with the field.
<!-- Fails -->
<input id="zip"> <p class="err">Invalid</p>
<!-- Better -->
connect it with aria-describedby, as aboveErrors that appear silently
A summary appears at the top of the form; focus stays on the button and nothing is announced.
/* Fails */
summary.hidden = false;
/* Better */
summary.hidden = false; summary.focus(); /* summary has tabindex="-1" and a heading */Generic messages
"Invalid input" names a failure without saying what's wrong (3.3.3 Error Suggestion covers the fix).
<!-- Fails -->
<p>Invalid input</p>
<!-- Better -->
<p>Card number must be 16 digits</p>Can automated testing check 3.3.1?
No. Errors only exist after someone submits the form with a mistake, which a page scan never does.
| axe-core 4.13.0 rule | What it checks |
|---|---|
| (none mapped) | axe-core maps no rules to 3.3.1 |
What automation can't decide: Everything: whether errors are shown in text, tied to the field, announced, and clear. All of it only appears after an interaction.
A clean automated result is never proof that 3.3.1 is met. See why sites pass axe-core but fail real screen reader users.
How to test it by hand
- Submit each form empty, then with deliberately wrong values (bad email, short card number, past date).
- Check every error is described in text, not only by color or an icon.
- With a screen reader, listen after submit: is the error (or an error summary) announced? Where did focus go?
- Move back to each field in error and check its error message is announced with it.
- Repeat for inline validation that fires as you type or leave a field.
New to screen readers? Start with how to test a website with a screen reader and how to test keyboard-only navigation.
How Accessible helps (and where it stops)
Journeys fill forms keyboard-only with the test values you provide, including wrong ones. After every submit they check what was announced, where focus went and whether errors are tied to their fields, and they report the step where the task couldn't continue. Our form-accessibility page lists errors that aren't tied to the field and errors nobody hears as found by journeys. The assistant tools form-fields check flags errors with no message on one page.
Where it stops: A journey tests the forms and wrong values in your journeys. It won't invent every possible error state, and whether a message is genuinely helpful is a human judgment. No automated tool, ours included, can certify that a criterion is met.
Related criteria
- 3.3.2 Labels or Instructions
- 1.3.1 Info and Relationships
- 4.1.2 Name, Role, Value
- WCAG 2.2 success criteria checklist
Sources
- Understanding Success Criterion 3.3.1: Error Identification (opens in a new tab). W3C Web Accessibility Initiative. Accessed October 18, 2026.
- Web Content Accessibility Guidelines (WCAG) 2.2, Success Criterion 3.3.1 (opens in a new tab). W3C Recommendation. Accessed October 18, 2026.
- axe-core rule descriptions (opens in a new tab). Deque Systems, axe-core 4.13.0. Accessed October 18, 2026.
- Form accessibility testing. Accessible. Accessed October 18, 2026.
Meeting a success criterion is not the same as legal compliance, which depends on the rules that apply to you. No automated tool can certify conformance.