Skip to main content
Understandable WCAG 3.3.1 62% fail

Error Identification

Errors must be described in text (not just color), placed near the field, and announce via aria-describedby + role='alert'. Specific and actionable: 'Enter a valid email' not 'Invalid input'.

In plain terms

When a form goes wrong, say clearly in words what the problem is and how to fix it — not just a red outline.

WCAG 3.3.1 (Level A) requires errors to be identified in text. WCAG 3.3.3 (Level AA) requires error suggestions when known. WCAG 3.3.4 (Level AA) requires error prevention for legal/financial actions.

Best practice: combine an error summary at the top of the form (with links to each field) with inline error messages next to each field, connected via aria-describedby.

Why this matters

This fails on 62% of homepages. When form errors are only indicated by a red border or color change, screen reader users and colorblind users miss them entirely. Vague error messages ("Invalid input") leave users guessing what went wrong.

How to detect

Quick check

Submit forms with empty required fields and invalid data. Are errors described in text? Are they near the relevant field? Do they announce to screen readers? Are they specific ("Enter a valid email" not just "Error")?

How to fix

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

<!-- Error summary at top of form -->
<div role="alert" aria-labelledby="error-heading" tabindex="-1">
  <h2 id="error-heading">2 errors found</h2>
  <ul>
    <li><a href="#email">Email address is invalid</a></li>
    <li><a href="#phone">Phone number is required</a></li>
  </ul>
</div>