|
Accessibility Tip:
Designing Accessible Forms
by Larisa Thomason,
Senior Web Analyst,
NetMechanic, Inc.
Webmasters spend a lot of time designing forms for readability and efficiency, but a form that looks great online may hopelessly confuse someone using a screen reader. Does your form sound as good as it looks? Could a visitor navigate through it without using a mouse? Those are two major considerations in accessible form design.
Could You Repeat That?
It's pretty easy to understand a complex form when you can look at it, but how would it sound if someone were reading aloud? A great-looking form may be completely unintelligible when someone listens to it.
JAWS, one of the most commonly used screen readers, is picky about forms. JAWS always tries to associate some piece of page text with each form field. If JAWS can't find text to associate, it either announces the presence of a form field on the page (without identifying the field) or skips the form field entirely.
But just labeling all your form fields won't solve the problem. If you've placed extraneous text between the text associated with the form field and the field itself, JAWS may read the extra text instead of the field label.
Even worse, JAWS may associate the wrong text with the form field, completely obscuring the purpose of the field to anyone listening to it. Instead of the instruction "Enter your first name" associated with a text box, how would a user react if she heard "Search the Web" instead?
Now, this isn't a JAWS-only issue! All screen readers and speech-enabled browsers can have problems reading forms that are placed inside tables. That's a reliable way to control form layout, but tables can cause accessibility problems. Form elements may be separated from their text descriptions when user's browser linearizes the table.
Structuring Forms To Be Heard
Here's a simple example of how table linearization works. Suppose you were using this form layout with the form labels placed above the input boxes:
Most screen readers and speech-enabled browsers read the cells in the order they're included in the HTML code. The example table may sound something like this:
- First name
- Last name
- Phone number
- Input box for first name
- Input box for last name
- Input box for phone number
|
It's better to place the labels directly adjacent to the form elements they describe:
With this layout, the user has a much better chance of understanding how the form is structured because the table cells read in this order when they're linearized:
- First name
- Input box for first name
- Last name
- Input box for last name
- Phone number
- Input box for phone number
|
That's much easier to understand when you're listening to the form.
Grouping Form Elements
There are other ways to make forms more accessible by grouping like form elements together using the LABEL, ID, FIELDSET, and OPTGROUP tags and attributes. We'll cover those more completely in an upcoming Accessibility Tip.
However, the grouping tags and attributes - many of which were added to HTML 4 specifically to enhance Web accessibility aren't completely supported by the major browsers. Many of the major assistive technology manufacturers don't support them completely either. While each new version includes expanded support for these techniques, keep in mind that new technology is expensive - and many people with disabilities are on severely limited budgets. Upgrading to the new version often just isn't possible.
Feel free to include tags like OPTGROUP to create more readable and attractive SELECT lists, but understand that they're no substitute for a good, basic form design.
Keyboard Accessibility
Lots of people prefer to navigate through Web sites using their keyboards whenever possible. For others, keyboard navigation isn't just an attractive option: it's a necessity. Those visitors depend on you to create a form that's easy to navigate.
Fortunately, HTML offers several different tags and attributes that improve keyboard navigation.
- ACCESSKEY: This is often referred to as a keyboard shortcut. When the visitor types the keyboard shortcut, the form element related to that shortcut becomes active and the visitor can input information.
Set the ACCESSKEY value for a form element like this:
First Name: (Alt-V)
<input type="text" name="firstName" size="15" accesskey=v>
A visitor would navigate straight to this attribute by holding down the ALT key (on a Windows machine) and pressing the "v" key.
We discussed this attribute in detail in our October 2001 Accessibility Tip.
- TABINDEX: While ACCESSKEY takes visitors straight to a particular form element, but visitors can also use the TAB key to click from element to element. By default, visitors tab through the form elements in the order they are defined in the HTML code.
The default is usually ok, but you may need to use the TABINDEX attribute to set the tab order if your form is complex.
First Name: (Alt-V)
<input type="text" name="firstName" size="15" accesskey=v tabindex=1>
The value of TABINDEX can be any number between 0 and 32767. That should take care of even the largest, most complex form!
- Remove extra elements between form controls to keep information together. For instance, you shouldn't include a "lost password" link or something else between the password input box and its descriptive text. Place those options outside the form instead.
This saves a few keystrokes between related elements. It can also help keep a screen reader from associating the phrase "Lost Your Password?" with the password input box instead of your intended "Enter Your Password Here" descriptive text.
- Use color where appropriate. Consider adding color to SELECT lists to clearly delineate the separate choices in the list.
|
Here's a sample form that incorporates these attributes. The form opens in a new browser window.
Build Forms For The Future
The ACCESSKEY and TABINDEX attributes are friendly. Browsers that don't support them yet just ignore the attributes and display the basic form instead of breaking the form layout.
That isn't true for all HTML tags. Incomplete browser support and browser-specific HTML tags may cause serious problems for your visitors. You'll have serious problems as well if frustrated visitors leave your page in disgust.
Always test your pages with NetMechanic's Browser Photo before you post them. Even a quick glance at your page in 16 different browser and operating system combinations may alert you to unanticipated problems in one or more browsers.
A good form is one that every visitor can see, understand, and use to easily transmit data to you. Remember that that each new version of browsers and other technologies adds more accessibility support. Design forms that work now - but consider how to make them even more accessible in the future. It's worth the effort to create forms that are accessible to every visitor!
|
