Forms
From Library
The Issue: Properly designed HTML forms are one of the easiest ways for people with disabilities to provide information. The problem arises when people designing HTML forms lay them out for visual appeal instead of functionality and ease of use.
Contents |
[edit]
STANDARD 13.1
On-line forms will allow people using assistive technology devices to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.
Comments: Properly designed HTML forms are one of the easiest ways for people with disabilities to provide information. The problem arises when people designing HTML forms do so for visual appeal or to "make it look just like the paper form."
Among the practices to consider:
1. Do not stack labels above their corresponding fields:
WRONG:
| Name Address | |
| Mike Medium | Schenectady NY |
Screen readers process pages by reading from top to bottom, starting at the left and moving to the right. In this example, the label "Name:" would be read, then any other labels on that same row, then the input box would be announced. It's entirely likely that the user would not be able to match a row of labels with a row of input elements.
RIGHT:
| Name | Mike Medium |
| Address | Schenectady NY |
2. Consider using pull-down list boxes instead of elements such as checkboxes or
radio buttons that require fine motor control. Select boxes tend to be easier
to manipulate. Use of the <label> tag on checkboxes and radio buttons makes these
controls significantly easier to use, if the developer chooses to these controls.
3. Consider grouping related elements (using the fieldset element) to provide
additional contextual cues. Use the <fieldset> tag to accomplish this.
4. Provide a submit button for forms instead of using some other method
(e.g., JavaScript) to automatically submit them.
5. Tables should not be used for form layout unless labels are explicitly associated
with form controls, especially if the labels and form controls are in separate
table cells. Style sheets make the use of tables for forms unnecessary, and are
considerably more accessible to people using alternative technology.
6. When requesting that the user enter an item in a format other than the one
usually associated with it (e.g., entering a Social Security number without
dashes), use the value attribute of the input element to provide that instruction.
For an example of this practice, see the Oceania Employment Application.
HTML Elements Affected: N/A — Pertains more to overall form layout than specific elements.
[edit]
STANDARD 13.2
A label element will be used for all form controls that do not have implicit labels.
Comments: Explicitly associating a label with each form control serves two important purposes. First, it cues the visitor as to what information is required to complete the form control. Second, it can be used to set an "access key," which makes the form accessible without a mouse.
Form labels are associated with form controls by the using the value of the form control's id attribute as the for value in the label. When a label receives focus, it passes the focus to the associated form control.
HTML Elements Affected: <input>, <textarea>, <select>
[edit]
Code Examples:
Implicit Label: The input element is enclosed within the label element.
<label>First Name:
<input type="text" name="firstname" id="fname" size=25>
</label>
NOTE: You cannot use implicit form control labels if you are using a table for layout and are placing the form control label and the form control in different table cells.
Explicit Label: The label element is associated with the input element by
using the input element's id value ("email") as the for value of the label element.
<label for="fname">First Name:</label>
<input type="text" name="firstname" id="fname" size=25>
[edit]
STANDARD 13.3
Forms elements will be in logical tab order.
Comments: This standard pertains to users who use the tab key to move through a form. From the WorldWide Web Consortium site:
The tabbing order defines the order in which elements will receive focus when navigated by the user via the keyboard. The tabbing order may include elements nested within other elements.
Elements that may receive focus should be navigated by user agents according to the following rules:
1. Those elements that support the tabindex attribute and assign a positive value to it are navigated first. Navigation proceeds from the element with the lowest tabindex value to the element with the highest value. Values need not be sequential nor must they begin with any particular value. Elements that have identical tabindex values should be navigated in the order they appear in the character stream.
2. Those elements that do not support the tabindex attribute or support it and assign it a value of "0" are navigated next. These elements are navigated in the order they appear in the character stream.
3. Elements that are disabled do not participate in the tabbing order.
The following elements support the tabindex attribute:
a, area, button, input, object, select, and textarea.
TIP: For large, complex forms, it's best to break the form down into sections and leave some gaps in tabindex numbering to accommodate subsequent additions or changes. HTML Elements Affected: <a>, <area>, <button>, <input>, <object>, <select>, and <textarea>
[edit]
Code Example:
<label for="st" accesskey="T">State Abbreviation:</label>
<select tabindex=10 name="state" id="st">
<option label="New York" value="NY">NY
<option label="Vermont" value="VT">VT
<option label="Connecticut" value="CT">CT
<option label="Massachusetts" value="MA">MA
<option label="Pennsylvania" value="PA">PA
</select>
