Why are forms such tricky business? Perhaps because there are lots of very unforgiving pieces of code involved. It might have to do with the troublesome process of creating an interaction between your form and another computer-based entity, such as another form, or a database. And of course, the trickiest interaction of all takes place between your form and a human being.

But forms are also a great opportunity to improve accessibility because they are where you find out you have a problem. If you give users an article to read and you never hear from them, you might assume that they got the information they needed, and everything was fine. But when a user submits a form with crazy input in it—why do these people put the zip code in the city field?—an accessibility alarm should sound.

Logical Layouts

Forms need to be designed in a logical, consistent way. Make sure the question or description for each input field (a text box, checkbox, or select menu, for example) is on the same line as the input field itself.

Place the label consistently on the same side of the input field, and be sure to explicitly tell the user which bits of information are required. Don’t be subtle! Many web designers rely on color or bold text alone to indicate which items are required fields. Obviously, this technique is of little help to a user who is blind or visually impaired.

We recommend actually making the word Required part of the label for each mandatory field. This practice will benefit users who have low vision, who are color-blind, or who are accessing the site with a screen reader. It is also helpful to users with cognitive disabilities. In general, being consistent and logical in form design will help all users.

Labeling Form Controls

Use the “Label” Tag for Form Controls

Especially for users who access your site using screen readers, it can be extremely difficult or impossible to know what is required in input fields in forms. A user moving through an incorrectly marked up form may hear no more than “Edit edit edit radio button not checked radio button not checked Submit button.”

To make the form usable, explicitly label each control by enclosing the text associated with it in a <label for=””> tag. Then, add an ID attribute to the input field and make both the ID and FOR equal to the same value. Note: ID values must be unique. You cannot give multiple inputs in a form the same ID value.

Avoid Radio Buttons

Radio buttons are not supported consistently by all versions of browsers, screen readers, and combinations. A correctly labeled and tagged set of radio buttons is a very difficult control for users of screen-reading technology. If a “choose only one” situation is called for, a select menu is preferable.

If you must use radio buttons, remember to label them with the “Label for” tag. When radio buttons are used, each radio button in the group has the shared name, but a unique ID. Each radio button in the group has a unique label, as well.

Select Menus

Label Select Menus Inside and Out

The default item in a select menu (also known as a “pulldown menu” or “combo box”) should clearly define the purpose of the menu. For example, “Select Age Range” is preferable to “18-25.” Many screen readers and browsers fail to connect the label with the menu, so users may never see the label.

Keyboard Accessibility

Many users do not use a mouse, but instead use the keyboard to move through the form. One of the main barriers to keyboard accessibility can be the use of client-side scripts, small sections of programming code that run in the user’s browser instead of on the web site’s computer. Be cautious about using client-side scripts to change the browser’s focus, manipulate the data, or submit forms. These techniques can make a form impossible to use with the keyboard alone.

Make sure select menus work with the keyboard as well as with the mouse. Some menus are configured, usually with a client-side script, to take an action as soon as the user has selected an item. Since the keyboard user must pass through the first four items to select the fifth, this select menu does not work for them. The screen-reader-user has reading and navigating tied together in one action, so this user is not only yanked away to the wrong page, he or she does not know what it will be.

Instead, provide a normal submit button that the user can select at leisure, after reviewing all the menu items.

Checkboxes

Checkboxes are a simple control and should be labeled as described above. But they are worth handling with special caution because they often appear after explanatory text or a long question. If the checkboxes’ labels include only the answers and not the original question, the user will miss important information.

A designer using common sense might label a choose-all-that-apply question in a technically correct manner, but might fail to make them usable to test-takers.

Solution: Use the Fieldset Tag

A better approach to the checkbox problem is to use a “fieldset” tag, and then create a “legend” for the fieldset. A fieldset tag allows the designer to treat several different input fields as a group, with a shared description.

Testing Your Form

It is nearly impossible to know whether you’ve marked up your form correctly without testing it with a screen reader. Use more than one screen reader. They can sometimes make good guesses about bad markup and mask a problem.

Read the form by tabbing from one input field to another without trying to fill out the form. Fix any errors you find.

Now test the form by entering the screen reader’s “forms mode” and attempting to fill out the form. You may find quite different results. Fix any additional errors you discover.

The Bottom Line

In summary, if you lay out your forms logically and consistently, make proper use of labels, and avoid client-side scripts and radio buttons, your web forms will be much more accessible to users who are visually impaired.

For more information about creating accessible web sites, explore the Creating Accessible Websites area of the AFB site, or visit the World Wide Web Consortium’s Web Content Accessibility Guidelines at http://www.w3.org/TR/WCAG20/.