Home / Publications / Keyboard Access / Avoiding the Mousetrap

Avoiding the Mousetrap:
An Evaluation of Keyboard-only Access to Windows

Copyright © Alan Cantor 1998. All rights reserved.
This paper was presented at the 13th CSUN Technology and Persons with Disability Conference, Los Angeles, on 18 March 1998.


This paper evaluates the usability of keyboard-only access to Windows 95. It establishes requirements for Windows-compatible expanded keyboards; determines whether keyboard shortcuts are usable in practice; highlights barriers faced by people who cannot easily use a mouse or other pointing device; and recommends ways to improve the keyboard-only interface.


Manipulating a mouse or other pointing device may be difficult or inefficient for people who operate computers with a single finger, toe, or stump, or use a head-stick, mouth-stick or similar appliance; have mobility impairments that affect upper-body coordination, such as cerebral palsy and dystonia; have mouse-induced repetitive strain injuries (RSIs); have low-vision; and are blind. For these populations, computer access is facilitated by keyboard-only techniques.

Three recent developments give rise to the hope that the Windows 95 environment is accessible without a mouse:

  1. Microsoft incorporated hundreds of keyboard shortcuts into Windows 95 and NT. See, for example, the Microsoft Windows Keyboard Guide [2] for an exhaustive list of keyboard conventions supported by the 95 and NT operating systems and most Windows applications.
  2. Microsoft encourages software developers to build programs that can be operated by keyboard alone. The Microsoft Windows Guidelines for Accessible Software Design [3] urges software authors to “[v]erify that all features can be used without a mouse."
  3. Windows 95's mouse emulation software, MouseKeys, transforms the numeric keyboard into a virtual mouse. Mouse emulation software is indispensable when using applications for which keyboard equivalents do not exist. Greater speed and control are achievable by using MouseKeys and StickyKeys together.


Notwithstanding these developments, questions remain about the viability of keyboard-only access to Windows 95. This paper explores three issues:

  1. Is the keyboard-only interface compatible with expanded keyboards? "Single-digit typists" — individuals who type with a single finger, toe, or stump, or who use a head-stick, mouth-stick or similar appliance — often benefit from using extra-large or compact keyboards. See Cantor [1]. Three expanded keyboard systems were tested for compatibility with Windows 95's keyboard-only interface.
  2. Is the keyboard-only interface usable? 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. Although keyboard equivalents for many mouse functions exist, the question remains as to whether they are usable in practice, without having to rely on mouse emulation software.
  3. How efficiently and effectively can applications be used sans mouse when software developers fail to provide a good keyboard-only interface?


This research was conducted between 1996 and 1998 while I provided accommodation support services to people with disabilities. The clients included:

  • An office worker 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.
  • An adult with cerebral palsy whose most reliable control site was his left foot. He typed with his big toe.


Access problems with expanded keyboards for single-digit typists

As potential buyers of expanded keyboard systems, the question of "mouseless" access to Windows is especially relevant to single-digit typists. Are commercially-available expanded keyboards compatible with Windows 95's keyboard-only interface?

While developing accommodations for the client who typed with one toe, we considered three expanded keyboard systems: the Intellitools IntelliKeys, the TASH WinKing; and the Unicorn Model II keyboard/Darci Too Computer Control Device.

Not all expanded keyboards are equal to the task of keyboard-only access. We determined that the keyboard interface is fully functional only if (a) the expanded keyboard has all 101 keys of a standard PC keyboard; (b) it supports latched and locked modifier keys, singly and in combination, with all keys, including mouse keys; and (c) its proprietary sticky key and mouse emulation software, if they exist, can be switched off. Access is compromised unless all three criteria are met.

Of the three keyboards, the IntelliKeys alone satisfied the criteria. However, other factors — relating to the size and spacing of the keys and the client's seating posture — compelled him to choose the Unicorn/ Darci Too system. He liked the bigness of the Unicorn, and was willing to trade a modicum of function for long-term physical comfort. With considerable effort, we were able to create workarounds for most of its incompatibilities with Windows 95.

There is no "perfect" expanded keyboard for single-digit computer work. When helping a single-digit typist select a new keyboard, tradeoffs must be made between productivity, technical features, health and safety factors, and personal preferences.

MouseKeys vs. keyboard shortcuts

Keyboard-only access to Windows 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 take 30 or more keystrokes. Choosing an item from a pull-down menu is easier, but still tedious.

Keyboard shortcuts, by contrast, are quick and positive. For example, to Exit from any Windows application, press the three-key sequence Alt, spacebar, C. Keyboard shortcuts save time, energy and frustration. Using MouseKeys, one of my clients needed 20 to 30 seconds to select an item from a menu. Using keyboard shortcuts, she completed the same task in under two seconds.

People who progress from MouseKeys to keyboard shortcuts see a dramatic increase in their productivity. However, mastery of the keyboard interface does not come easily, for reasons that will become clear.

Access problems associated with the Windows 95 operating system and applications

Although Window 95'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 [3], Vanderheiden & Lee [4], and others. Although keyboard-only access is almost always possible, it is not particularly usable.

Paciello [5] 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 95 operating system and many Windows applications render the keyboard interface less than usable.

The practical problems associated with using the keyboard-only interface are of three kinds: important information that is hard to see, navigation by keyboard that is overly complex, and operations that do not work properly.

Visibility problems

Efficient use of the keyboard interface depends on the ability to immediately spot the focus and pick out important information. For keyboard-only users who can see, detecting information on the screen may not be easy:

  • The focus indicator in dialog boxes is almost invisible. Dialog box focus is shown by a faint dotted line around the perimeter of the object. The focus indicator should be unambiguous and conspicuous.
  • Some dialog boxes are visually busy. The Word 97 Open dialog box, for example, has 11 navigable areas and 12 buttons, making it hard to detect important information at a glance, and awkward to move around quickly.
  • In some dialog boxes, fonts are inordinately small and underlined access keys are hard to see. Dialog box text size does not adapt to system metrics; boxes are laid out by the author, and the typeface and font size are not affected by changing the Display Properties in the Control Panel. The Microsoft Windows Guidelines for Accessible Software Design recommends that developers avoid hard coding font sizes smaller than 10 points, but even this modest standard is often disregarded. Ironically, many adults who have 20-20 corrected vision report that 10-point typefaces, when presented on a computer monitor, are barely legible.
  • The insertion point in word processors and text editors is hard to see. People who have low-vision or who work at a distance from the monitor (e.g., toe typists) need a larger and/or bolder insertion point, similar to the modified system carets and mouse pointers that are available.
  • The Accessibility status window, which shows MouseKeys, StickyKeys and FilterKeys states, is too small to provide useful information to anyone with less than perfect vision. Furthermore, the StickyKey indicator does not differentiate between latched and locked states. Not knowing the states of the Shift, Alt and Ctrl keys is a frequent source of error and frustration.

Navigational complexity

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 shortcut keys for a pointing device to complete a task. Some specific examples:

  • Many features cannot be accessed without pointing and clicking. Paradoxically, a large version of the Accessibility status window (described above) can be activated only by clicking the secondary mouse button on the accessibility status indicator and choosing "Show Status Window" from the menu.
  • In Word 7, some help screens ignore navigational keystrokes.
  • There are two standard methods to move focus between tabbed pages in a dialog box: Ctrl+PgUp, Ctrl+PgDown and Ctrl+Tab, Shift+Ctrl+Tab. In some contexts, the first method works; in others, the second; sometimes both methods work; occasionally, neither method works. When the focus is on a tab selector, a third method, involving the directional arrow keys, must be used. What is needed is a single method for moving focus between tabbed pages that always works.
  • Many useful keyboard shortcuts are too onerous to be practical. For example, to move the focus from the current task to the desktop, press Ctrl+Esc, Esc, Tab, Tab. To reach the menu to rearrange the desktop, press: Ctrl+Esc, Esc, Tab, Shift+F10. Both of these tasks can be done easily using the two new Windows keys, but shortcuts based on these keys are not available, at present, on the three expanded keyboards discussed in this paper. Additional simple keyboard equivalents — preferably ones that do not involve the two Windows keys — are needed.
  • The organization of certain menus complicates access for keyboard-only users. For example, when an icon is selected in an open folder, the "File" menu lists two items called "New," and two items that use "N" as an access key.

Functional problems

Functional problems refer to access barriers that result from poorly designed or implemented software. In other words, things do not work as one might expect, which contributes to user frustration:

  • There is no tolerance for error when using keyboard-only techniques to select an unavailable menu item. When a user chooses, for example, "Paste" from the "Edit" menu before copying text to the clipboard, the "Edit" menu closes. (When the unavailable item is clicked with the mouse, the menu stays open.) The keyboard-only technique should exhibit the same tolerance for error as the point-and-click method.
  • When activating the taskbar using keyboard shortcuts, Windows 95 gives no visual indication that the taskbar has been reached.
  • Software manufacturers ignore keyboard interface standards. Recent releases of WordPerfect and Eudora Light do not reserve Shift+F10 for the shortcut menu, and have dialog boxes that do not close when the Esc key is pressed.
  • The function of the Alt-key is inconsistent. It acts both as a sticky key (e.g., during menu selection) and as a regular modifier key (e.g., the Alt+F4 Exit shortcut). The inconsistency is an annoyance because keyboard-only users often press the Alt-key inadvertently, which transfers focus to the menu bar. The sticky property of the Alt-key should be optional.

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. In Office 95, the menu bar and the selected menu title appear as contrasting colours. In 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: now it is hard to tell when the menu bar has been activated.


The keyboard-only interface of Windows 95 is basically accessible, but not especially 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 six adults I have taught mouseless techniques, only one continues to use them.

The mouseless interface could be much better. These measures should go far to improving the keyboard-only interface of future versions of Windows:

  • Correct the problems identified in the previous sections.
  • Expand the set of universal Windows keyboard shortcuts to include familiar shortcuts that are not, at present, fully supported, such as Esc to cancel a dialog box and Ctrl+A to select all.
  • Urge software authors to create keyboard equivalents for mouse-intensive tasks. Many functions that are typically controlled by mouse can be controlled by keyboard. To illustrate this capability, I have developed a set of Visual Basic macros that allow quick and precise adjustments to kerning, leading (spacing), inter-paragraph spread, hanging paragraph indent, and so on, in Word 97.
  • Strengthen the requirements for the "Designed for Windows NT and Windows 95" logo so that software authors are obliged to incorporate comprehensive keyboard controls into their products.

The difficulties of the keyboard-only interface are symptomatic of a larger problem. Windows is a rich and complex computer environment. Its organizational and operating characteristics have not matured to the point where the environment is 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 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.


[1] Cantor, Alan. An Evaluation of Keyboard-only Access to Windows for "Single-Digit" Typists. In RESNA `97 Proceedings. Rehabilitation Engineering and Assistive Devices Society of North America Annual Meeting, June 20-24 1997. Pittsburgh, PA. An updated version appears at http://www.cantoraccess.com.

[2] Snyder, Maryanne K. & Lowney, Gregory C. Microsoft Windows Keyboard Guide. October 17, 1996.

[3] 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.

[4] 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.

[5] Paciello, Michael. Accessibility By Any Other Name Is ...Usability. EIA/CEG "CE Network News." December 1993.