Publishers of technology books, eBooks, and videos for creative people

Home > Articles > Design > Voices That Matter

Web Design Reference Guide

Hosted by

Toggle Open Guide Table of ContentsGuide Contents

Close Table of ContentsGuide Contents

Close Table of Contents

Usability Tips You Can Use: Designing Forms for Keyboard Access

Last updated Oct 17, 2003.

By Sarah Horton, author of Access by Design: A Guide to Universal Usability for Web Designers

Forms are what make web communication a dialogue rather than a monologue. Through forms, we converse—we pose questions, make requests, tell about ourselves. To engage in a web-based conversation, we must be able to fill out and submit forms. Otherwise, we’re back to a monologue, and what fun is that?

For a form to function, it must be operable from the keyboard, because many people use the keyboard to work the computer—and, consequently, to work with web sites. Some people find it easier and more efficient to input information and commands using the keyboard than switching between keyboard and mouse. Some people use a device that only has a keyboard, such as a cell phone. Some people can’t see the screen in order to point and click, which rules out use of any pointing device. For keyboard users, a form that calls for point-and-click interaction is inaccessible.

Fortunately, it’s easy to design forms for keyboard access. Read on to learn about the basic requirements of context, operability, and flow, and to pick up a few CSS tricks for form element positioning.

Context

Were you ever asked a question while in the middle of a daydream, and you awake to find everyone looking at you, expectant, waiting for an answer? Well, form fields are a lot like questions, and a form field without a label is a question without context (see Figure 1).

Figure 1

Figure 1

Providing context is where labels come in, and context is important for keyboard access, particularly for non-visual users. Using the keyboard, we can navigate a form using the Tab key to move between form fields. Upon arriving in a form element, visual users can scan nearby elements to establish the field context, but non-visual users may have difficulty determining what information is being requested unless the field is properly labeled. Fortunately, HTML provides a means to attach labels to form fields, using the LABEL FOR tag. Let’s modify our blank form to add a label to that text box (see Figure 2):

<form>
<label for="name2">Name:</label> <input type="text" name="name2" id="name2" /> <input type="submit" value="Submit" />
</form>
Figure 2

Figure 2

Operability

For a functional form, we need to be able to do all of the following:

  • Move between form elements
  • Enter text in input fields
  • Select menu items
  • Check and uncheck checkboxes
  • Select and deselect radio buttons
  • Activate submit buttons

To accomplish these tasks from the keyboard, we have these handy-dandy keys at our disposal (which may vary depending on which software you’re using):

  • Tab to move between elements
  • Arrow keys to move within an element
  • Spacebar to select a radio button or checkbox
  • Enter to activate a button

Example 3 is an example of a form where one would typically be able to use the up- and down-arrow keys to move within the menu and use Enter to submit the request. This is just an image of a sample form. The form here won’t actually submit.

Sometimes these basic actions don’t work from the keyboard, or don’t work the way we expect, such as when JavaScript is used to respond to actions other than those detailed above. For example, drop-down menus (such as the one shown in Example 4) are often designed to respond to the OnChange event, which triggers menu-item selection.

<form>
<select name="menu4" id="menu4" onchange="location.href=this.form.menu4[this.form.menu4.selectedIndex].value">
<option value="http://www.yahoo.com/">Yahoo!</option>
<option value="http://www.google.com/">Google</option>
<option value="http://www.dogpile.com/">Dogpile</option>
</select>
</form>

When we use the keyboard to work such a menu, we’re unable to get past the first item, since selecting a menu item by using the arrow keys triggers the OnChange event.

Many dynamic menus don’t work from the keyboard. Depending on the implementation and the browser you’re using, the menu either won’t display when activated from the keyboard or will display but won’t be keyboard-navigable. Try putting aside your mouse and accessing these sites, and see what happens:

In general, the best approach is to stick with basic form controls and behaviors—for example, use a submit button to activate a drop-down menu (see Example 5).

<form>
<select name="menu5" id="menu5">
<option value="http://www.yahoo.com/">Yahoo!</option>
<option value="http://www.google.com/">Google</option>
<option value="http://www.dogpile.com/">Dogpile</option>
</select>
<input onclick="location.href=this.form.menu5[this.form.menu5.selectedIndex].value" type="button" value="Go" />
</form>

Flow

Keyboard access to forms is a linear process defined by the order in which elements appear in the code. Access is better when form elements are grouped logically: fields grouped with labels, and similar fields coded in sequence. For more logical flow, HTML provides the FIELDSET tag, which allows you to code relationships between form elements (see Figure 3):

<form>
<fieldset>
<legend>Contact Information</legend>
<label for="name6">Name:</label> <input type="text" name="name6" id="name6" /><br />
<label for="email6">Email:</label> <input type="text" name="email6" id="email6" />
</fieldset>

<fieldset>
<legend>Account Information</legend>
<label for="username">Username:</label> <input type="text" name="username" id="username" /><br />
<label for="password">Password:</label> <input type="password" name="password" id="password" />
</fieldset>

<input type="submit" value="Submit" />
</form>
Figure 3

Figure 3

In addition to grouping, sequence is important to flow. If we use Tab to cycle through form elements, the submit control should be the last form element. When Submit comes too soon, we either miss the additional fields or have to complete them and then backtrack to submit the form (see Figure 4).

Figure 4

Figure 4

Try using Tab to cycle through the forms on the pages below. If you’re a visual user, imagine that you can’t see past the cursor—would you know there are additional fields beyond the submit button?

When designing a form, make sure that the submit button follows after all relevant input fields (see Figure 5).

Figure 5

Figure 5

Positioning

Many times, we design forms using layout tables (see Figure 6).

Figure 6

Figure 6

We use layout tables because forms are easier to scan and work with when labels and fields are aligned, rather than spilled willy-nilly down the page (see Figure 7).

Figure 7

Figure 7

Layout tables are not an obvious problem for keyboard access, but screen-reader users, who are also likely to be keyboard users, may stumble over the irrelevant table code when navigating though forms. It’s better to use CSS to align form elements, as in Figure 8.

label
{
   clear: left;
   width: 20%;
   float: left;
   text-align: right;
   padding-right: .5em;
}
Figure 8

Figure 8

Wrapping Up

There you have some tips for designing forms for keyboard access. If you’re a mouser, try putting aside your mouse for a few days and see whether pages are designed for keyboard access. You may wind up unplugging that rodent for good!

For more information on keyboard accessibility and forms, check out these sources:

Save To Your Account