Level AWCAG 2.0

3.3.1 Error Identification

If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.

Last reviewed: September 9, 2026

Understanding 3.3.1

This criterion ensures users know exactly what went wrong when a form submission fails, so they can correct it. Without a clear text identification, screen reader users, people with cognitive disabilities, or anyone relying on assistive technology may never realize an error occurred, or which field caused it, especially if the only indicator is a color change or a bare icon.

How to Meet It

When validation fails, identify the specific field(s) in error using text (not color or an icon alone) and describe the problem in plain language (for example, "Email address is required"). Programmatically associate the error text with its field using aria-describedby, and set aria-invalid="true" on the offending field so assistive technology announces it.

Code Examples

INCORRECT

<input type="email" id="email" style="border-color:red" />
<!-- Only a color change indicates an error; no text description, no programmatic association -->

CORRECT

<label for="email">Email</label>
<input type="email" id="email" aria-invalid="true" aria-describedby="email-error" />
<p id="email-error" role="alert">Enter an email address in the format name@example.com.</p>

Frequently Asked Questions

Is a red border alone ever sufficient?

No. Color alone fails this criterion as well as 1.4.1 Use of Color. The field in error must be identified in text, and that text needs to be programmatically associated with the field, or otherwise exposed to assistive technology.

Related Success Criteria

3.3.2 Labels or Instructions 3.3.3 Error Suggestion 3.3.4 Error Prevention (Legal, Financial, Data)3.3.5 Help

Quick Facts

Criterion3.3.1
LevelA
IntroducedWCAG 2.0

Automate Compliance

AccessiSight automatically scans and identifies 3.3.1 issues in your codebase.

Try Scanner Free