3.3.1 Error Identification

WCAG 2.2 · 3.3.1 A Understandable

What it requires

If an input error is automatically detected, the item that is in error must be identified, and the error described to the user in text. Colour, an icon, or simply moving focus is not enough on its own — the message has to name what went wrong in words a person and assistive technology can read (for example, “Email address is required” rather than just a red border). This applies to any validation the page performs, whether on submit or in real time.

It does not require you to detect every possible mistake — only that, when your form does detect one, it is announced clearly in text.

  • Blind and low-vision users relying on screen readers, who cannot see a colour change or icon-only indicator.
  • Users with colour-vision deficiencies, for whom a red highlight alone carries no meaning.
  • Users with cognitive or learning disabilities, who need a plain, specific description of the problem and how to correct it.
  • Anyone who misses a subtle visual cue and is left unsure why a form would not submit.

How to detect it

Manual and tooling checks
Check What to look for
Manual review Submit the form with bad or missing data: is each error described in text, and is the specific field identified?
Keyboard Tab to a field with an error — is the message programmatically associated (e.g. via aria-describedby) so it is reachable?
Screen reader On error, is the message announced (via a live region or by moving focus to it) and not conveyed by colour or icon alone?
Zoom / reflow At 200% zoom, do error messages stay visible and adjacent to their fields?
Automated tools Tools like axe can flag missing aria-invalid or unassociated messages, but cannot judge whether wording is meaningful — manual testing is required.

How to fix it

  1. Detect errors and present a clear text message that names the field and the problem.
  2. Mark the failing control with aria-invalid="true" and link the message with aria-describedby.
  3. Make the message programmatically determinable — place it next to the field and expose it to assistive technology (a live region for dynamic validation).
  4. Avoid relying on colour or icons alone; pair every visual cue with text.
<label for="email">Email address</label>
<input id="email" type="email" name="email"
       aria-invalid="true" aria-describedby="email-error">
<p id="email-error" class="field-error">
  Enter a valid email address, e.g. name@example.com.
</p>

Copy-paste tests

Automated coverage

There is no fully automated axe-core rule that confirms error identification, so this criterion needs manual review using the console check and steps below.

Run this in the browser console

error-identification-audit.js 
// Read-only: surfaces likely error indicators for human review.
const suspects = [...document.querySelectorAll(
  '[aria-invalid="true"], .field-error, .error, [role="alert"], input:invalid, select:invalid, textarea:invalid'
)];
suspects.forEach(el => { el.style.outline = '2px solid magenta'; });
console.table(suspects.map(el => ({
  tag: el.tagName,
  text: (el.textContent || '').trim().slice(0, 80),
  describedby: el.getAttribute('aria-describedby') || ''
})));
console.log('Review each:', suspects);

What to check manually: confirm each error message names the field in text (not colour or icon alone) and clearly says how to fix it, and that programmatic errors above are wired to their field via aria-describedby.