SC 3.3.1 Error Identification
Clearly identify and describe input errors when they are automatically detected.
- Requirement: When an error occurs (e.g., in a form), the system must explicitly identify the field in error and provide a text-based description explaining the mistake.
- Accessibility: Error messages should be specific and actionable. They can be supplemented with color, icons, or programmatic cues (like ARIA live regions) to ensure assistive technologies can communicate the issue to the user.
- Navigation: Ideally, provide a way for users to navigate directly to the erroneous field from the error message (e.g., a “Correct this now” link/button).
- Best Practice: Ensure error descriptions offer clear guidance on how to fix the issue (e.g., listing valid characters for a password rather than just stating an input is invalid).
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.
SC 3.3.1 Error Identification supports WCAG Principle 3 - Understandable because it requires Web pages to identify errors when they are automatically detected and make users aware that an error has occurred. The error message should be as specific as possible. This SC impacts users who are without vision, without perception of color and with limited language, cognitive, and learning abilities.
This SC allows the use of color, images, and text style in addition to text messages to identify and describe errors (assuming that the use of color and non-text also conform to other applicable SC requirements). The identification and description of an error can also be combined with programmatic information to allow assistive technologies (AT) to identify and describe an error to the user.
For example, a user may be required to create a password that only allows use of a particular set of special characters, but must include at least one of those special characters (such as !, $, %, or &). If the user types @ as part of a password, an error message that meets SC 3.3.1 Error Identification could use one of the following:
- An error message that uses details provided by the user: _“@ is not permitted as a special character.” _
- An error message that uses information from the program requirements. “Only the following special characters can be used to create your password: !, $, %, or &.”
SC 3.3.1 Error Identification also allows the use programmatic information about an error’s location specifically to assist users of AT by providing a way to navigate directly to the error from the message. An example might be providing a button labeled “Correct this now” in the error message, which would bring the user directly to the field that needs to be changed.
Impact of Nonconformance with SC 3.3.1 Error Identification
| Type of Disability | Description of Impact |
|---|---|
| 302.1 Without Vision | Users who are blind cannot use a mouse to interact with electronic content and typically use an assistive technology, such as a screen reader, to get audible or other alternative output for the information represented visually. To be able to navigate the content, understand its structure and relationships, and understand the meaning of content represented in graphics and images, the content must provide textual and programmatic cues in addition to the content presented purely visually. |
| 302.2 With Limited Vision | Users with limited vision may have widely different visual perception. Individuals with limited vision may or may not use assistive technologies. Therefore, in addition to textual and programmatic cues necessary for assistive technologies, ICT must also present content consistently and predictably. Users who view content with magnifiers may not pick up alerts, warnings, or other content if such content is presented outside of a consistent and predictable navigation pattern or if the content is not itself viewable at large magnification. Content that becomes distorted when magnified can also prevent some users with limited vision from being able to understand or interact with the content. |
| 302.3 Without Perception of Color | Some users may not be able to perceive differences between certain colors, and therefore do not receive information conveyed by the colors (e.g., using gradients of color between red, yellow, and green to indicate an item’s status from poor to good). In such cases, ICT must provide additional information by alternative means that conveys the same meaning (e.g., shapes and/or textual labels in addition to the color). |
| 302.9 With Limited Language, Cognitive, and Learning Abilities | Some users require more time than average to process information while others may find complicated instructions difficult to follow. Furthermore, some ICT content can distract or overwhelm users, preventing them from being able to interact with or understand other ICT content. Designers and developers of ICT must consider a broad range of cognitive abilities in order to provide ICT that is simple and easy to use. |
Applicability of Success Criteria 3.3.1 Error Identification
| Technology | Applicability of SC 3.3.1 Error Identification |
|---|---|
| Web | Web developers can use various methods for identifying errors, including alerts or dialogs, ARIA Live Regions, and/or sending focus to on-screen text describing the error. |
| Software | Software developers can use various methods for identifying errors, including alerts, dialogs, and/or sending focus to on-screen text describing the error. |
| Office documents | It can be difficult to create accessible forms in Office documents. The MS Word 2013 Basic Authoring and Testing Guide from the Accessible Electronic Documents Community of Practice instructs content authors to avoid creating forms in MS Word 2013 entirely. Nevertheless, content authors might use macros to create alerts and dialogs in addition to data validation alerts available in some Office applications. |
| PDF documents | Depending on the authoring tool, PDF form developers may use form field validation alerts to identify field formatting errors. Such validation and other error identification based on more complicated calculations rely on built-in or embedded scripts to identify errors. Again, depending on the authoring tool, alert messages provide mixed results with regard to accessibility. Therefore, PDF form developers must ensure that the error messages and/or on-screen text used to identify errors is accessible. |
| Mobile Native | Mobile-native software developers can use various methods for identifying errors, including alerts, dialogs, and/or sending focus to on-screen text describing the error. |