Web designers who care about creating accessible web sites know they need to label images, write links whose text will make sense out of context, and make many other simple-to-implement accessibility changes. But what about the accessibility details that are harder to implement, harder to understand, and harder to test? In this article, we will tackle one of the trickier issues that can turn an otherwise accessible web site into a frustrating experience for web users who are blind or visually impaired: forms.
Forms are an important method that web designers use to gather information from the users of a web site and provide them with customized information in return. A site's search function, for example, relies on a very simple form--the search box--to collect the terms that people are interested in so that the web programmer can provide search results that will meet their needs. The checkout process in an online bookstore is an example of a longer, more complicated form. The same basic rules apply to both, however, and a few simple changes can greatly improve their accessibility. This article will explain some of the problems you may be encountering with forms and will provide some suggestions you can pass on to a designer of a site--or that you can use yourself in designing your own accessible web sites.
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.
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.
Here is an example that will be all too familiar to screen reader users. On a web page is a select menu (combo box or drop-down menu) of choices that start with "Choose One" or "Select a Category." You tab to this item, do whatever your screen reader wants you to do to "activate" the combo box (probably hit Enter) and start arrowing down to see what the choices are. Boom, you're off to another page. What other page? You may never find out.
What has happened? Some select menus are programmed to take an action as soon as you have selected an item. These forms often use a client-side script with what JavaScript calls an "onChange event," triggered when you release the mouse button after selecting the desired item in the drop-down menu. Since the keyboard user must pass through the first four items to select the fifth, this select menu does not work. 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. To prevent this from happening, provide a Submit button that the user can select at leisure after reviewing all the items in the select menu.
Labeling Form Controls
When you access a site using a screen reader, it can be extremely difficult or impossible to know what information is supposed to be supplied in forms. A person tabbing his or her way through an incorrectly marked-up form may hear no more than "Edit, edit, edit, radio button not checked, radio button not checked, Submit button." Clear as mud, right?
This problem is solved by using labels in HTML (hypertext markup language, the set of tags used to format and display content on the web). Labels connect the question or explanatory text with the input field. Once a form is properly labeled, a screen reader will read the text label identified with the input field, no matter where the label appears on the screen. It is still important to make the visual layout of the form logical and consistent, but identifying labels within the HTML can make forms much easier for people to use with screen readers and other assistive technologies.
Label markup is a bit tricky, though. To make the form accessible, explicitly label each input field 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 LABEL FOR equal to the same value. ID values must be unique. You cannot give more than one input field in a form the same ID value. ID values are also case-sensitive, so check your work carefully. Note that the name and ID of an input field are not the same thing. The input field must have both a name and an ID in order to work correctly with the label. Here is a sample of HTML for a text field that uses the <label for=""> tag:
<label for="fname">First Name:</label>
<input type="text" name="firstname" id="fname" size="20">
Another common mistake that designers make is to use the <label for=""> tag correctly, but to forget to put text in it! So, the code checks with an automatic checking tool, but the user is not helped at all. Don't forget to label the control with meaningful text.
After labeling each input field properly, read through the form using a screen reader. Make sure that the labels actually make sense; the answers alone will not do the trick. You want to make sure that the screen reader reads the questions, too. Check boxes labeled "French, Italian, Russian" might be requesting information about the user's national heritage, or something else entirely. There are two ways to handle this problem. One is to enclose the question as part of the first option's label. For example:
<label for="French">What is your favorite type of salad dressing?<br>
French</label> <input id="French" type="checkbox" name="dressing1" value="checkbox"><br>
<label for="Italian">Italian</label> <input id="Italian" type="checkbox" name="dressing2" value="checkbox"><br>
<label for="Russian">Russian</label> <input id="Russian" type="checkbox" name="dressing3" value="checkbox">
Now, when you move to the first checkbox you'll hear, "What is your favorite type of salad dressing? French checkbox not checked." If you were taking a multiple-choice quiz set up using this approach, you would hear the question combined with the first choice of response each time you arrive at that first option.
The other approach is to use a "fieldset" tag, and then create a "legend" for the fieldset. A fieldset tag groups several different input fields together.
<fieldset>
<legend>What is your favorite type of salad dressing?</legend><br>
<input id="French" type="checkbox" name="dressing1" value="checkbox">
<label for="French">French</label><br>
<input id="Italian" type="checkbox" name="dressing2" value="checkbox">
<label for="Italian">Italian</label><br>
<input id="Russian" type="checkbox" name="checkbox3" value="checkbox">
<label for="Russian">Russian</label>
</fieldset>
Although this method is cleaner than the first method, it is not supported by all forms and versions of assistive technology. For example, JAWS 5.0 reads the form just presented 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 types of salad dressings, without the question in both instances. If you want your form read by the widest variety of users, use the first method.
Avoid Radio Buttons
Radio buttons are a form of input field that presents the user with a group of options that can be chosen by clicking on a button. You can select only one radio button at a time. When you select another button, the original button is deselected. Radio buttons are not supported consistently by all versions of browsers, screen readers, and combinations of the two. Even a correctly labeled and tagged set of radio buttons is a very difficult control for users of screen-reading technology. The problem is that in order to hear the radio button options, you must land on one of the buttons. But the very process of landing on the radio button (shifting the browser's focus to it) will "push the button," changing your selection. If a "choose only one" situation is called for, a select menu is preferable.
If a web designer cannot be convinced to avoid radio buttons, then the radio buttons must be coded correctly. Each radio button in a series should have the same name, but a unique ID. Therefore, each radio button in a series should have a unique label. As mentioned before, another helpful approach is to enclose the radio button options in a fieldset, and then add a legend to the fieldset. Here is an example of properly coded radio buttons:
<fieldset>
<legend>Sex</legend><br>
<input id="male" type="radio" name="sex" value="male">
<label for="male">Male</label><br>
<input id="female" type="radio" name="sex" value="female">
<label for="female">Female</label><br>
</fieldset>
Select Menus
The default item in a select menu should clearly define the purpose of the box. For example, "Select your age range" is more self-explanatory than simply diving in with "18-25." Many screen readers and browsers fail to connect the label with the select menu, so, when users tab to it, they may never hear the label. The options inside the select menu are always read, though, so the first item should explain the purpose of the menu. And, as described in the Keyboard Accessibility section, make sure select menus work with the keyboard as well as with the mouse.
Tables
Many web forms are designed using a table structure, with labels in the left-hand column and input fields in the right-hand column. Remember to mark up structure, not appearance. Use the table summary meaningfully. People are going to read it. If the table has headings, then be sure to use the "scope" attribute to let users know if the heading corresponds to a vertical column (scope="col") or a horizontal row (scope="row").
Buttons
Standard buttons are automatically accessible--no special labeling is required. But if a fancy, graphical button is used, an alt tag (alternative text that describes the image) must be supplied. Always provide a button to submit forms. Don't use JavaScript to automatically submit them.
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, see the fact sheet "Designing an Accessible Web Site" in the Web Accessibility section of the American Foundation for the Blind's web site, <www.afb.org>, or visit the World Wide Web Consortium's Web Content Accessibility Guidelines at <http://www.w3.org/TR/WCAG10/>.
