Checkpoint 3.3.2 Labels and Instructions

Labels or instructions are provided when content requires user input. (Level A)

Rationale

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).

Development Techniques

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.

General techniques

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.

  1. G131: Providing descriptive labels IN COMBINATION with one or more of the following, appropriate for the circumstances:
  2. G167: Using an adjacent button to label the purpose of a field

Web (HTML, ARIA, CSS) techniques

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.

  1. G131: Providing descriptive labels AND ARIA2: Identifying a required field with the aria-required property (see G131 AND ARIA2 supplement)
  2. G131: Providing descriptive labels AND one or more of the following:
  3. H44: Using label elements to associate text labels with form controls
  4. H71: Providing a description for groups of form controls using fieldset and legend elements
  5. H65: Using the title attribute to identify form controls when the label element cannot be used
  6. 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)

Web supplements

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 aria-required property

The use of a visual indicator along with aria-required on mandatory form fields is strongly recommended.

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.

<form action="#" method="post" id="login1" onsubmit="return errorCheck1()">
    <p>Note: [*]denotes mandatory field</p>
    <p>
        <label for="usrname">Login name: </label>
        <input type="text" name="usrname" id="usrname" aria-required="true" />[*]
    </p>
    <p>
        <label for="pwd">Password</label>
        <input type="password" name="pwd" id="pwd" size="12" aria-required="true" />[*]
    </p>
    <p>
        <input type="submit" value="Login" id="next_btn" name="next_btn" />
    </p>
</form>

H90: Indicating required form controls using label or legend

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>First name (required):</label>
<input...
<label>Last name:<label> (required)
<input...

 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.');">

When the field receives focus, the following JavaScript® function exposes the message and adds an 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.

function showMsg(msg){
var msgContainer = document.createElement('div');
msgContainer.setAttribute('role', 'alert');

var msg = document.createTextNode(msg);
msgContainer.appendChild(msg);

document.body.appendChild(msgContainer);
}

Mobile (iOS) techniques

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.

Provide descriptive labels

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.

- (NSString*)accessibilityLabel
{
return @"Angle";
}
- (NSString*)accessibilityHint
{
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:


- (BOOL)isAccessibilityElement
{
return YES;
}

Refer to the Accessibility Programming Guide for iOS for Apple's style instructions on creating good labels and hints.

Provide instructions when content requires user input

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 setTitle:@"Help:"];
[aButton setAccessibilityHint:@"Additional help text for VoiceOver users."];

Eclipse techniques

There are no specific Eclipse techniques for this checkpoint. Refer to the General techniques section.

Windows-based (MSAA+IA2) techniques

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