Forms - Optimal Content Examples

Introduction

A form contains a set of form elements, which are a type user control that accepts user input. Form elements are the foundation for nearly all web applications.

Coding Requirements

The following summarizes selected techniques from the Web Content Accessibility Guidelines (WCAG) 2.0 for satisfying the most common applicable success criteria related to this topic. Additional WCAG 2.0 success criteria, techniques, and failures not listed here may also be applicable depending on the content.

1. Labels

Associate Labels

Every form element (<input>, <textarea>, <select>) must be labeled using one of these techniques:

  • Set the form element's id attribute and associate a <label> element by setting its for attribute to the same value. (e.g. <label for="mylabel">Name:</label> <input type="text" id="myname">)

  • Set the form element's title attribute and add a supplementary visual label, instruction, or adjacent button to explain the form element's purpose.

  • Set the form element's value attribute if it is a button (for example, a <button> element or an <input> element with type attribute set to "submit" or "reset").

Source: WCAG 2.0, Technique H44, WCAG 2.0, Technique H65 and WCAG 2.0, Technique G167.

Descriptive Labels

Related to Success Criteria:

Form elements must have descriptive labels that make a form element's purpose clear.

Source: WCAG 2.0, Technique G131

Consistent Labels

Related to Success Criteria:

Form elements must also be labeled consistently. Form elements which provide the same function on one or more pages should have a consistent label.

For example, a button labeled Go To Chapter 4 on one page, and Go To Chapter 5 on another is consistent. However, a button labeled Go To Chapter 4 on one page and Open Chapter 5 on another is not.

Source: WCAG 2.0, Technique G197

Instructions

Related to Success Criteria:

Some form controls require user input data that is mandatory, provided in a specific format, or selected from a set of values. These instructions must be provided to the user through explanation, expected data formats, or examples before the form control.

Source: WCAG 2.0, Success Criterion 3.3.2, Sufficient Techniques #1

2. Error Messages

Related to Success Criteria:

When provided, an error message must:

  • Be provided at the top of the form (when it is server side generated).

  • Indicate the form element containing the error.

  • Indicate the type of error (i.e. missing data, incorrect format, outside of allowed values).

  • Where possible, suggest corrections (unless it would jeopardize the security or purpose of the content).

Source: WCAG 2.0, Technique G83, WCAG 2.0, Technique G84, and WCAG 2.0, Technique G85

3. Session Time Limits

Related to Success Criteria:

When a time limit is present, one of the following is required:

  • Turn off: The user is allowed to turn off the time limit before encountering it; or

  • Adjust: The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or

  • Extend: The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "press the space bar"), and the user is allowed to extend the time limit at least ten times; or

  • Real-time Exception: The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or

  • Essential Exception: The time limit is essential and extending it would invalidate the activity; or

  • 20 Hour Exception: The time limit is longer than 20 hours.

Source: WCAG 2.0, Success Criterion 2.2.1 Timing Adjustable

4. Legal Committments and Financial Transactions

When a user submits changes through a web page that cause a legal committment or financial transaction to occur, one of the following is required:

  • Allow the submission to be reversed. A time limit for the reversal is permitted provided it is stated on the form.

  • Provide a mechanism to review, confirm, and correct before finalizing the submission. Check the data for user input errors.

Source: WCAG 2.0, Technique G98, WCAG 2.0, Technique G99, WCAG 2.0, Technique G155, WCAG 2.0, Technique G164, WCAG 2.0, Technique G168

5. Ensure Form Elements Are Keyboard Accessible

See general web accessibility requirements for the keyboard.

6. Use Of Colour

See general web accessibility requirements for colour.

Content Examples

1. Form Field Examples

  1. Source Code
    <label for="homeaddress">Home Address:</label> 
    <input type="text" name="homeaddress" id="homeaddress" size="60" />
  2. Source Code
    <label for="homeprovince">Home Province:</label>
    <select id="homeprovince" name="homeprovince" size="1">
    <option value="nl">Newfoundland</option>
    <option value="ns">Nova Scotia</option>
    <option value="pe">Prince Edward Island</option>
    <option value="nb">New Brunswick</option>
    <option value="qc">Quebec</option>
    <option value="on">Ontario</option>
    <option value="mb">Manitoba</option>
    <option value="sk">Saskatchewan</option>
    <option value="ab">Alberta</option>
    <option value="bc">British Columbia</option>
    <option value="nu">Nunavut</option>
    <option value="nt">North West Territories</option>
    <option value="yk">Yukon</option>
    </select>
  3. Provinces Lived:
    Source Code
    To follow
  4. Source Code
    <label for="searchTerm">Search for:</label>
    <input id="searchTerm" type="text" size="30" value="" name="searchTerm">
    <select title="Search in" id="scope">
    <option value="books">Books</option>
    <option value="music">Music</option>
    <option value="software">Software</option>
    </select>
  5. Source Code
    <label for="comments">Comments:</label> 
    <textarea name="comments" cols="65" rows="3" id="comments"></textarea>

2. Required Data, Format, and Values

See the form validation project.

3. Search Box

Source Code
<label for="search" class="wb-invisible">Search</label><input type="text" id="search" /> <input type="submit" value="Search" />

Web Accessibility Considerations

Cognitive Impairments

  • Formulate questions so that the options are as short as possible. Users can get overwhelmed if they have to choose between several options with large amounts of text.

Mobility, Dexterity and Coordination Impairments

  • Do not use radio buttons. Users with mobility impairments have difficulties selecting them because of the small target area.

Visual Impairments

  • Do not use forms without submit buttons (e.g. an automated JavaScript solution). Users need the ability to control when to activate the form submission. Performing this action automatically is especially confusing for screen readers.

  • Do not use radio buttons, as users with low vision have difficulty determining when a radio button is selected. Additionally, radio buttons introduce multiple form controls into the tab order. This results in extra effort for screen reader users to navigate a form.