Introduction to Keyboard Accessibility
Something to Think About...
Ensure that all content can be accessed with the keyboard alone.
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.
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.
positioning. Some WYSIWYG (What
You See Is What You Get) editors, such as Dreamweaver and GoLive,
allow Web designers to easily create absolute-positioned
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
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
to the tag. For example,
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.