Keyboard Accessibility
Introduction to Keyboard Accessibility

Something to Think About...

Keyboard accessibility is one of the most important aspects of disability access. Blind people generally cannot use a mouse because they cannot see where to click. They use their keyboard almost exclusively. (Some legally blind people have limited residual vision which allows them the use of a mouse if the page is enlarged and the contrast is high.)

Some individuals with neuromuscular impairments cannot use a mouse either. Some have tremors which don't allow for fine muscle control. Others have little or no use of their hands, due to a spinal cord injury, brain damage, or some other cause. Some people simply do not have hands, whether due to a birth defect, an accident, or amputation. There is an almost limitless list of conditions that could make mouse usage difficult or impossible.

Those who cannot use a mouse may not be able to use a keyboard either. Some use "puff and sip"devices activated by airflow from the mouth. Others use single-switch devices - consisting of a piece of hardware with one button that can be pushed. These devices are sometimes configured to interpret Morse code, which the person performs by tapping on it. One thing that all of these devices have in common is that they interact with the computer in a way that mimics the functionality of the keyboard. If a Web site is not keyboard-accessible, you will shut many people out.

Potential Problems

JavaScript DHTML menus. Despite its flashy appearance, dynamic HTML (DHTML) is rarely keyboard-accessible. One popular application of DHTML is to create menus that appear when the mouse rolls over them (for an example of this technique, see http://www.microsoft.com/windows/ - external link, using Internet Explorer in Windows, or http://www.franklincovey.com/foryou/ - external link).

The menus are slick ways of keeping the interface simple and uncluttered, while also allowing the user to quickly locate the desired content with a minimum number of clicks. The down side is that none of the functionality is available without a mouse. The DHTML menus can't be made directly accessible with current technologies, but there are workarounds.

Microsoft provides a prime example of an effective workaround strategy. Microsoft's DHTML menus are designed to work only on Internet Explorer in Windows. Presumably Microsoft did this to make Internet Explorer look better than the competition. The programmers knew that not everyone visiting their site would be using Internet Explorer. Some people use Firefox, Opera, Lynx, or other browsers. The programmers realized that they needed to provide a redundant menu system that was accessible to the non-Microsoft browsers. Their solution was to place plain text links on the destination pages that contain identical menu options as the ones in the DHTML menus. As long as the links and functionality produce the same results without extra hardship, this is an acceptable solution from an accessibility standpoint. Some people will use the DHTML menus, and others will use the redundant text links.

WYSIWYG absolute positioning. Some WYSIWYG (What You See Is What You Get) editors, such as Dreamweaver and GoLive, allow Web designers to easily create absolute-positioned div or span elements which can be dragged around and repositioned with the mouse. The process of repositioning changes the visual layout, but does not change the order of the elements in the code. The result can be that the structural reading order and tab order do not match the visual reading order. When a person uses the keyboard to navigate through the links on a Web page (in most browsers this is the Tab key), the tab order is unorganized and out of sequence with the visual order.

Keyboard Accessibility Enhancement

Specifying the tab order. For the most part, Web developers don't need to worry about specifying the tab order of the elements on their Web pages. Well designed pages and/or tables usually have a built-in logical tab order. At times, though, a page—especially a page with forms—can benefit by assigning the tab order to form controls and/or links. To specify the tab order of an element, add a tabindex attribute to the tag. For example, tabindex="1", tabindex="2", etc.

Providing keyboard shortcuts. This feature is rarely used, so most users do not expect a page to have keyboard shortcuts. Perhaps over time this feature will become more popular, but the wide variation between Web page interfaces, combined with the decentralized nature of the Web, and the disparity between the skills of Web designers makes the implementation somewhat problematic. The shortcuts are specific to the page or site on which they reside. In addition, there is no standard method of alerting the user to the presence of the shortcuts. In contrast, the convention for non-Internet programs on the Windows platform is to underline the letter of the shortcut key. This convention wouldn't be appropriate on the Web, since underlined elements usually suggest a link. Another potential drawback of keyboard shortcuts is that they may interfere with the shortcuts of the browser, operating system, or assistive technology (e.g. screen reader or screen enlarger) that the person is using. Despite the potential negative aspects of keyboard shortcuts, the potential benefit is that a user can immediately jump to the desired destination or perform the desired action by pressing a key.