Web checklist

This checkpoint ensures that users have sufficient information to complete forms that may contain required fields and that users can correct potential errors on a form. The application must notify the user if an error occurs when the user enters information into a form and the Web application must provide information that will help the user correct the error. To enable accessibility for all users, this information must be described to the user in text.

To comply with this checkpoint, you must meet all of the following techniques.

These techniques are defined in WCAG 2.0 Level A Success Criterion 3.3.1 (link resides outside of ibm.com).

1. Identify incomplete fields: Provide text descriptions to identify required fields that were not completed.
2. User input: Provide a text description when user input falls outside the required format or values.

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. Identify incomplete fields: Provide text descriptions to identify required fields that were not completed.

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

   General example 1

   When a user submits a form without completing all required fields, an error message must identify the required fields so the user can complete the form. For example, if a user submits a simple feedback form without entering an email address, the following JavaScript^® alert dialog box appears.

   

   General example 2

   Provide text descriptions and a WAI-ARIA required property to identify required fields that were not completed.

   When a user submits a form without completing all required fields, an error message must identify the fields that are required so the user can complete the form.
   The following HTML displays a phone number text box with an asterisk beside it and a message below the text box indicating that the field is required.

   <label for="phone">* Phone number:</label>
<input type="text" id="phone" name="phone">
<p>* indicates required information must be entered.</p>

   The rendered HTML looks like this:

   * Phone number:

   * indicates required information must be entered.

   A sighted user immediately recognizes that a phone number is required. However, a blind user may not know that an asterisk indicates a required field until she navigates to the bottom of the form and the screen reader reads "asterisk indicates required information must be entered." Additionally, if form fields are placed in a layout table and an asterisk and required field are placed in different table cells, a screen reader user may not recognize that the field is required.

   Adding an aria-required property to the <input> element enables a screen reader to provide immediate feedback that a phone number is required. When aria-required is set to true, as in the following example, a screen reader announces "required" when the phone number field receives focus.

   The following is a better code sample:

   <label for="phone">* Phone number:</label>
<input type="text" id="phone" name="phone" aria-required="true" >


   Assume that when a user does not enter a phone number, JavaScript prevents the submission of the form and renders an error message below the form indicating that a phone number is required.

   <label for="phone">* Phone number:</label>
<input type="text" id="phone" name="phone">
<p>* indicates required information must be entered.</p>
<p style="color:red;">Before submitting this form, your phone number must be entered.</p>

   The error message is created in the DOM, but unfortunately screen readers do not always read elements created in the DOM, meaning that blind users do not realize that an error has occurred. This problem may be overcome by assigning an alert role to the message container as follows.

   Better code sample:

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

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

   When an error occurs, the JavaScript function creates a <div> element and assigns it a role of alert. A text node containing the error message is created and appended to the <div>. Finally, the <div> is appended to the document body. The alert role causes the screen reader to read the error message when it is rendered.

   Required unit tests for general development technique 1

   Manually perform the following unit tests.

   • Locate any forms in the content.
   • Complete every form that has required fields, deliberately leave one or more required fields blank, and submit it. Verify that a text description is provided that indicates the required field(s) was not completed.

2. User input: Provide a text description when user input falls outside the required format or values

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

   General example 3

   When a user changes their password, the format of the password must meet specific guidelines. In the example below, if the user enters a password that does not meet the required number of characters, the application displays an error message explaining that the password must contain at least eight characters.

   

   General example 4

   Provide a aria-invalid property when user input falls outside the required format or values.

   When a Web page renders an invalid input error message below a form, screen reader users may have difficulty locating the fields that the message references. For example, if a user enters a phone number incorrectly in the field below, an error message is rendered at the bottom of the form. If the form contains multiple fields, a screen reader user must navigate through the form to find the invalid fields. However, when a field receives focus, the screen reader does not indicate that it contains an invalid input and the user may have forgotten the names of the fields referenced in the error message.

   <label for="phone">* Phone number:</label> <input type="text" id="phone" name="phone"> <p>* indicates required information must be entered.</p> <p style="color:red;">Phone number is not in the correct format.</p>

   To assist screen reader users in locating fields with invalid input, provide an aria-invalid property on the fields. For example, an aria-invalid property is provided on the following phone number field.

   <input type="text" id="phone" aria-invalid="true" ...>

   When the phone number field receives focus, a screen reader announces that it is an "invalid entry."

   Required unit tests for general development technique 2

   Manually perform the following unit tests.

   • Locate any forms in the content.
   • Deliberately enter user input that falls outside the required format or values. Then verify that the invalid entry has a text description that indicates it is incorrect, describes the nature of the error and how to fix it.

Back to top

Dojo examples

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

1. Identify incomplete fields: Provide text descriptions to identify required fields that were not completed.

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

   Dojo example 1

   The Dojo number textbox family of controls (link resides outside of ibm.com) provides client-side validation and an accessible method of displaying error messages when required input is missing. The following example shows a field with required input missing. The textbox changes color when a validation error occurs. For users that cannot perceive color, an icon appears in the field. The field is marked with an aria-invalid property and when it receives focus, a screen reader announces that the user has entered invalid input. The tooltip is announced by screen readers and is visible to sighted users.

   

   Required unit tests for Dojo development technique 1

   Manually perform the following unit tests.

   • Locate any forms in the content.
   • 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.

2. User input: Provide a text description when user input falls outside the required format or values.

   Dojo example 2

   The Dojo currency textbox family of controls (link resides outside of ibm.com) provides client-side validation and an accessible method of displaying error messages when input is invalid or formatted incorrectly. In the following example, the user enters the letter a in a currency textbox and the control renders an error message that indicates an invalid input value.

   

   As in the previous example, the textbox changes color when a validation error occurs. For users that cannot perceive color, an icon appears in the field. The field is marked with a aria-invalid property and when it receives focus, a screen reader announces that the user has entered invalid input. The tooltip is announced by screen readers and visible to sighted users.

   Required unit tests for Dojo development technique 2

   Refer to the required unit tests for Dojo development technique 1.

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 Success Criterion 3.3.1 (link resides outside of ibm.com). Use of these techniques goes beyond compliance to making the Web site usable, as well as accessible.