Understanding SC 3.3.1: Error Identification (Level A)
In Brief
- Goal
- Users know an error exists and what is wrong.
- What to do
- Provide descriptive notification of errors.
- Why it's important
- Flagging errors helps people with reduced sight and cognitive disabilities resolve them.
Success Criterion (SC)
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.
Intent
The intent of this success criterion is to ensure that users are aware that an error has occurred and can determine what is wrong. In the case of an unsuccessful form submission, it is not sufficient to only re-display the form without providing any hint that the submission failed. The error must be indicated in text. Whether or not an error message provides users with sufficient information about the nature of the error, and what they should do to correct it, is covered more specifically by 3.3.3 Error Suggestion.
An "input error" is information provided by the user that is not accepted. This includes:
- information that is required by the web page but omitted by the user, or
- information that is provided by the user but that falls outside the required data format or allowed values.
For example:
- the user fails to enter the proper abbreviation in a state, province, or region field;
- the user enters a state abbreviation that is not a valid state;
- the user enters a non existent zip or postal code;
- the user enters a birth date 2 years in the future;
- the user enters alphabetic characters or parentheses into their phone number field that only accepts numbers;
- the user enters a bid that is below the previous bid or the minimum bid increment.
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 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 this success criterion does not require, nor prevent it.
It is perfectly acceptable to indicate the error in other ways such as through the use of an image, color, or other visual indicator, in addition to the text description.
Note
This criterion does not mandate any particular way in which errors should be displayed. Depending on the situation, it may be more suitable for all errors to be listed at the start or before a form. In other cases, it may be more appropriate to show errors inline, with error messages next to the specific fields that are in error. Errors could also be listed in an alert, or dialog. This criterion does not cover which of these methods should be used - the only requirement is for errors to be presented to users in text or a text alternative.
See also 3.3.3: Error Suggestion.
Benefits
- Providing information about input errors in text allows users who are blind or color deficient (color blind) 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 specific reason why a form submission failed (in cases where this is not already made obvious by the nature of the form).
Examples
- Identifying errors in a form submission
-
An airline Web site offers a special promotion on discounted flights. The user is asked to complete a simple form that asks for personal information such as name, address, phone number, seating preference and e-mail address. If any of the fields of the form are either not completed or completed incorrectly, an alert is displayed notifying the user which field or fields were missing or incorrect.
Note
This success criterion does not mean that color or text styles cannot be used to indicate errors. It simply requires that errors also be identified using text.
- Providing multiple cues
- The user fails to fill in two fields on the form. In addition to describing the error and providing a unique character to make it easy to search for the fields, the fields are highlighted in yellow to make it easier to visually search for them as well.
Techniques
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
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.
- G83: Providing text descriptions to identify required fields that were not completed
- ARIA2: Identifying a required field with the aria-required property
- ARIA21: Using aria-invalid to Indicate An Error Field
- SCR18: Providing client-side validation and alert
- PDF5: Indicating required form controls in PDF forms
Situation B: If information provided by the user is required to be in a specific data format or of certain values.
- ARIA18: Using aria-alertdialog to Identify Errors
- ARIA19: Using ARIA role=alert or Live Regions to Identify Errors
- ARIA21: Using aria-invalid to Indicate An Error Field
- G84: Providing a text description when the user provides information that is not in the list of allowed values
- G85: Providing a text description when user input falls outside the required format or values
- SCR18: Providing client-side validation and alert
- SCR32: Providing client-side validation and adding error text via the DOM
- PDF22: Indicating when user input falls outside the required format or values in PDF forms
Advisory Techniques
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.
Key Terms
- assistive technology
hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements of users with disabilities that go beyond those offered by mainstream user agents
Note
functionality provided by assistive technology includes alternative presentations (e.g., as synthesized speech or magnified content), alternative input methods (e.g., voice), additional navigation or orientation mechanisms, and content transformations (e.g., to make tables more accessible).
Note
Assistive technologies often communicate data and messages with mainstream user agents by using and monitoring APIs.
Note
The distinction between mainstream user agents and assistive technologies is not absolute. Many mainstream user agents provide some features to assist individuals with disabilities. The basic difference is that mainstream user agents target broad and diverse audiences that usually include people with and without disabilities. Assistive technologies target narrowly defined populations of users with specific disabilities. The assistance provided by an assistive technology is more specific and appropriate to the needs of its target users. The mainstream user agent may provide important functionality to assistive technologies like retrieving Web content from program objects or parsing markup into identifiable bundles.
- screen magnifiers, and other visual reading assistants, which are used by people with visual, perceptual and physical print disabilities to change text font, size, spacing, color, synchronization with speech, etc. in order to improve the visual readability of rendered text and images;
- screen readers, which are used by people who are blind to read textual information through synthesized speech or braille;
- text-to-speech software, which is used by some people with cognitive, language, and learning disabilities to convert text into synthetic speech;
- speech recognition software, which may be used by people who have some physical disabilities;
- alternative keyboards, which are used by people with certain physical disabilities to simulate the keyboard (including alternate keyboards that use head pointers, single switches, sip/puff and other special input devices.);
- alternative pointing devices, which are used by people with certain physical disabilities to simulate mouse pointing and button activations.
- human language
language that is spoken, written or signed (through visual or tactile means) to communicate with humans
Note
See also sign language.
- input error
information provided by the user that is not accepted
Note
This includes:
- Information that is required by the Web page but omitted by the user
- Information that is provided by the user but that falls outside the required data format or values
- programmatically determined
determined by software from author-supplied data provided in a way that different user agents, including assistive technologies, can extract and present this information to users in different modalities
- sign language
a language using combinations of movements of the hands and arms, facial expressions, or body positions to convey meaning
- text
sequence of characters that can be programmatically determined, where the sequence is expressing something in human language
- user agent
any software that retrieves and presents Web content for users
- Web page
a non-embedded resource obtained from a single URI using HTTP plus any other resources that are used in the rendering or intended to be rendered together with it by a user agent
Note
Although any "other resources" would be rendered together with the primary resource, they would not necessarily be rendered simultaneously with each other.
Note
For the purposes of conformance with these guidelines, a resource must be "non-embedded" within the scope of conformance to be considered a Web page.
Test Rules
The following are Test Rules for certain aspects of this Success Criterion. It is not necessary to use these particular Test Rules to check for conformance with WCAG, but they are defined and approved test methods. For information on using Test Rules, see Understanding Test Rules for WCAG Success Criteria.