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 unexpected 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) follows a consistent pattern.
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.
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.
Add the "required" attribute to critical input fields. Having the required attribute gives screen readers and browsers a programmatic definition and will give more standardized interactions such as a native browser indicator if you try to submit something without entering information into a required field. The screen reader will also announce required when that attribute is present.
It doesn't hurt to make the word "required" part of the visible text in the label as well, just be aware that screen reader users may get a redundant announcement. However, this practice will benefit users who have low vision or who are color-blind. It is also helpful to users with cognitive disabilities.
In general, being consistent and logical in form design will help all users.
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.
Fieldsets
Checkboxes and radio buttons are common controls, 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' or radio buttons' labels include only the answers ("yes" and "no," for example), 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
The best approach to the checkbox or radio button problem is to include them in 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. This way, the overall question gets automatically announced by the screen reader.
Fieldsets are also useful for dividing forms into different sections. This is helpful when you have repeating fields such as a mailing address and billing address section, which would both contain the same fields.
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, your web forms will be much more accessible to users who are visually impaired.
For more help, check out our Web Accessibility Resources page.
