← All criteria

Understandable · Level A · 3.3.1

Error Identification

When a form submission is automatically detected to have an error, two things are required together: the specific field it's in has to be identified, and the error has to be described in actual text — not just implied by a red border or a color change.

  • Blind
  • Low vision
  • Color blindness
  • Cognitive

How to recognize it

Submit a form with a deliberate mistake — leave a required field empty, type an email address with no @ — and check whether any text anywhere says what's wrong and which field it's wrong in. The most common failure is a field that just turns red with no text at all: that's simultaneously a 3.3.1 failure (no text description exists) and a 1.4.1 failure (color is the only signal). A close second: a generic message like 'Please fix the errors below' with nothing identifying which specific fields are the problem, which is nearly useless on a form with more than two or three fields. A subtler one: aria-invalid="true" set on the field with no error text associated anywhere — aria-invalid correctly signals that a field has a problem, but says nothing about what the problem is, so it satisfies part of the requirement and not the other.

How to fix it

Do both things together, not just one: identify the specific field (visually, with proximity and an icon or border, and programmatically, with aria-invalid="true") and describe the actual error in text right next to that field, tied to it with aria-describedby so assistive technology announces the field and its error as one unit. Write the error text specifically enough to act on — 'Enter a valid email address' rather than 'Invalid' — and avoid a summary-only approach that never gets more specific than a field count. This connects directly to 4.1.3's exception for blocking form errors: move focus to the first invalid field after a failed submit, so the field and its inline error text land in view together, which solves both the discovery problem for screen reader users and the visibility problem for someone using high magnification.

Example

Avoid

<input type="email" style="border-color: red;">
<div class="alert">Please fix the errors below.</div>
<!-- no indication of which fields, or what's wrong with them -->
<input aria-invalid="true">
<!-- signals an error exists, but no text says what it is -->

Prefer

<label for="email">Email</label>
<input type="email" id="email" aria-invalid="true" aria-describedby="email-error" style="border-color: red;">
<p id="email-error">Enter a valid email address.</p>
<div role="alert">2 errors: <a href="#email">Email is invalid</a>, <a href="#password">Password is too short</a></div>
<input id="name" aria-invalid="true" aria-describedby="name-error">
<p id="name-error">Name is required.</p>

Resources

  • 4.1.3 Status Messages

    A passing, informational error count is a 4.1.3 status message. A blocking form-validation error that stops submission is this criterion's territory, and is commonly handled by moving focus to the first invalid field.

  • 1.4.1 Use of Color

    A field that only turns red with no text fails both at once: 1.4.1 because color is the only signal, 3.3.1 because there's no text description of the error at all.

  • 3.3.2 Labels or Instructions

    Preventive versus corrective: 3.3.2 is about giving someone enough information to fill a field in correctly the first time; this criterion is about what happens after they've already gotten it wrong.

  • 3.3.3 Error Suggestion

    This criterion only requires that an error be identified and described in text at all; 3.3.3 goes further and requires a specific correction suggestion when one is knowable and safe to give.