Labels or instructions are provided when content requires user input. (Level A)
The purpose of this checkpoint is to ensure that content contains unambiguous labels, input format examples, and instructions that enable users to avoid errors when input is required.
Instructions or labels may also specify data formats for fields especially if they are out of the customary formats or if there are specific rules for correct input. Content authors may also choose to make such instructions available to users only when an individual control has focus.
The intent of this checkpoint is not to clutter the content 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.
Refer to Understanding SC 3.3.2 for more information (external link to WCAG).
Review the General techniques as well as other tabs applicable to your technology. Prioritize the use of technology-specific techniques, and implement the General techniques as needed. You are always required to find, understand and implement accessible code techniques to meet the checkpoint. The documented techniques and supplements are not exhaustive; they illustrate acceptable ways to achieve the spirit of the checkpoint. If numbered, techniques are in order of preference, with recommended techniques listed first. Where used, IBM information that complements the WCAG techniques is indicated as supplemental.
Instructions: Item in this section represent a technique or combination of techniques deemed sufficient. Where numbered, techniques are ordered from most to least preferred. Ensure you review WCAG Common Failures to avoid development mistakes.
- G131: Providing descriptive labels IN COMBINATION with one or more of the following, appropriate for the circumstances:
- G89: Providing expected data format and example
- G184: Providing text instructions at the beginning of a form or set of fields that describes the necessary input
- G162: Positioning labels to maximize predictability of relationships
- G83: Providing text descriptions to identify required fields that were not completed
- G167: Using an adjacent button to label the purpose of a field
Instructions: In addition to the General techniques, any item in this section represents a technique or combination of techniques deemed sufficient. Using multiple techniques is encouraged, and techniques are ordered from most to least preferred. The first technique is strongly recommended for mandatory form fields.
- G131: Providing descriptive labels AND ARIA2: Identifying a required field with the
aria-requiredproperty (see G131 AND ARIA2 supplement)
- G131: Providing descriptive labels AND one or more of the following:
- H90: Indicating required form controls using
legend(see H90 supplement)
- ARIA1: Using the
aria-describedbyproperty to provide a descriptive label for user interface controls
- ARIA9: Using
aria-labelledbyto concatenate a label from several text nodes
- ARIA17: Using grouping roles to identify related form controls
- H90: Indicating required form controls using
- H44: Using label elements to associate text labels with form controls
- H71: Providing a description for groups of
- H65: Using the
titleattribute to identify
formcontrols when the
labelelement cannot be used
- Meeting G89: Providing expected data format and example by Using the WAI-ARIA alert role to provide text instructions for fields that require data in a specific format (supplement)
The following examples and comments provide additional information beyond that available in the WCAG techniques. Where items supplement existing WCAG techniques, they are numbered accordingly (e.g., H90).
G131: Providing descriptive labels AND ARIA2: Identifying a required field with the
The use of a visual indicator along with
aria-required on mandatory form fields is one of the few required techniques in the IBM checklist.
If a symbol (such as an asterisk) is used to indicated required fields, an explanation of its purpose must precede the form. This gives a clear indication to the sighted user which fields in the form are mandatory.
In addition, adding an
aria-required property to the
input element enables a screen reader to provide immediate feedback that a field is mandatory. When
aria-required is set to true, a screen reader announces "required" when the field receives focus.
<p>Note: [*]denotes mandatory field</p>
<label for="usrname">Login name: </label>
<input type="text" name="usrname" id="usrname" aria-required="true" />[*]
<input type="password" name="pwd" id="pwd" size="12" aria-required="true" />[*]
<input type="submit" value="Login" id="next_btn" name="next_btn" />
In order for the indicator for the required field to be programmatically associated, it must be positioned inside the
<label> tag. In the following example, although the First and Last Name labels will visually look identical, only the first name will be programmatically flagged as required, since the second "(required)" text falls outside the label tags.
<label>Last name:<label> (required)
If a symbol is used to indicated required fields, an explanation of its purpose must precede the form.
Using the WAI-ARIA
alert role to provide text instructions for fields that require data in a specific format
The WCAG guidance on labelling and instructions states "Content authors may also choose to make such instructions available to users only when the individual control has focus especially when instructions are long and verbose." In the following example, the social security input field uses an
onfocus event to expose a message that advises users to avoid adding dashes when entering a social security number.
<label for="ssn">SSN:</label><input type="text" id="ssn" onfocus="showMsg('Do not enter dashes in the social security number.');">
alert role to the
div container. The alert role causes “Do not enter dashes in the social security number” to be read to the user.
var msgContainer = document.createElement('div');
var msg = document.createTextNode(msg);
Instructions: In addition to the General techniques, the Mobile Native iOS techniques in this section represent a technique or combination of techniques deemed sufficient for meeting this checkpoint.
Software using standard iOS UI elements must have the label attribute set. This can be done through the development IDE or through API calls in code. Some UI elements have a default label value. Hint attributes should be provided when needed. A hint provides additional explanation to help the user understand the purpose of the control.
Custom widgets should programmatically implement the
accessibilityLabel method and return an appropriate label. They should likewise implement
accessibilityHint and return a localized hint. In the following code, a custom widget that allows the user to select the angle of rotation provides both a label and a hint.
return @"Adjusts the angle of rotation"; }
iOS UI elements must also set accessibility attribute to YES, either in the development IDE or through API calls in code:
Refer to the Accessibility Programming Guide for iOS for Apple's style instructions on creating good labels and hints.
A set of input controls may need instructions so that a VoiceOver user can provide the required information. One way to provide additional help text is to provide a help image button just before the controls. When activated, the button displays instructions on how to provide the requested information in the fields. The displayed help text is used by both sighted and VoiceOver users. If providing additional text for VoiceOver users is beneficial, a hint can be attached to the button. VoiceOver reads the hint text when the button receives focus. The hint text is not seen by sighted users.
[aButton setImage:[UIImage imageNamed:@";help.jpg"] forState:UIControlStateNormal];
[aButton setAccessibilityHint:@"Additional help text for VoiceOver users."];
There are no specific Eclipse techniques for this checkpoint. Refer to the General techniques section.
There are no specific Windows-based(MSAA+IA2) techniques for this checkpoint. Refer to the General techniques section.
Most links in this checklist reside outside ibm.com at the Web Content Accessibility Guidelines (WCAG) 2.0. W3C Recommendation 11 December 2008: http://www.w3.org/TR/WCAG20/
Copyright © 1994-2017 World Wide Web Consortium, (Massachusetts Institute of Technology, European Research Consortium for Informatics and Mathematics, Keio University, Beihang University). All Rights Reserved.
Copyright © 2001, 2017 IBM Corporation