WCAG 3.3.1 — Error Identification

Missing Error Identification

What is this issue?

Missing error identification occurs when a form validation error is detected but the user is not clearly informed which field has an error and what the error is. WCAG Success Criterion 3.3.1 (Level A) requires that if an input error is automatically detected, the item in error is identified and the error is described to the user in text.

The most common failures include: forms that highlight error fields in red without any text explanation, error messages that appear at the top of the form without indicating which field is affected, generic messages like "Please fix the errors below" without specifying what the errors are, and validation that silently prevents form submission with no feedback at all.

Another frequent issue is relying solely on color to indicate errors -- a red border on the invalid field with no text message. This fails both WCAG 3.3.1 (no text description) and WCAG 1.4.1 (color as the only indicator). Users who are color-blind or using a monochrome display cannot see the red highlight, and screen reader users receive no error information at all.

Impact on users

When errors are not identified in text, screen reader users have no way to know which fields failed validation or why. They submitted the form, something went wrong, but the only feedback is a color change they cannot perceive. They must revisit every field, guess what might be wrong, and resubmit -- a process that may take multiple attempts.

Users with cognitive disabilities are particularly affected by vague error messages. "Please correct the errors" provides no actionable information. Without knowing what the error is and where it is, users with memory or attention difficulties may not be able to resolve it, leading to form abandonment.

For all users, poor error identification creates frustration and increases abandonment rates. Studies show that clear, specific, inline error messages significantly improve form completion rates compared to generic or invisible error feedback.

Code example

Before (non-compliant)

<!-- Error indicated only by color -->
<input type="email" value="invalid"
  style="border-color: red;">

<!-- Generic error message -->
<div class="error">
  Please fix the errors below.
</div>

<!-- No error feedback at all -->
<form onsubmit="if(!valid()) return false;">
  <input type="text" required>
  <button>Submit</button>
</form>

After (compliant)

<!-- Error identified with text and associated to field -->
<label for="email">Email address</label>
<input type="email" id="email" value="invalid"
  aria-invalid="true"
  aria-describedby="email-error">
<p id="email-error" class="error" role="alert">
  Please enter a valid email address (e.g. name@example.com).
</p>

<!-- Error summary with links to each field -->
<div role="alert">
  <h2>2 errors found:</h2>
  <ul>
    <li><a href="#email">Email: enter a valid address</a></li>
    <li><a href="#phone">Phone: include area code</a></li>
  </ul>
</div>

How Scrutia detects this issue

Scrutia submits forms with intentionally invalid data and monitors the page response. It checks whether error messages appear in text (not just color changes), whether each error identifies the specific field and describes the problem, and whether error messages are programmatically associated with their fields using aria-describedby or aria-errormessage. Fields with color-only error indication are flagged.

Check your site for this issue

Scrutia audits your site against WCAG criteria in minutes.

Free audit

Frequently Asked Questions

Is a red border enough to indicate an error?

No. A red border alone fails both WCAG 3.3.1 (error not described in text) and 1.4.1 (color as sole indicator). You must include a text message describing the error, and the message should be associated with the field using aria-describedby.

Should I use inline errors or an error summary?

Both are valuable. Inline errors next to each field provide immediate context. An error summary at the top of the form provides an overview and lets users jump to each error. For the best experience, use both.

How do I make errors accessible to screen readers?

Use aria-invalid="true" on the field, associate the error message using aria-describedby, and use role="alert" on the error container so screen readers announce it immediately. Move focus to the first error field or the error summary when the form is submitted.

Should errors appear on submit or on blur?

Both approaches are acceptable. On-blur validation provides faster feedback but can be disruptive. On-submit validation is less intrusive but delays feedback. The key is that errors must be clearly identified in text regardless of when they appear.

Does your site have this issue?

Scrutia scans your pages against WCAG success criteria and delivers actionable fixes. Results in 5 minutes.

Run a free audit