Forms - Optimal Content Examples
Table Of Contents
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
Related to Success Criteria:
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 itsfor
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 withtype
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
Related to Success Criteria:
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
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.
Related Links
Web Content Accessibility Guidelines (WCAG) 2.0 Success Criteria
Web Content Accessibility Guidelines (WCAG) 2.0 Sufficient Techniques
- H44: Using label elements to associate text labels with form controls
- H65: Using the title attribute to identify form controls when the label element cannot be used
- G167: Using an adjacent button to label the purpose of a field
- G83: Providing text descriptions to identify required fields that were not completed
- G84: Providing a text description when the user provides information that is not in the list of allowed values
- G85: Providing a text description when user input falls outside the required format or values
- G131: Providing descriptive labels
- G89: Providing expected data format and example
- G184: Providing text instructions at the beginning of a form or set of fields that describes the necessary input
- G162: Positioning labels to maximize predictability of relationships
- G83: Providing text descriptions to identify required fields that were not completed
- H90: Indicating required form controls using label or legend
- G197: Using labels, names, and text alternatives consistently for content that has the same functionality
Tools and Utilities
- Date modified: