Design for keyboard access

One of the primary requirements for universal usability is keyboard accessibility. Some users prefer or are required to use the keyboard to operate a computer. Keyboard users include nonvisual users who cannot see the screen to point and click, and users who control the computer using alternate input devices, such as a switch device or voice commands. To work with Web pages, these users must be able to accomplish all tasks using the keyboard.

On the most basic level, interactive controls must be operable from the keyboard. Any time a control requires the use of a pointing device, such as a mouse, keyboard-only users are immobilized because they cannot point and click. Users must be able to select menu items, activate links and buttons, and fill in and submit form fields using the keyboard (Figure 1.7).

Figure 1.7: Oxo screenshot

Figure 1.7: The product order page on the OXO site has site links, a search feature, links to other product categories, an order form, and more. For universal usability, all these functional elements must be accessible from the keyboard.

But keyboard accessibility extends beyond functionality. Controls must be logical, self-explanatory, and must function according to user expectations.

Keyboard users can use the tab key to cycle through actionable elements on a Web page. For efficient tabbing, the “tab order” of a Web page must follow a logical sequence. Tab order is generally determined by the order in which elements appear in the code. While it is possible to define tab order using the TABINDEX attribute, the best approach is to construct pages so actionable elements follow a logical sequence in the code. For instance, site links and section links should precede page links, and footer links should appear last in the code. Form fields should follow a logical and customary sequence: for example, first name, last name, and email address (Figure 1.8). In addition, related elements must be grouped: For instance, all section navigation links should be grouped together in the code.

Figure 1.8: AnyWho screenshot

Figure 1.8: For keyboard accessibility, links and form elements must be clearly labeled and follow a logical sequence, as on the AnyWho lookup form for businesses and individuals.

Another aspect of designing for keyboard access is the labeling of interactive elements. For keyboard access, these elements must be understandable without the surrounding context of the page, because users may choose to access page controls directly rather than within the page by, for example, tabbing directly to links or form elements. Self-explanatory controls allow keyboard users to understand the purpose and function of each control without having to expand their focus to the surrounding context. Links that are labeled “Click here” are not self-explanatory, whereas links that are labeled to describe the target are. Form fields without labels are not self-explanatory, whereas form fields labeled using the LABEL FOR tag are. Design pages to be usable via links and form elements.

Finally, keyboard accessibility depends on keyboard controls functioning in a manner that is consistent with user expectations. Keyboard control of Web pages is based on a simple functional paradigm: Elements are selected using the tab or arrow key, and selected elements are activated using the return or enter key. Whenever controls use different event triggers—for example, menus that activate when an item is selected or buttons that respond to mouse clicks—keyboard accessibility suffers. Make sure all functional elements respond to the select-activate keyboard interface.