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/.

1. Relative Font Sizes

Use relative font sizes expressed in percentages or ems, rather than absolute font sizes expressed in points or pixels. This practice allows users to make the text larger or smaller as desired—an important feature for users with low vision.

2. Provide Alternative Text for Images

It is absolutely necessary to provide text equivalents for all meaningful graphics. If the graphic includes text, be sure that the alternative text (often referred to as an “alt tag”) supplies all of the words.

Example:
<img src=”graphic.gif” alt=”Acme – supplying widgets since 1945″ width=”50″ height=”20″>

That said, providing “alt” text for spacers or placeholding graphics subjects the speech user to meaningless information. Spacers or graphics used only for positioning should be labeled with alt=” ” (quote, space, quote). Note that you should never completely omit the alt tag, even for placeholding graphics. This omission subjects the speech user to hearing the file name of the image.

If you are in doubt as to whether or not to describe an image with an alt tag, do it.

3. Name Links Carefully

Users often move through a page by tabbing from link to link. Never use “Click here” or “Learn More” as the text for your links. “Download New Version” is self-explanatory.

4. Explicitly State Information

Do not use indentation or color alone, for example, to convey meaning.

Example:

Indicating required fields in a form by making them bold is bad.
Indicating required fields by using a phrase such as “required” is good.

5. Label Forms Properly

Create a predictable, consistent interface for your users. For example, make sure the question or description is consistently on the same side of its control. Ideally, place the question or label on the same line as the input field itself.

Enclose the label associated with an input field in a <label for=””> tag, or wrap it in a fieldset.

6. Provide Skip Links

Skip links allow the speech software or braille user to bypass information that is repeated on every page, such as navigation bars. Speech and braille users generally read the page from top to bottom and consequently are subjected to repeated information before reaching the heart of the page. Skip links allow these users to jump past the repetitive navigation links to get to the main content on the page.

To implement skip links, place a link before the repeated information as follows:

<a href=”#content”><img src=”empty.gif” height=”15″ border=”0″ alt=”Skip Main Navigation” width=”5″></a>

and place an anchor at the beginning of unique copy:

<a name=”content”></a>

The image can be transparent so that the visual display is not affected, but speech and braille users can hear the alt tag reading “skip main navigation”.

It is also possible to use a text link that literally says <a href=”#content”>skip main navigation</a>, if you prefer. We do not recommend using an “invisible” text link, like a single space or underscore. That technique relies on the link’s title to provide accessibility, and not all screen readers provide the link title to the user.