Category: WCAG Principles and Conformance

Error Identification

Also known as: WCAG Success Criterion 3.3.1, SC 3.3.1

Simply put

Error Identification is a web accessibility requirement stating that when a form or input field detects a mistake in what a user entered, the system should tell the user that an error occurred, point out which item is wrong, and describe the problem in text. This helps people, including those using assistive technology, understand what went wrong so they can fix it. It is one of the requirements in the Web Content Accessibility Guidelines (WCAG).

Formal definition

Error Identification is WCAG Success Criterion 3.3.1, a Level A criterion under Guideline 3.3 (Input Assistance). It 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. The intent is to ensure users are aware an error has occurred and can determine what is wrong; text-based identification supports users of assistive technology such as screen readers who may not perceive visual-only cues like color or icons. This criterion addresses automatically detected errors only and does not by itself require that errors be prevented, nor does it mandate correction suggestions (which are addressed by separate criteria such as 3.3.3 Error Suggestion). Meeting this criterion is one component of conformance and does not on its own guarantee an accessible experience or legal compliance; manual and assistive technology testing are generally required to verify effective error communication.

Why it matters

Forms are among the most common points of interaction on the web, and they are also where users are most likely to make mistakes. When an input error is detected but not clearly communicated, users can be left stranded, unable to determine what went wrong or how to proceed. This barrier is especially significant for people using assistive technology such as screen readers, who may not perceive visual-only cues like a red border or a warning icon. Error Identification (WCAG Success Criterion 3.3.1) helps ensure that when a mistake is automatically detected, the user is made aware of it, the specific item in error is identified, and the problem is described in text that assistive technology can convey.

The consequences of poor error communication are practical and often high-stakes. A user completing a job application, submitting a benefits form, making a purchase, or scheduling an appointment may abandon the task entirely if they cannot understand why a submission failed. Because this is a Level A criterion, it represents one of the most fundamental accessibility requirements, and failures here can undermine the usability of an otherwise functional interface.

Meeting SC 3.3.1 is one component of WCAG conformance, but it does not on its own guarantee an accessible experience or legal compliance. Automated tools can flag some issues, but confirming that errors are actually announced and understandable generally requires manual and assistive technology testing. This entry is informational and not legal advice; organizations should consult qualified counsel and current guidance for their specific obligations.

Who it's relevant to

Front-end and Web Developers

Developers implement the logic that detects input errors and surfaces them to users. To meet SC 3.3.1, they should ensure detected errors are identified at the relevant field and described in text that is programmatically available to assistive technology, rather than communicated through visual-only cues alone.

UX and Interaction Designers

Designers shape how error states are presented, including messaging, placement, and visual treatment. Designing clear, text-based error descriptions that identify the specific item in error supports both general usability and conformance with this Level A criterion.

Quality Assurance and Accessibility Testers

Because automated tools detect only a portion of issues, testers generally need to trigger form errors and verify through manual and assistive technology testing that each error is announced, the field in error is identifiable, and the description is conveyed in accessible text.

Compliance Officers and Accessibility Program Owners

Those responsible for accessibility programs should treat SC 3.3.1 as one component of overall WCAG conformance. Passing this criterion does not by itself guarantee an accessible experience or legal compliance, and specific obligations should be confirmed with qualified legal counsel and current guidance.

Inside Error Identification

Error Identification (WCAG 3.3.1)

A WCAG 2.0 Level A success criterion requiring that when an input error is automatically detected, the item in error is identified and the error is described to the user in text.

Automatic detection scope

The criterion applies to errors that the system can detect automatically, such as a required field left blank or data entered in an invalid format. It does not obligate detection of errors the system cannot programmatically recognize.

Identification of the item in error

Users must be able to determine which specific field or control caused the error, rather than receiving only a general failure notice.

Text description of the error

The error must be conveyed in text so it is available to assistive technologies, not communicated by color, icon, or visual position alone.

Relationship to related criteria

Error Identification works alongside other WCAG criteria such as Labels or Instructions (3.3.2, Level A) and Error Suggestion (3.3.3, Level AA), which address providing guidance and suggested corrections; those are distinct success criteria and should not be conflated with 3.3.1.

Common questions

Answers to the questions practitioners most commonly ask about Error Identification.

Does Error Identification require that error messages describe how to fix the problem?

No. WCAG Success Criterion 3.3.1 Error Identification (Level A) requires only that an input error is identified and described to the user in text when it is automatically detected. Guidance on how to correct the error is addressed by a separate criterion, Error Suggestion (3.3.3, Level AA). Conflating the two can lead teams to over- or under-scope their work. For that reason, meeting Error Identification alone does not necessarily satisfy the related suggestion criterion, and it does not on its own guarantee an accessible or usable error-handling experience.

Is showing a red border or color change enough to meet Error Identification?

Generally, no. Error Identification requires that the error be identified and described to the user in text. Relying solely on color or a visual style to indicate an error does not convey the information in text and may not be perceivable to users who cannot distinguish the visual cue or who rely on assistive technology. A text description of what went wrong is commonly needed. Keep in mind that this criterion addresses error identification specifically; other criteria address use of color and other aspects of an accessible experience.

Which fields does Error Identification apply to?

Error Identification applies where an input error is automatically detected. When the system detects that information the user submitted is not accepted, the item in error should be identified and the error described to the user in text. This commonly includes required fields left blank and entries that fall outside a required format or range, when those conditions are detected by the application.

How should errors be conveyed so assistive technology users are aware of them?

The criterion requires the error to be identified and described in text; how you associate and expose that text is an implementation choice. Common practices include placing a text description near or associated with the field in error and ensuring the description is programmatically available. Because automated testing detects only a portion of issues, verify with manual review and testing using assistive technologies such as screen readers to confirm users are actually informed of the error.

Can automated testing confirm that Error Identification is met?

Automated tools can help flag some issues, but they detect only a portion of potential problems and generally cannot confirm that an error is meaningfully described to the user in text. Confirming this criterion typically requires manual testing, including triggering the error conditions and checking that a clear text description is presented and available to assistive technology.

At what conformance level and WCAG version does Error Identification apply?

Error Identification (3.3.1) is a Level A success criterion, the most basic conformance level, and it is present in WCAG 2.0, 2.1, and 2.2. Level AA, which is the level most commonly cited as a target, includes Level A criteria as well, so organizations aiming for AA would generally need to meet this criterion. This entry describes the technical guideline; it is not legal advice, and whether and how a specific version or level applies to your organization can depend on regulation, agency guidance, or case law. Consult qualified legal counsel for your situation.

Common misconceptions

Error Identification requires the system to catch every possible mistake a user could make.

The criterion applies only to input errors that are automatically detected. It does not require detecting errors the system cannot programmatically recognize, though other design considerations may still be advisable.

Highlighting an errored field in red is sufficient to meet Error Identification.

The criterion requires that the error be identified and described in text. Relying on color or visual cues alone does not satisfy 3.3.1 and can fail users of assistive technology; a related consideration is WCAG's use of color guidance.

Meeting Error Identification means a form is fully accessible and legally compliant.

Conformance with a single success criterion does not guarantee an accessible experience or legal immunity. Automated checks detect only a portion of issues, and manual and assistive technology testing are needed. This is not legal advice.

Best practices

Provide error messages in text that both name the specific field in error and describe what went wrong, so the information is available to assistive technologies.

Do not rely on color, icons, or position alone to indicate an error; pair any visual cue with a programmatically available text description.

Programmatically associate error text with its corresponding field so screen reader users encounter the message in context.

Test error handling with manual review and assistive technologies, since automated tools detect only a portion of potential issues.

Consider related criteria such as Labels or Instructions (3.3.2) and Error Suggestion (3.3.3, added at Level AA) when designing forms, while keeping each success criterion distinct.

Consult current W3C guidance and, where legal exposure is a concern, qualified legal counsel, as requirements evolve through regulation and case law.