When users make a mistake, they need to know that an error occurred and what went wrong. Preventing an action or reloading a form without explanation forces users to guess—and guessing is not accessible.
For people who are blind, have low vision, use screen readers, or have cognitive or learning disabilities, unidentified errors can completely block task completion. WCAG requires that input errors be clearly identified and described in text whenever the system detects them.
WCAG Success Criterion
3.3.1 Error Identification (Level A)
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.
This is a Level A requirement. Failure can prevent users from completing basic tasks such as submitting forms, signing up, or making payments.
What WCAG Means by “Input Error”
An input error occurs when the user provides information that does not meet the system’s rules, including:
- Required information is missing
- The value is in the wrong format
- The value is outside the allowed limits
Examples include:
- Leaving a required field empty
- Entering an invalid email address
- Using letters in a numeric-only field
- Selecting a date that is not allowed
If the system can detect the problem automatically, it must also tell the user about it.
What “Automatically Detected” Means
“Automatically detected” means the system itself notices the error, during submission or validation, not when a human reviews the data later.
This includes:
- Client-side validation
- Server-side validation
- Auto-correction of values
It does not include:
- Manual moderation
- Human review after submission
If the system reacts to the input, it must also explain the problem.
Plain-Language Requirement
When an error occurs:
- Users must be told that an error exists
- Users must be told which input is wrong
- Users must be told what the problem is
This information must be available at the moment the error occurs.
It is not enough to:
- Block submission silently
- Reload the form with no explanation
- Highlight fields using colour alone
- Show icons without text
What “Text” Means in This Criterion
For Error Identification, “text” means information that users—and assistive technologies—can actually read.
This includes:
- Visible text on the page
- Text exposed to assistive technologies (for example, error messages announced by screen readers)
This does not include:
- Color alone
- Icons alone
- Visual styling without readable text
An error can be reinforced visually, but text must always be present.
Programmatic Association
It is not enough for the error text to exist. Assistive technologies must also know which field the error belongs to.
Think of it as a connection:
- The input field
- The error message
- A link between them
When this connection exists:
- Screen readers announce the error when the field is focused
- Users immediately know what needs attention
When it does not:
- Users hear an error message with no context
- They must hunt through the form to guess which field is wrong
This connection is what WCAG means by programmatic association.
Example: Failing vs Passing Error Identification
Failing Example
- The email field is outlined in red
- No error message is shown
- Submission is blocked
Result:
- Screen reader users are not told what went wrong
- Colour-only users may not perceive the error
- The criterion fails
Passing Example
- An error message appears:
“Enter a valid email address.” - The message is connected to the email field
- Focus moves to or remains on the invalid field
Result:
- Screen readers announce both the field and the error
- Users know exactly what is wrong
- The criterion passes
What Assistive Technologies Do in Practice
When errors are correctly identified and associated, screen readers typically announce something like: “Email address, invalid. Error: Enter a valid email address.”
If the association is missing, users may only hear: “Error. Enter a valid email address.” with no indication of where the problem is.
Multiple Errors: Conformance vs Usability
WCAG 3.3.1 allows errors to be revealed one at a time. This can technically conform.
However:
- Requiring repeated submissions to uncover each error creates frustration
- Users may abandon the task entirely
Best practice is to allow users to discover all errors without trial and error, even though this goes beyond minimum conformance.
Native Browser Validation: Allowed but Limited
Native HTML validation can meet this criterion because:
- Errors are shown in text
- Focus moves to the invalid field
- Screen readers often announce the error
However, common limitations include:
- Generic messages
- Small, non-scalable text
- Only one error exposed at a time
- Messages that disappear or are hard to revisit
Because of this, native validation often meets minimum conformance but not good usability.
Common Failure Patterns
Teams often fail this criterion by assuming:
- A red outline is enough
- The error is visually obvious
- The browser handles accessibility automatically
- Auto-correcting input does not need explanation
If users are not explicitly told what went wrong, the criterion is not met.
How to Test
- Submit a form with missing or invalid data
- Confirm that:
- The error is described in text
- The specific field in error is identified
- Test using:
- Keyboard only
- A screen reader
- High zoom or magnification
If users must guess what went wrong, the criterion fails.
Rule Description
When a system detects an input error, users must be informed that an error occurred and told which input is invalid and why.
Wrapping Up
Error Identification removes guesswork at the moment users need clarity most.
Users should never have to wonder:
- Did something go wrong?
- Which field caused it?
- Why submission failed?
As a Level A requirement, WCAG 3.3.1 addresses one of the most fundamental barriers to task completion. Clear, timely error identification makes interactions recoverable, predictable, and usable, especially for users who cannot rely on visual cues alone.
