Skip to Content

AFBAmerican Foundation®
for the Blind

Expanding possibilities for people with vision loss

Designing Accessible Web Forms

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.

There is much more detail on how to use the "Label" tag in the AccessWorld® article Getting Your Forms in Shape.

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. We'll use the example of the multiple-choice quiz.

A designer using common sense might label the following questions in a technically correct manner, but might fail to make them usable to test-takers.

1. Which of the following foods have more than 3 grams of fiber per serving?

- Apples
- Brown rice
- Orange Popsicles
- Kellogg's Raisin Bran

2. Check those foods that have more than 15 grams of protein per serving:

- Canned tuna in water
- Kellogg's Rice Krispies
- Large eggs
- Cheddar cheese

If the designer encloses only the answers in a "label for" tag, the screen reader user might hear something like:

"Apples (checkbox not checked)
Brown rice (checkbox not checked)
Orange Popsicles (checkbox not checked)
Kellogg's Raisin Bran (checkbox not checked)
Canned tuna in water (checkbox not checked)
Kellogg's Rice Krispies (checkbox not checked)
Large eggs (checkbox not checked)
Cheddar cheese (checkbox not checked)"

The user not only misses the question, but may not be able to distinguish that there is more than one question.

Solution: include the question in the label of the first option. So, the markup for the "apples" and "Brown rice" choices would look like this:

<label for = "q1a">1. Which of the following foods have more than 3 grams of fiber per serving? <br>
<br>
Apples
</label>
<input type = "checkbox" name = "q1a" id = "q1a" value = "apples">
<br>
<label for= "q1b">- Brown rice</label>
<input type = "checkbox" name = "q1b" id = "q1b" value = "brown rice">
<br>

The above code would appear on the page this way:


Note: <br> was inserted for formatting. Many, but not all, tags can be used within the "label for" tag.

Why Not Use the Fieldset Tag?

The other approach to the checkbox problem described above 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. (Again, see the AccessWorld® article Getting Your Forms in Shape for details.)

Unfortunately, the fieldset approach is not supported by all forms and versions of assistive technology. For example, JAWS 5.0 reads the legend very nicely when not in "forms mode," but does not read the question while you are actively filling out the form. Window-Eyes 4.5 reads only the answers, without the question, no matter what. If you want your form read by the widest variety of users, use the first method.

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 Web Accessibility area of the AFB site, or visit the World Wide Web Consortium's Web Content Accessibility Guidelines at www.w3.org/TR/WCAG10/.

services icon Directory of Services

Join Our Mission

Help us expand our resources for people with vision loss.