Web checklist

If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.

The purpose of this checkpoint is to provide sufficient information to users so they can complete forms which may have required fields and correct errors that may occur when filling out forms. When an error occurs, an application must identify the field that is in error and provide information to help the user correct the problem. This information must be described to the user in text so that it is accessible to all users.

Back to top

Compliance with this checkpoint requires all of the following techniques to be met.

These techniques are defined in the Level A Success Criterion for item 3.3.1 from the WCAG 2.0 checklist (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.
3. Client-side validation: Provide client-side validation and alert.

Examples for General developers

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

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

Example 1

When a user submits a form without completing all required fields, an error message must identify which fields were omitted so the user knows what is needed to complete the form. When the form is submitted without an email ID, the following error dialog is displayed indicating the email address must be filled in.

Note: Adding an error message via the DOM also meets this requirement provided a screen reader reads the message when it is rendered.

For more examples of this technique, refer to WCAG 2.0 examples for providing client-side validation and adding error text via the DOM (link resides outside of ibm.com), and to WCAG 2.0 examples for providing text descriptions to identify required fields that were not completed (link resides outside of ibm.com).

Example 2

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

Note: WAI-ARIA examples are not supported by all browsers. If your product needs to be accessible in multiple browsers one or more of the required HTML/CSS specific techniques must be implemented as well as a WAI-ARIA technique.

When a form is submitted without completing all required fields, an error message must identify which fields were omitted so the user knows what information is needed to complete the form.

The following HTML renders a phone number text box with an asterisk beside it and a message below the text box indicating the field is required.

Undesirable code sample:

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

The rendered HTML follows.

* 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 realize 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 will say "required" when the phone number field receives focus.

Corrected code sample:

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

Assume that when a phone number is missing, Javascript prevents a form from being submitted and renders an error message below the form indicating that a phone number is required.

Undesirable code sample:

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

In this example, the error message is created in the DOM, however screen readers don't always read elements created in the DOM. Therefore, a blind user won't know that an error occurred. This problem can 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.

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

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

Example 3

When a user changes their password, the password must meet specific formatting guidelines. In the following example, the user entered a password that did not meet the required number of characters. An error is displayed telling them the password must be at least 8 characters.

Note: Adding an error message via the DOM also meets this requirement provided a screen reader reads the message when it is rendered.

For more examples of this technique, refer to WCAG 2.0 examples for providing a text description when user input falls outside the required format or values (link resides outside of ibm.com) and WCAG 2.0 examples for providing client-side validation and adding error text via the DOM (link resides outside of ibm.com).

Example 4

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

Note: WAI-ARIA examples are not supported by all browsers. If your product needs to be accessible in multiple browsers one or more of the required HTML/CSS specific techniques must be implemented as well as a WAI-ARIA technique.

Often an invalid input error message is rendered below a form, which makes it difficult for a screen reader user to locate the fields the message is referencing. For example, if a phone number is entered 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 discover which fields are invalid. However, when a field receives focus, the screen reader does not indicate that it contains 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>

In order 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 phone number field as follows.

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

When the phone number field receives focus, a screen reader will say "invalid entry".

The aria-invalid property may also be provided on the phone number field via Javascript as in the following example:

document.getElementById('phone').setAttribute('aria-invalid', 'true')

3. Client-side validation: Provide client-side validation and alert.

There are no specific examples for general developers.

Back to top

Examples for script developers

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.

There are no specific examples for script developers.

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

There are no specific examples for script developers.

3. Client-side validation: Provide client-side validation and alert.

Example 5

In the following example, when a user enters an invalid search term into the search field, client-side Javascript alerts the user that they must enter a valid search term and describes the correct format for a valid search term.

Note: Adding an error message via the DOM also meets this requirement provided a screen reader reads the message when it is rendered.

For more examples of this technique, refer to WCAG 2.0 examples for providing client-side validation and alert (link resides outside of ibm.com).

Back to top

Examples for Dojo developers

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, at least one of the following examples must be implemented.

Example 6

The Dojo textbox family of controls (link resides outside of ibm.com) provide 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 don't perceive color, an icon appears in the field. The field is marked with a WAI-ARIA aria-invalid property and when it receives focus, a screen reader will announce that invalid input was entered. The tooltip is spoken by screen readers and visible to sighted users.

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

Example 7

The Dojo 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, an "a" is entered in a CurrencyTextBox and an error message is rendered indicating an invalid input value.

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

3. Client-side validation: Provide client-side validation and alert.

There are no specific examples for Dojo developers

Back to top

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 guideline 3.3.1 from WCAG 2.0 (link resides outside of ibm.com). These techniques go beyond compliance to make the Web site usable as well as accessible.

Back to top

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

1. Test tools
2. Required accessibility verification test techniques

Back to top