Web checklist

Checkpoint 3.3a: Error Identification

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.


Rationale

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.

Required development and unit test techniques


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

    Alert box with message: E-mail, you need to fill in your email address.

    General example 2

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

    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.

    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:

    * 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 label 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" >

    Note: The HTML5 input tag's required attribute behaves the same way the WAI-ARIA aria-required attribute behaves in Firefox 10.0.7+/JAWS and Mobile Safari/VoiceOver. However, only aria-required works in Internet Explorer 8/JAWS. If your application must be accessible in Internet Explorer 8, use aria-required

    .

    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.

  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.

    Alert box with message: password must contain at least 8 characteres. Please retry.

    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.


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.

    empty form field with error message: Enter a value between -20000 and +20000

    Required unit tests for Dojo development technique 1

    Manually perform the following unit tests.

  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.

    form field filled with $54,775.5a and with error message by side: Invalid amount. Include dollar sign, commas, and cents.

    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.

 

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.

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.


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