>From the web page
http://www.interlog.com/~acantor/www8.htm
Escaping the Mousetrap:
An Evaluation of the Accessibility and Usability of the Windows
Keyboard-only Interface
Copyright (c) Alan Cantor 1999. All rights reserved.
Alan Cantor, B.Ed., M.A.
President
Cantor + Associates
Workplace Accommodation Consultants
32 Queensdale Avenue
Toronto Ontario M4J 1X9 Canada
phone 416 406-5098
fax 416 406-5498
[log in to unmask]
http://www.interlog.com/~acantor
Developers Day, WWW8, Toronto, Ontario, 14 May 1999
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:
* 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.
* 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."
* 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:
* 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?
* 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?
* 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:
* Ensure that important information, especially the focus, is
always conspicuously visible.
* Ensure that all parts of the application can be reached as
easily by keyboard as by mouse.
* 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.interlog.com/~acantor/resnapap.htm.
[2] Snyder, Maryanne K. & Lowney, Gregory C. Microsoft Windows
Keyboard Guide. October 17, 1996.
[3] No author. The Microsoft(R) Windows(R) 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.
Go to top of page.
Go home.
RSI prevention.
Core services.
Publications.
Upcoming presentations.
Contact us.
----------
VICUG-L is the Visually Impaired Computer User Group List.
To join or leave the list, send a message to
[log in to unmask] In the body of the message, simply type
"subscribe vicug-l" or "unsubscribe vicug-l" without the quotations.
VICUG-L is archived on the World Wide Web at
http://maelstrom.stjohns.edu/archives/vicug-l.html
|
