Understanding WCAG 2.0

Skip to Content (Press Enter)

-

Error Identification:
Understanding SC 3.3.1

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. (Level A)

Intent of this Success Criterion

The intent of this Success Criterion is to ensure that users are aware that an error has occurred and can determine what is wrong. The error message should be as specific as possible. In the case of an unsuccessful form submission, re-displaying the form and indicating the fields in error is insufficient for some users to perceive that an error has occurred. Screen reader users, for example, will not know there was an error until they encounter one of the indicators. They may abandon the form altogether before encountering the error indicator, thinking that the page simply is not functional. Per the definition in WCAG 2.0, an "input error" is information provided by the user that is not accepted. This includes:

For example:

Note: If a user enters a value that is too high or too low, and the coding on the page automatically changes that value to fall within the allowed range, the user's error would still need to be described to them as required by the success criterion. Such an error description telling the person of the changed value would meet both this success criterion (Error Identification) and Success Criterion 3.3.3 (Error Suggestion).

The identification and description of an error can be combined with programmatic information that user agents or assistive technologies can use to identify an error and provide error information to the user. For example, certain technologies can specify that the user's input must not fall outside a specific range, or that a form field is required. Currently, few technologies support this kind of programmatic information, but the Success Criterion does not require, nor prevent it.

It is perfectly acceptable to indicate the error in other ways such as image, color etc, in addition to the text description.

See also Understanding Success Criterion 3.3.3 Error Suggestion.

Specific Benefits of Success Criterion 3.3.1:

  • Providing information about input errors in text allows users who are blind or colorblind to perceive the fact that an error occurred.

  • This Success Criterion may help people with cognitive, language, and learning disabilities who have difficulty understanding the meaning represented by icons and other visual cues.

Examples of Success Criterion 3.3.1

Related Resources

Resources are for information purposes only, no endorsement implied.

(none currently documented)

Techniques and Failures for Success Criterion 3.3.1 - Error Identification

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this Success Criterion. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.

Sufficient Techniques

Instructions: Select the situation below that matches your content. Each situation includes techniques or combinations of techniques that are known and documented to be sufficient for that situation.

Situation A: If a form contains fields for which information from the user is mandatory.

  1. G83: Providing text descriptions to identify required fields that were not completed

  2. ARIA21: Using Aria-Invalid to Indicate An Error Field (ARIA)

  3. SCR18: Providing client-side validation and alert (Scripting)

  4. PDF5: Indicating required form controls in PDF forms (PDF)

  5. SL35: Using the Validation and ValidationSummary APIs to Implement Client Side Forms Validation in Silverlight (Silverlight)

Situation B: If information provided by the user is required to be in a specific data format or of certain values.

  1. ARIA18: Using aria-alertdialog to Identify Errors (ARIA)

  2. ARIA19: Using ARIA role=alert or Live Regions to Identify Errors (ARIA)

  3. ARIA21: Using Aria-Invalid to Indicate An Error Field (ARIA)

  4. G84: Providing a text description when the user provides information that is not in the list of allowed values

  5. G85: Providing a text description when user input falls outside the required format or values

  6. SCR18: Providing client-side validation and alert (Scripting)

  7. SCR32: Providing client-side validation and adding error text via the DOM (Scripting)

  8. FLASH12: Providing client-side validation and adding error text via the accessible description (Flash)

  9. PDF22: Indicating when user input falls outside the required format or values in PDF forms (PDF)

  10. SL35: Using the Validation and ValidationSummary APIs to Implement Client Side Forms Validation in Silverlight (Silverlight)

Additional Techniques (Advisory) for 3.3.1

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

Common Failures for SC 3.3.1

The following are common mistakes that are considered failures of Success Criterion 3.3.1 by the WCAG Working Group.

(No failures currently documented)

Key Terms

input error

information provided by the user that is not accepted

Note: This includes:

  1. Information that is required by the Web page but omitted by the user

  2. Information that is provided by the user but that falls outside the required data format or values