Web checklist

Checkpoint 3.3b: Labels or instructions

Labels or instructions are provided when content requires user input.


Rationale

People with disabilities may face difficulty when errors occur on a Web-based form. The purpose of this checkpoint is to ensure that Web interfaces contain unambiguous labels, input format examples, and instructions for completing forms, which enable users to avoid errors when input is required.

Required development and unit test techniques


To comply with this checkpoint, you must implement all of the following techniques. These techniques are defined in the WCAG 2.0 Level A Success Criterion 3.3.2 (link resides outside of ibm.com).

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

Note: The examples presented in the techniques are not exhaustive. They are meant to illustrate the spirit of this checkpoint.

At this time WAI-ARIA examples are only fully supported in Firefox version 3.6 or later and version JAWS 12 or later. If your product needs to be accessible in Internet Explorer and mobile Safari/VoiceOver, one or more of the required HTML/CSS specific techniques must be implemented, as well as a WAI-ARIA technique. When WAI-ARIA becomes an approved W3C recommendation and Internet Explorer and mobile Safari/VoiceOver fully support it, then WAI-ARIA techniques alone will be sufficient to comply with this checkpoint.

Applications that provide WAI-ARIA must add the following statement to the checkpoint comments column of the Web Accessibility Checklist:

Note: This product uses WAI-ARIA to comply with this checkpoint. WAI-ARIA is supported on Windows using Firefox version 3.6 or later and JAWS version 12 or later, and supported on iOS v5.0 and later using Safari and VoiceOver.

General examples

  1. Labels: Provide descriptive labels.

    To comply with this technique, you must implement all the following examples.

    General 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 additional information, refer to the WCAG 2.0 examples for providing descriptive labels (link resides outside of ibm.com).

    General example 2

    For a form with required fields, refer to Web checkpoint 1.3d Forms for examples on how to label them using the aria-required attribute.

    Required unit tests for general development technique 1

    Manually perform the following unit tests.

    • Locate all interactive (form) fields in the content.
    • Confirm that all interactive components within the Web content have descriptive labels that clarify the component's purpose.
  2. Instructions: Provide instructions when content requires user input.

    To comply with this technique, you must implement at least one of the following examples.

    General example 3

    Provide expected data format to help a user enter data in the correct format. For example, the following field label indicates how to enter a date of birth in the correct format.

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

    For additional information, refer to the WCAG 2.0 examples of providing expected data format and example (link resides outside of ibm.com).

    General example 4

    Provide text instructions at the beginning of a form or set of fields that describes the expected input format to assist users 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 additional information, refer to the WCAG 2.0 examples of providing text instructions (link resides outside of ibm.com).

    General example 5

    Position labels to maximize predictability of relationships. By placing form labels where the user expects them, users can better 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 additional information, refer to the WCAG 2.0 examples for positioning labels (link resides outside of ibm.com).

    General example 6

    Provide text descriptions to identify required fields that the user did not complete. See Web checkpoint 3.3a for examples of providing text descriptions and an aria-required property to identify required fields that were not completed.

    General example 7

    Use aria-describedby to provide text instructions for fields that require data in a specific format. Describing expected input format helps to prevent errors when completing forms. For example, if the following footnote appears at the bottom of the page, a screen reader user cannot determine how to enter a social security number in a form field that appears near the top of the page.

    Do not enter dashes in the social security number.

    To solve this issue, add an aria-describedby attribute to the input field that references the instructions for entering a social security number as follows:

    <label for="ssn">SSN:</label><input id="ssn" type="text" aria-describedby="ssnHelp"/>

    <span id="ssnHelp">
    Do not enter dashes in the social security number.</span>

    When the social security number field receives focus, the user hears the text that describes the expected format of the input data.

    General example 8

    Use the WAI-ARIA alert role to provide text instructions for fields that require data in a specific format. The following 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);
    }

    Required unit tests for general development technique 2

    Manually perform the following unit tests.

    • Locate any interactive (form) fields in the content using the tools available.
    • Confirm that instructions about expected data format and examples of such format are provided for all form controls that will only accept user input data in a given format.
    • Ensure that form fields have visible labels that appear immediately before the field. For checkboxes and radio buttons, the label appears immediately after the field to maximize predictability of relationships.
    • Ensure that a text description is provided that identifies the mandatory field(s) that the user did not complete for any required fields in the content.
 

HTML examples

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

  1. Labels: Provide descriptive labels.

    HTML example 1

    Use <label> elements to associate text labels with form fields. Refer to technique 1 in Checkpoint 1.3d: Forms for details on using <label> elements to associate text labels with form fields.

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

    There are no specific examples for implementing this technique in HTML. Use the general examples as a guide.

 

Dojo examples

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

  1. Labels: Provide descriptive labels.

    There are no specific examples for implementing this technique with Dojo. Use the general examples as a guide.

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

    To comply with this technique, you must implement all of the following examples.

    Dojo example 1

    Use the Dojo promptMessage attribute to provide text instructions for fields that require data in a specific format. The following example uses promptMessage to display a tooltip hint about the expected format of a social security number. When the field receives focus, a tooltip displays the promptMessage and JAWS announces the message.

    <input type="text" id="userSSN" name="userSSN"
    dojoType="dijit.form.ValidationTextBox"
    promptMessage="Do not enter dashes in the social security number."/>

    Dojo example 2 (for iOS platform)

    For mobile Safari targeted content, do not use the Dojo mobile DatePicker widget because it is not accessible at this time. Use the HTML5 date input type to enable easier data input and validation. When an HTML5 date field receives focus, the following picker widget is rendered.

    <input type="date" ... />

    Dojo mobile DatePicker widget

    Dojo example 3 (for iOS platform)

    For mobile Safari targeted content, do not use the Dojo mobile TimePicker widget because it is not accessible at this time. Use the HTML5 time input type to enable easier data input and validation. When an HTML5 time field receives focus, the following picker widget is rendered.

    <input type="time" ... />

    Dojo mobile TimePicker widget

    Dojo example 4 (for iOS platform)

    For mobile Safari targeted content, do not use a WAI-ARIA widget with role="slider". Slider widgets are not accessible at this time. Use the HTML5 range input type to enable accessible data input and validation.

    <input type="range" ... />

    Dojo mobile widget displaying a range slider

    Note: The HTML5 input types are not supported by the latest version of Firefox ESR and Internet Explorer 8. When a browser does not support an HTML5 input type, the input field defaults to the behavior of a standard HTML 4 text type (i.e., <input type="”text”..." /> ). Therefore, the HTML5 input types offer enhanced user input controls for mobile and no undesirable behavior in desktop browsers. Refer to the recommended development techniques to see more examples of HTML5 input types.

    Required unit tests for Dojo development technique 1

    Manually perform the following unit tests.

    • Locate any forms in the content using the tools available.
    • Complete every form that has required fields, deliberately leave one or more required fields blank, and submit it. Verify that a visual indication is provided that indicates the required field(s) was not completed and that a tooltip is provided that identifies the error and describes the form of valid input.
    • (Optional) Confirm that the tooltip is announced by a screen reader.
 

Recommended development techniques

Although you do not have to implement the recommended techniques in order to comply with this checkpoint, you should review them because they can improve the accessibility and usability of the application.

The following techniques are recommended to comply with this checkpoint:

  1. Use the HTML5 month input type for mobile Safari targeted content.
  2. Use the HTML5 search input type for mobile Safari targeted content.
  3. Use the HTML5 number input type for mobile Safari targeted content.
  4. Use the HTML5 tel input type for mobile Safari targeted content.
  5. Use the HTML5 url input type for mobile Safari targeted content.
  6. Use the HTML5 email input type for mobile Safari targeted content.
  7. Use the HTML5 week and color input types for mobile Safari targeted content.

Note: For mobile Safari targeted content, recommended examples 1 through 7 encourage using HTML5 input types to help users easily enter information in forms. Many of the HTML5 input types enable entering form information by selecting from picker controls that mobile Safari renders when the HTML5 input types are specified. When a picker is not appropriate, mobile Safari exposes a virtual keyboard.

Recommended example 1 (for iOS platform)

Use the HTML5 month input type for mobile Safari targeted content.

<input type="month" ... />

When a month field receives focus, mobile Safari displays the following picker control:

Dojo mobile widget displaying a slider

Recommended example 2 (for iOS platform)

Use the HTML5 search input type for mobile Safari targeted content.

The search field can be given place holder text by specifying the placeholder attribute as follows:

<input type=”search” placeholder=”enter search term” .../>

When a search field receives focus, mobile Safari displays the virtual keyboard:

Dojo mobile widget displaying a slider

Recommended example 3 (for iOS platform)

Use the HTML5 number input type for mobile Safari targeted content.

<input type="number" ... />

When a number field receives focus, mobile Safari displays a number keyboard:

Safari number keyboard

Recommended example 4 (for iOS platform)

Use the HTML5 tel input type for mobile Safari targeted content.

<input type="tel" ... />

When a tel field receives focus, mobile Safari displays a number pad:

Safari keypad

Recommended example 5 (for iOS platform)

Use the HTML5 url input type for mobile Safari targeted content.

<input type="url" ... />

When a url field receives focus, mobile Safari displays a keyboard with “.com”, “/” and period keys to enable typing a URL:

Safari keyboard with .com key

Recommended example 6 (for iOS platform)

Use the HTML5 email input type for mobile Safari targeted content.

<input type="email" ... />

When an email field receives focus, mobile Safari displays a keyboard with an “@” symbol to enable entering an email address:

Safari keyboard with @ symbol

Recommended example 7 (for iOS platform)

Use the HTML5 week and color input types for mobile Safari targeted content. When the week and color input types receive focus, mobile Safari displays a standard keyboard. However, other browsers (perhaps even a future version of mobile Safari) may display picker controls for these fields.

<input type="week" ... />

<input type="color" ... />

Safari standard keyboard

Refer to the WCAG 2.0 Additional Techniques (Advisory) for 3.3.2 (link resides outside of ibm.com) . The use of these techniques more than ensures compliance for developing usable, as well as accessible, Web sites.


Copyright 2013 IBM Corporation

Last updated January 1, 2013.

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.