Labels or Instructions:
Understanding SC 3.3.2
Intent of this Success Criterion
The intent of this Success Criterion is to help users avoid making mistakes when their input is required. To help avoid mistakes it is good user interface design to provide simple instructions and cues for entering information. Some users with disabilities may be more likely to make mistakes than users without disabilities or recovery from mistakes may be more difficult, making mistake avoidance an important strategy for users with disabilities. People with disabilities rely on well documented forms and procedures to interact with a page. Blind users need to know exactly what information should be entered into form fields and what the available choices are. Simple instructions visually connected to form controls can assist users with cognitive disabilities or those accessing a page using a screen magnifier.
The intent of this Success Criterion is not to clutter the page with unnecessary information but to provide important cues and instructions that will benefit people with disabilities. Too much information or instruction can be just as much of a hindrance as too little. The goal is to make certain that enough information is provided for the user to accomplish the task without undue confusion or navigation.
Specific Benefits of Success Criterion 3.3.2:
Label elements associated with input elements insure that information about the input field is spoken by screen readers when the field receives focus.
Field labels located in close proximity to the associated field assist users of screen magnifiers because the field and label are more likely to visible within the magnified area of the page.
Providing examples of expected data formats help users with cognitive, language and learning disabilities to enter information correctly.
Clearly identifying required fields prevents a keyboard only user from submitting an incomplete form and having to navigate the redisplayed form to find the uncompleted field and provide the missing information.
Examples of Success Criterion 3.3.2
A field which requires the user to enter the two character abbreviation for a US state has a link next to it which will popup an alphabetized list of state names and the correct abbreviation.
A field for entering a date contains initial text which indicates the correct format for the date.
A field for entering a given name is clearly labeled with "Given Name" and the field for family name is labeled "Family Name" to avoid confusion over which name is requested.
A U.S. phone number separates the area code, exchange, and number into three fields. Parentheses surround the area code field, and a dash separates the exchange and number fields. While the punctuation provides visual clues to those familiar with the U.S. telephone number format, the punctuation is not sufficient to label the fields. The single "Phone number" label also cannot label all three fields. To address this, the three fields are grouped in a
fieldset
with thelegend
"Phone number". Visual labels for the fields (beyond the punctuation) cannot be provided in the design, so invisible labels are provided with the "title" attribute to each of the three fields. The value of this attribute for the three fields are, respectively, "Area Code", "Exchange", and "Number".
Related Resources
Resources are for information purposes only, no endorsement implied.
(none currently documented)
Techniques and Failures for Success Criterion 3.3.2 - Labels or Instructions
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. The techniques listed only satisfy the Success Criterion if all of the WCAG 2.0 conformance requirements have been met.
Sufficient Techniques
G131: Providing descriptive labels AND one of the following:
H44: Using label elements to associate text labels with form controls (HTML)
FLASH32: Using auto labeling to associate text labels with form controls (Flash)
FLASH29: Setting the label property for form components (Flash)
FLASH25: Labeling a form control by setting its accessible name (Flash)
H71: Providing a description for groups of form controls using fieldset and legend elements (HTML)
FLASH8: Adding a group name to the accessible name of a form control (Flash)
H65: Using the title attribute to identify form controls when the label element cannot be used (HTML)
G167: Using an adjacent button to label the purpose of a field
Note: The techniques at the end of the above list should be considered "last resort" and only used when the other techniques cannot be applied to the page. The earlier techniques are preferred because they increase accessibility to a wider user group.
Additional Techniques (Advisory) for 3.3.2
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.
ARIA1: Using the aria-describedby property to provide a descriptive label for input controls (ARIA)
ARIA2: Identifying required fields with the aria-required property (ARIA)
Providing linear form design and grouping similar items (future link)
Common Failures for SC 3.3.2
The following are common mistakes that are considered failures of Success Criterion 3.3.2 by the WCAG Working Group.
Key Terms
- label
text or other component with a text alternative that is presented to a user to identify a component within Web content
Note 1: A label is presented to all users whereas the name may be hidden and only exposed by assistive technology. In many (but not all) cases the name and the label are the same.
Note 2: The term label is not limited to the label element in HTML.