Web checklist

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.

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 both Internet Explorer and Firefox, 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 fully supports WAI-ARIA, then WAI-ARIA techniques alone will be sufficient to comply with this checkpoint in both Internet Explorer and Firefox. Refer to the WAI-ARIA overview for more information.

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 using Firefox version 3.6 or later and JAWS version 12 or later.

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.

Back to top

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.

Back to top

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 the following example.

   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."/>

   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.

Back to top

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.

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.