This paper evaluates the accessibility and usability of keyboard-only access to Windows 95, 98 and NT. I identify the people who need a good keyboard interface; highlight barriers they encounter when using Windows without a mouse; recommend ways to improve the keyboard interface; and establish design principles that developers can apply to ensure that applications are as accessible by keyboard as by mouse.
Manipulating a mouse or other pointing device may be difficult or inefficient for "single-digit typists" — people who operate computers with a single finger, toe, or stump, or use a head-stick, mouth-stick or similar appliance ; people who are blind; have low-vision, mobility impairments that affect upper-body coordination (e.g., cerebral palsy and dystonia), mouse-induced repetitive strain injuries (RSIs), and learning disabilities that affect hand-eye coordination. Furthermore, some people without disabilities, including laptop owners and "power users," complain that the mouse can be awkward to handle. For these populations, computer access is facilitated by keyboard-only techniques.
Three recent developments give rise to the hope that the Windows environment is fully accessible without a mouse:
Notwithstanding these developments, questions remain about the viability of keyboard-only access to Windows. Windows is arguably the most mouse-intensive computer environment ever devised. Function is highly concentrated in the pointing device. The "shortcut menu," for example, is activated by clicking the secondary mouse button on a screen object. Toolbars, which are not easy to access by keyboard, are now ubiquitous. This paper explores three issues:
I conducted this research between 1996 and 1999 while performing usability and accessibility studies of software, hardware, and web-sites for private companies, and providing accommodation support services to employees and university students. My clients included several office workers with computer-induced RSIs for whom mouse work was painful, four adult students — one with dystonia, three with cerebral palsy — for whom using a standard mouse or pointing device was difficult and slow, and an adult with cerebral palsy whose most reliable control site was his left foot. He controlled his PC with his big toe.
Keyboard-only access is always possible using MouseKeys. However, not everybody can use MouseKeys, and the technique is cumbersome at best. A simple drag-and-drop operation can use ten different keys and dozens of keystrokes. Choosing an item from a pull-down menu is easier, but still tedious.
To use MouseKeys to advantage, a single-digit typist must also use StickyKeys. StickyKeys allow a user to regulate mouse pointer speed. Combining StickyKeys and MouseKeys, however, is extremely complex. For example, to select a columnar block of text in Word 97, lock the Alt-key (press Alt twice), lock the drag lock button (press keypad-Insert), and use the directional mouse keys to select text. When the text block is selected — but before acting on it — unlatch the Alt-key and drag lock (press Alt and keypad-Delete). To increase the pointer speed, lock the Ctrl-key (press Ctrl twice) at the start of the process, and unlock it (press Ctrl) at the end. To slow the pointer, use the Shift key.
Keyboard shortcuts, by contrast, are quick and positive. For example, in Word 97, Ctrl + Shift+F8 toggles Column Selection mode. To cancel any dialogue box, close any window, or exit from any application, press the three-key sequence Alt, spacebar, C. (It is not necessary to hold down the Alt-key.) Keyboard-only techniques save time, energy and frustration. Using MouseKeys, one of my clients took 20 to 30 seconds to select an item from a menu. Using keyboard shortcuts, she completed the task in under two seconds.
Skilled keyboard-only users work significantly faster than people who rely on MouseKeys. Mastery of the keyboard interface, however, does not come easily, for reasons that will become clear.
Although Window's keyboard-only interface has many outstanding features, the goal of reliable access remains elusive. Some aspects of the keyboard interface appear to be retrofits, and consequently, are poorly integrated into the overall design of the operating system.
In addition, significant barriers stem from developers who ignore keyboard interface design guidelines, such as the standards set out by Microsoft , Vanderheiden & Lee , and others. Although keyboard-only access is almost always possible, it is not particularly usable.
Paciello  defines product usability in terms of five factors: (a) how easy it is to learn; (b) how easy it is to remember; (c) whether it promotes productivity; (d) whether it reduces the chances of error; and (e) user satisfaction. Access barriers associated with the Windows operating system and many applications render the keyboard interface less than usable.
The practical problems associated with using the keyboard-only interface are of three kinds: important information is hard to see, navigation by keyboard is overly complex, and operations do not work properly.
Efficient use of the keyboard interface depends on the ability to immediately spot the focus and pick out important information on a busy screen. For keyboard-only users who can see, detecting information on the screen may not be easy:
Navigational complexity refers to difficulties moving around or performing tasks using keyboard equivalents. The threshold of navigational complexity is reached when an experienced user is compelled (or forced) to abandon keyboard techniques for a pointing device to complete a task. Some examples:
Functional problems refer to access barriers that result from poorly designed or implemented software. In other words, a feature does not work as expected, or using it causes unexpected errors. Some examples:
These problems (and others) create significant and needless obstacles for people who demand mouseless access to Windows. The barriers are maddening to the people I have taught keyboard-only techniques, and are completely unnecessary: the principles of accessible software design are widely known.
With recent software upgrades, there have been incremental improvements in keyboard-only access; but there have been setbacks as well. Menu selection in Office 97 applications, for example, is more complex than in previous versions. In earlier versions, the System menu and Document menu were functionally part of the menu bar. The Document menu appeared to the left of the File menu as an unlabelled icon (itself problematic), and could be reached from the File menu by pressing the left arrow. The System menu was located to the left of the Document menu, and could be reached from the File menu by pressing the left arrow twice, or from the Help menu, by pressing the right arrow once. In Office 97, the System menu (also unlabelled) is no longer part of the menu bar. Whereas in the past there were several ways to reach the System menu via keyboard, now there is only one (Alt+spacebar). The design of the Office 97 menu bar and System menu complicates access by limiting the means by which users select menus.
These navigation complexities are compounded by a newly-created visibility problem. In early versions of Office, the menu bar and the selected menu title appeared as contrasting colours. Beginning with Office 97, the menu bar is grey and the selected menu title appears as a raised grey button. The lack of contrast has created a new access barrier for keyboard-only users: it is hard to tell when the menu bar has focus.
The keyboard-only interface of Windows is basically accessible, but not usable. Once mastered, the interface boosts productivity; but on other measures of usability, the design fails: it is hard to learn and remember, produces unnecessary errors, and does not promote user satisfaction. Of the more than a dozen adults to whom I have taught mouseless techniques, only one continues to use them regularly.
The mouseless interface could be much better. These measures should go far to improving the keyboard-only interface of future versions of Windows:
When creating or upgrading applications, developers should attend to the three kinds of problems that keyboard-only users encounter. These problems can be expressed as design principles:
The difficulties associated with the Windows keyboard-only interface are symptomatic of a larger problem. Windows is a rich and complex computer environment, but its organizational and operating characteristics are not as "intuitive" as Microsoft's promotion materials would have us believe. Many aspects of the overall design could be improved by adhering to the cardinal Universal Design principle: consider all intended users. Significant improvements to the interface, both to people with and without disabilities, are achievable if developers and manufacturers consult with people who demand keyboard-only access. Such collaborations would result in applications that are easier to learn, easier to remember, promote productivity, reduce error, and increase user satisfaction.
 Cantor, Alan. An Evaluation of Keyboard-only Access to Windows for "Single-Digit" Typists. In RESNA `97 Proceedings. Rehabilitation Engineering and Assistive Technology Society of North America Annual Meeting, June 20-24 1997. Pittsburgh, PA. An updated version appears at http://www.cantoraccess.com.
 Snyder, Maryanne K. & Lowney, Gregory C. Microsoft Windows Keyboard Guide. October 17, 1996.
 No author. The Microsoft® Windows® Guidelines for Accessible Software Design: Creating Applications That Are Usable by People with Disabilities. Redmond, WA.: Microsoft Corporation. May 7, 1997 Edition.
 Vanderheiden, G. C. & Lee, C. C. Considerations in the Design of Computers and Operating Systems to Increase their Accessibility to Persons with Disabilities (Version 4.2). Madison, WI.: Trace R&D Center. 1988.
 Paciello, Michael. Accessibility By Any Other Name Is ...Usability. EIA/CEG "CE Network News." December 1993.
Endnote 2: To activate the large status indicator, click the secondary mouse button on the accessibility status indicator in the system tray, and choose "Show Status Window" from the menu. Apparently, this problem will be fixed in Windows 2000.
Endnote 4: There are approximately 1000 built-in commands in Word, most of which have no keyboard equivalents and do not appear on any menu or toolbar. Poorly-documented text selection commands in Word include a command to select columnar blocks of text, and two commands to expand (or shrink) a selection by a character, word, sentence, paragraph, section, or document.