Error Identification and Suggestion

Error identification and suggestion encompasses two closely related WCAG 2.x success criteria: 3.3.1 Error Identification (Level A) and 3.3.3 Error Suggestion (Level AA). Together, they ensure that when users make mistakes in forms or other input contexts, the errors are detected and communicated in an accessible, understandable way — and that the system offers concrete guidance on how to fix them. These criteria are part of the broader Input Assistance guideline (Guideline 3.3), which aims to help all users avoid and correct mistakes.

At their core, these requirements recognize that everyone makes errors, and that the way a system handles those errors can either empower users to recover gracefully or leave them stranded. For people who use assistive technologies like screen readers, or for users with cognitive disabilities, vague or purely visual error indicators (such as a red border with no text explanation) are effectively invisible or meaningless. Proper error identification and suggestion bridges that gap by providing explicit, programmatically determinable error messages.

Why error identification and suggestion matters

Form errors are one of the most common friction points on the web. When an error occurs — a required field is left blank, an email address is malformed, a date is in the wrong format — users need to know three things: that an error occurred, where it occurred, and how to fix it.

Without accessible error handling:

• Screen reader users may never learn that a submission failed, especially if error messages are only conveyed through color changes or icons without text alternatives.
• Users with cognitive disabilities may struggle to understand what went wrong if the error message is generic (e.g., "Invalid input") rather than specific.
• Users with low vision may miss error indicators that rely solely on color (violating SC 1.4.1 Use of Color as well).
• Keyboard-only users may not be able to navigate to the error or the offending field efficiently.

Poorly handled errors increase abandonment rates for everyone and create outright barriers for people with disabilities. Accessible error handling improves usability universally while meeting legal and compliance requirements.

How error identification and suggestion works

Error identification (WCAG 3.3.1)

This Level A criterion 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. "In text" is the key phrase — the error must not be communicated solely through sensory characteristics like color, shape, or position.

The error message should be associated programmatically with the relevant form control so assistive technologies can announce it. Common techniques include using aria-describedby to link an error message element to its input, using aria-invalid="true" to mark the field as invalid, and using live regions or focus management to ensure the error is perceived immediately.

Error suggestion (WCAG 3.3.3)

This Level AA criterion goes further: if an input error is detected and suggestions for correction are known, those suggestions must be provided to the user — unless doing so would compromise security or the purpose of the content. For example, if a user enters "03/32/2024" in a date field, the system should not just say "Invalid date" but should suggest the expected format, such as "Please enter a valid date in MM/DD/YYYY format."

Combining both criteria effectively

In practice, the best implementations combine identification and suggestion into a single, clear message. They also use an error summary at the top of the form (often announced via role="alert" or by moving focus) alongside inline messages next to each problematic field.

Code examples

Bad example — error indicated only by color

<form>
  <label for="email">Email</label>
  <input type="text" id="email" name="email" style="border: 2px solid red;">
  <!-- No text error message, no aria-invalid, no suggestion -->
  <button type="submit">Submit</button>
</form>

Here the red border is the only error indicator. Screen reader users will not perceive it, and no user receives guidance on what went wrong or how to fix it.

Bad example — generic error with no suggestion

<form>
  <label for="phone">Phone number</label>
  <input type="text" id="phone" name="phone" value="abc">
  <span class="error">Invalid input.</span>
  <button type="submit">Submit</button>
</form>

The error text exists but is not programmatically associated with the input, the field is not marked as invalid, and "Invalid input" offers no suggestion for correction.

Good example — accessible error identification with suggestion

<form novalidate>
  <div>
    <label for="email">Email address</label>
    <input
      type="email"
      id="email"
      name="email"
      aria-invalid="true"
      aria-describedby="email-error"
      value="john@@example">
    <span id="email-error" class="error" role="alert">
      Error: The email address appears to contain a typo.
      Please enter a valid email, e.g. name@example.com.
    </span>
  </div>
  <button type="submit">Submit</button>
</form>

This version marks the input with aria-invalid="true", links the error text via aria-describedby, uses role="alert" so the message is announced by screen readers, and provides a specific suggestion with an example of the expected format.

Good example — error summary with inline messages

<form novalidate>
  <div role="alert" aria-labelledby="error-heading">
    <h2 id="error-heading">There are 2 errors in this form</h2>
    <ul>
      <li><a href="#name">Name is required.</a></li>
      <li><a href="#dob">Date of birth must be in MM/DD/YYYY format.</a></li>
    </ul>
  </div>

  <div>
    <label for="name">Name</label>
    <input
      type="text"
      id="name"
      name="name"
      aria-invalid="true"
      aria-describedby="name-error"
      value="">
    <span id="name-error" class="error">Please enter your full name.</span>
  </div>

  <div>
    <label for="dob">Date of birth</label>
    <input
      type="text"
      id="dob"
      name="dob"
      aria-invalid="true"
      aria-describedby="dob-error"
      value="13/45/2024">
    <span id="dob-error" class="error">
      Please enter a valid date in MM/DD/YYYY format, e.g. 01/15/1990.
    </span>
  </div>

  <button type="submit">Submit</button>
</form>

This pattern presents a summary of all errors at the top with anchor links to each problematic field, while each field also has its own inline error message with a clear suggestion. Moving focus to the error summary on submission ensures sighted and assistive technology users alike are immediately aware that errors need attention.