WWW Cantor Access Inc.

Escaping the Mousetrap:
An Evaluation of the Accessibility and Usability of the Windows Keyboard-only Interface

Copyright © Alan Cantor 1999. All rights reserved.

Alan Cantor, B.Ed., M.A.
President
Cantor Access Inc.

Overview

Abstract

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.

Background

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 [1]; 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:

1. Microsoft incorporated hundreds of keyboard shortcuts into Windows 95, 98 and NT. See, for example, the Microsoft Windows Keyboard Guide [2] for an exhaustive list of keyboard conventions supported by the Windows operating system and most 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. MouseKeys, the mouse emulation software bundled with Windows, transforms the numeric keyboard into a virtual mouse. Mouse emulation software is indispensable for people who cannot handle a mouse when using applications that lack full keyboard support.

Objective

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:

1. Is the keyboard-only interface accessible? It is possible for individuals who cannot — or choose not to — use a mouse to perform tasks that are usually done by pointing and clicking?
2. Is the keyboard-only interface usable? Can applications be used effectively sans mouse? Keyboard equivalents for many functions exist, but are they usable in practice, without resorting to mouse emulation software?
3. What must software designers know to construct an accessible and usable keyboard-only interface? What can developers do to ensure that applications work equally well with and without a mouse?

Approach

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.

Discussion

MouseKeys vs. keyboard-only techniques

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.

Access problems associated with the Windows operating system and applications

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

Visibility problems

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:

• The focus indicator in dialogue boxes and most Web-browsing software is almost invisible. Focus is shown by a faint dotted line around the perimeter of the object. The nearly-invisible focus indicator impedes access for individuals who have mobility impairments and low-vision, for people with small monitors and laptop computers, and for those who prefer navigating by keyboard. Software designers should make the focus indicator unambiguous and conspicuous. [Endnote 1]
• In some dialogue boxes, typefaces are inordinately small. Dialogue 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. Interestingly, many adults with perfect or corrected vision report that 10-point typefaces, when presented on a computer monitor, are barely legible.
• Underlined access keys are sometimes illegible, especially in dialogue boxes with extremely small typefaces. Narrow or small letters or numbers, such as "i," "l," and "1," are poor choices for access keys and should be avoided.
• Some dialogue boxes are visually busy. The Word 97 "Open" dialogue 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. Crowded dialogue boxes complicate access for people with visual impairments and certain learning disabilities.
• 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 already available.
• When activating the taskbar using keyboard shortcuts, Windows gives no visual indication that the taskbar has been reached.
• 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 cause of frustration for individuals who rely on keyboard-only techniques.

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 keyboard techniques for a pointing device to complete a task. Some examples:

• Many features cannot be accessed without pointing and clicking. Ironically, a large version of the Accessibility status window (described above) can be activated only by mouse [Endnote 2]. In addition, many mainstream applications have features that cannot be activated without a pointing device. In Word 97, for example, a number of screens and menus ignore navigational keystrokes.
• There are too many ways to move focus between tabbed pages in a dialogue box. The two "standard" methods are 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. A single method for moving focus between tabbed pages that always works is needed.
• Many essential keyboard shortcuts are onerous. For example, to move the focus from the current task to the desktop, press Ctrl + Esc, Esc, Shift + Tab. To activate the shortcut menu for the desktop (when a desktop icon was not previously selected), press Ctrl + Esc, Esc, Shift + Tab, Shift + F10. If a desktop icon was previously selected, the sequence is Ctrl + Esc, Esc, Shift + Tab, Home (or End, PgUp, or PgDown), Ctrl + spacebar, Shift + F10. These tasks can be done easily using the two new Windows keys, but shortcuts based on these keys are not available on many alternative keyboards that people with disabilities use. [Endnote 3] 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 a file icon is selected in a folder or Windows Explorer, the "File" menu lists two items called "New." To further confuse matters, two items, "New" and "Send To," share "N" as an access key.

Functional problems

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:

• There is no tolerance for error when using keyboard-only techniques to select an unavailable menu item. When a user clicks an unavailable menu item with the mouse (say, "Edit | Paste" when the clipboard is empty), the Edit menu stays open. When an unavailable item is selected by keyboard, the "Edit" menu closes. The keyboard-only technique should have the same tolerance for error as the point-and-click method.
• 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, and an alternative means to put focus on the menu bar should be established.
• Software manufacturers regularly ignore keyboard interface standards. Recent releases of WordPerfect and Eudora Light do not reserve Shift + F10 for the shortcut menu, and have dialogue boxes that do not close when Esc is pressed.
• It is awkward to search for an item in a list box, extended selection list box, and similar control (e.g., the folder/file list in My Computer, Windows Explorer, an "Open" dialogue box, or on the desktop). To search for and select an item, quickly type the name (or the first few letters of the name). If the user cannot type fast enough or hesitates while typing, the search is cancelled and begins anew with the next character typed. The cutoff time is about one second, and cannot be adjusted. Better search-by-typing routines are needed.
• It is not possible to reverse the order of a sorted list using keyboard-only techniques in My Computer, Windows Explorer, and the folder/file list in an "Open" dialogue box, etc. (To reverse the sort order using the mouse, click on a column header.)

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.

Conclusion

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:

• Correct the problems identified in this paper.
• 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 dialogue box, Ctrl + S to save, and Ctrl + A to select all.
• Urge software authors to create keyboard equivalents for mouse-intensive tasks. Many tasks that are commonly assumed to require the mouse can be controlled quickly and easily by keyboard. Word, for example, includes several poorly-documented keyboard commands that simplify text selection [Endnote 4]. To illustrate the possibilities of an exemplary keyboard interface, I have developed Visual Basic macros that allow, in Word, precise adjustments of kerning, leading (spacing), inter-paragraph spread, hanging paragraph indent, and other typographical adjustments that usually require mouse-driven graphic design software.

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:

1. Ensure that important information, especially the focus, is always conspicuously visible.
2. Ensure that all parts of the application can be reached as easily by keyboard as by mouse.
3. Ensure that all features are as easy to use with or without a mouse.

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.

References

[1] 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/resnapap.htm.

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

Endnotes

Endnote 1: The Opera Web-browser, version 3.5, features an exemplary hypertext link indicator.

Endnote 2: To activate the large status indictor, 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 3: Alternative keyboards that lack the two new Windows keys include the Tash Winking and Winmini, the Intellitools Intellikeys, the Left-Handed keyboard, the Pace, and the Comfort.

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.

Quick Links