Skip to main content

Web checklist

Checkpoint 3.3b: *WCAG 2.0* Labels or instructions

Labels or instructions are provided when content requires user input.

On this page:



Rationale

It is sometimes hard for disabled users to recover from input errors when a form is submitted. The intent of this checkpoint is to provide unambiguous labels, input format examples and instructions for completing forms so that mistakes are avoided when user input is required.

Required development techniques

These techniques are defined in the Level A Success Criterion for guideline 3.3.2 from the WCAG 2.0 checklist (link resides outside of ibm.com).

Compliance with this checkpoint requires all of the examples from technique 1 to be met, and at least one of the examples from technique 2 to be met.

  1. Labels: Provide descriptive labels.
  2. Instructions: Provide instructions when content requires user input.

Examples for general developers

1. Labels: Provide descriptive labels.

To comply with this technique, all the following examples must be implemented.

Example 1

An application that provides maps must provide controls that are keyboard accessible and labeled. For example, controls might be labeled "Zoom (Ctrl + Shift + L) and "Zoom out (Ctrl + Shift + R)".

For more examples of this technique, refer to WCAG 2.0 examples for providing descriptive labels (link resides outside of ibm.com).

Example 2

Use label elements to associate text labels with form fields. Please refer to technique 1 in Web checkpoint 1.3d Forms for details on using label elements to associate text labels with form fields.

Example 3

A form with required fields. Please refer to Web checkpoint 1.3d Forms for examples on how to label required fields on a form and how to label required fields on a form using WAI-ARIA aria-required.

2. Instructions: Provide instructions when content requires user input.

To comply with this technique, WAI-ARIA example 4 is required and at least one of the following other examples must be implemented.

Example 4

Provide text descriptions to identify required fields that were not completed.

See Web checkpoint 3.3a for examples of providing text descriptions and a WAI-ARIA required property to identify required fields that were not completed.

Example 5

Provide expected data format helps to prevent data being entered in an incorrect format. For example, the following field label indicates how to enter a birth date in the correct format.

<label for="birthdate">Birth date (dd-mm-yyyy):</label><input type="text" name="birthdate" id="birthdate">

For more examples of this technique, refer to WCAG 2.0 examples of providing expected data format and example (link resides outside of ibm.com).

Example 6

Provide text instructions at the beginning of a form or set of fields describing expected input format helps to prevent errors when completing forms. For example, the following text may be rendered at the top of a form. Enter the following driver license information. Dates should be entered in mm-dd-yyyy format. Do not enter dashes in the social security number. Required fields are indicated with an asterisk (*).

For more examples of this techniques, refer to WCAG 2.0 examples of providing text instructions at the beginning of a form or set of fields that describes the necessary input (link resides outside of ibm.com).

Example 7

Position labels to maximize predictability of relationships. Form labels appearing where they are expected helps users understand and locate specific fields within complex forms. For example in left-to-right languages, field labels commonly appear above or to the left of input fields as follows.

<table border="0" cellspacing="20" role="presentation">
<tr><td>
<div> <label for="city1">City:</label>
</div>
<input type="text" id="city1" name="city1">
</td>
<td valign="bottom">
<label for="city2">City: </label><input type="text"id="city2" name="city2">
</td>
</tr>
</table>


For right-to-left languages, input field labels appear above or to the right of the fields. Labels for checkboxes and radio buttons commonly appear to the right of a checkbox or button as follows.

<input type="radio" id="single" name="single" value="single">
<label for="single">Single</label>
<input type="radio" id="married" name="married" value="married">
<label for="married">Married</label>


For more examples of this technique, refer to WCAG 2.0 examples for positioning labels to maximize predictability of relationships (link resides outside of ibm.com).


Examples for script developers

For techniques that have no technology-specific examples, refer to the general example section for guidance.

1. Labels: Provide descriptive labels.

To comply with this technique, all of the following examples must be implemented.

Example 8

See Web checkpoint 1.3a for examples on how to provide a description for groups of form controls using fieldset and legend elements.

Example 9

See Web checkpoint 1.3d Forms for examples on how to use the title attribute to identify form controls when the label element cannot be used.

2. Instructions: Provide instructions when content requires user input.

There are no specific examples for script developers.

Implementation of recommended techniques is not required to comply with this checkpoint, but these techniques should be reviewed since they can improve the accessibility and usability of the solution.

Please refer to the Additional Techniques (Advisory) for 3.3.2 from WCAG 2.0 (link resides outside of ibm.com). Using the additional techniques goes beyond compliance to make the Web site usable as well as accessible.

Required test techniques

The following test tools and techniques are required to verify this checkpoint.

  1. Test tools
  2. Required accessibility verification test techniques

Test tools:

Install the following tools to test this checkpoint:

Required accessibility verification test techniques:

Use the following accessibility verification test (AVT) techniques to validate the Web content. It is recommended that these tests be performed in order.

1. Web syntax analyzer test:
Action Result

Test the Web site with a Web syntax analyzer to verify the compliance criteria as follows

Pass:

Fail:

2. Manual test:
Action Result

Verify the compliance criteria for this technique as follows.

For any user interface elements on the page, verify all of the following to be true.

Pass:

Fail:

3. Screen reader test:
Action Result
Verify the following compliance criteria with a screen reader.
For detailed instructions on how to test this checkpoint with a screen reader follow the 'Screen reader accessibility verification tests for Web checklist 5.1' document.

Pass:

Fail:

©2009 IBM Corporation

Last updated September 1, 2009

W3C Recommendation 11 December 2008: http://www.w3.org/TR/WCAG20/ (link resides outside of ibm.com)
Consortium for Informatics and Mathematics, Keio University), All Rights Reserved.