Accessible Design: Best Practices

Forms

Section 508: General Guidelines || Form Control Labels || Label Position || Logical Read-Order || Keyboard Shortcuts || Place-holding Characters

return to contents

General Guidelines for Forms.

(n) When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues. (508.n) (MWAS 14)

|

The Section 508 standard for electronic forms addresses the issue from the users perspective rather than the designers. Instead of itemizing specific design elements that must be included in forms, Section 508 simply states that, however the form is designed, it must be functional for users of assistive technology. In practice, this means designers must have a better understanding of how form elements are rendered in assistive technology and sites relying on forms for functionality should be tested using a variety of assistive technology and in a variety of platforms/browsers.

In addition, the WAC recommends form pages clearly display a contact or help link that encourages users who have difficulty using the online form to report their problems. Of course, the contact or help method should not also require the completion of a form (such as the "Tell us what problem you are having" forms found on many commercial sites).

To further help form designers, the WCAG includes more specific guidelines for form development, specified below. For detailed examples and guides on creating accessible forms, see our WAC Forms Tutorials.

return to contents

Form Control Labels.

Each form element should have an associated label. In the past, form designers relied on nearby text to identify the purpose of a particular form element. For example, putting "First Name:" in front of a text box. However, if users of assistive technology read the page out-of-order (as frequently occurs) or must move around the form to make changes or re-enter information, the preceding text may be omitted. Without an associated label, JAWS reads a text box as "Blank, edit." -- an unhelpful description to say the least.

To avoid this problem, designers need only to enclose the existing text label in the <LABEL> tag and add an "id" name to text box. Here is an example:

<LABEL for="firstname">First Name:
<INPUT type="text" id="firstname" tabindex="1">
</LABEL>

Note that the "for" attribute in the LABEL tag must be identical to the "id" attribute of the form element the label describes. This is what is meant by an "explicit association." The result looks essentially the same:

First Name:

However, when the JAWS user navigates to the text box, JAWS no longer reads “Blank, edit.”  Instead, the text box is identified as “First name, edit,” a much more helpful description of what information should go into the edit box.

Explicit association of label and form element is particularly important for list boxes, combo boxes, radio buttons, and check buttons, in which several entries/options are associated with one form question. Consider this example of a radio button set:

Since the code that creates this whole table is kind of lengthy, let's just look at the first three cells:

<td>
<p align="center">
<label for="adminbtn">
<input type="radio" name="position" value="Administrator" id="adminbtn" tabindex="6">
Administrator</label>
</p>
</td>
<td>
<p align="center">
<label for="facultybtn">
<input type="radio" name="position" value="faculty" id="facultybtn" tabindex="6">
<br> Faculty
</label></p></td>
<td>
<p align="center">
<label for="lectbtn">
<input type="radio" name="position" value="Lecturer" id="lectbtn" tabindex="8">
Lecturer</label></p></td>

Each radio button has an associated label, which allows assistive technology to read the text appearing below the button whenever the button is activated. Since labels for buttons often appear above, below, and to the left or right of the button itself, they can be extremely difficult to navigate without associated labels.

Like many forms, the example button options appear within a layout table. While designed to help sighted users identify the grouping of like elements, tables add another layer of navigation difficulty for assistive technology users that can further disassociate the form element from its purpose. If you decide to use layout tables in your forms, be sure you have reviewed the elements of good table design in this tutorial.

return to contents

Positioning Form Control Labels.

As assistive technology advances, it includes more support for accessible HTML tags and attributes. However, not all users are working with the latest version of their technology and not all technology supports the same level of code structure.  Technically, explicit association of labels with form elements means that the label does not need to be near/next to the element for assistive technology to understand and translate the relationship. Thus, with the use of explicitly associated labels, assistive technology could correctly interpret even a form that looked like this:

However, WCAG continues to require designers to follow the generally accepted practice of putting the label as close to the form element as possible (in this case, within the same cell as the associated radio button).   Although practioners continue to argue about the best arrangement, generally speaking, labels appear immediately before or below for text boxes, and to the right of check boxes and radio buttons.

return to contents

Creating a Logical Read Order.

If you don't specify a particular read-order for your form, screen-readers will try to interpret the page using a top-down, left-right default structure. But, forms in particular can cause a number of problems when interpreted using this system. Consider this section of the 2003 U.S. Individual Income Tax Return form 1040:

If the "Filing Status" section of the form is read left-to-right and top-down, it would read "Single," then "Head of household," then "Married filing jointly," then the edit box for "Head of household, then "Married filing separately," and finally, "Qualifying widow." Consider the next section, "Exemptions." At what point would each of the entries on the far right column be read?

Creating a logical tab order resolves the problem of which form control gets read when and helps users input like and related information. The easiest way to create a logical tab order is add the "tabindex" attribute to each form control:

<FORM action="submit" method="post">
<P>
<LABEL for="field1">Email:</label>
<INPUT tabindex="2" type="text" name="field1" id="field1">
<LABEL for="field2">Name::</label>
<INPUT tabindex="1" type="text" name="field2" id="field2" >
<INPUT tabindex="3" type="submit" name="submit">
</FORM>

In this example, the tab order would read Name, Email, Submit, while reading top-down, the form would appear as Email, Name, Submit.

return to contents

Keyboard Shortcuts.

Keyboard users often face difficulty with forms when trying to engage "submit," "reset," or other buttons or form controls usually activated using a mouse click. One strategy to avoid this problem is to be sure to assign a tabindex attribute to form controls, to insure the cursor can be "focused" on these elements. Another helpful tool is to create alternate key combinations or keyboard shortcuts to activate form controls. Keyboard shortcuts are created using the "accesskey" attribute:

<FORM action="submit" method="post">
<P>
<LABEL for="firstname" accesskey="F">First name</LABEL>
<INPUT type="text" tabindex="1"id="firstname">
<INPUT tabindex="2" type="submit" name="submit" accesskey="S">
</FORM>

This example assigns "F" as the accesskey to the first text box. Typing "F" gives focus to the label, which in turn gives focus to the input control, so that the user can input text.

On long forms it may be implausible to assign keyboard shortcuts to every element, but you should still assign a keyboard shortcut to important form elements, like the submit button.

return to contents

Placeholding Characters.

Although support for forms is improving, some assistive technologies require initial text in form controls in order to function correctly. A blank space can be used in most cases. However, if you expect a larger portion of your users to be working with older technology, use alphabetic characters instead. Here are two examples of text boxes:

Name:

Email:

Here is the code used to create these form elements:

<p align=left>
<label for="textfield">Name:</label>
<input type="text" name="textfield" accesskey="N" tabindex="1" id="textfield" value=" ">
</p>
<p align=left>
<label for="textfield2">Email:</label>
<input name="textfield2" type="text" id="textfield2" accesskey="E" tabindex="2" value="enter email address">
</p>

In the first text box, the initial value is set to " ", or a blank space. In the second text box, the initial value is set to "enter email address." In both cases, users must delete or type-over the initial value.

return to top

Next