WCAG 3.3.1 Error Identification

Success Criterion 3.3.1 requires that when an input error is automatically detected, the item in error is identified and the error is described to the user in text. It's a Level A criterion under Guideline 3.3 (Input Assistance).

The two required elements

Identification — the user needs to know which field has the problem, not just that "something" went wrong somewhere on a long form.

Description in text — the nature of the error needs to be explained in text, not communicated through color or an icon alone (which would also risk violating 1.4.1 Use of Color).

Common failures

• A generic "Form submission failed" message with no indication of which field(s) caused it
• An error indicated only by a red border around the field, with no accompanying text explaining what's wrong
• An error message that appears visually near the field but isn't programmatically associated with it, so a screen reader user tabbing to the field doesn't hear the error at all

What good error identification looks like

<label for="email">Email</label>
<input
  type="email"
  id="email"
  aria-invalid="true"
  aria-describedby="email-error"
>
<p id="email-error" role="alert">
  Please enter a valid email address (e.g., name@example.com).
</p>

The aria-describedby connection ensures a screen reader announces the error message when the field receives focus, not just when it initially appears — critical for a user who tabs directly to the field after the page has already loaded or re-rendered.

Why this is usually a fully automatable check

Whether an error message exists in text form, and whether it's programmatically associated with its field, are both mechanically verifiable — a scanner can check for the presence of validation-error text and its association with the relevant input with high confidence, though judging whether the wording of the error is genuinely helpful (rather than just present) still benefits from human review.