Thread Subject: Shortcuts in documentation - data gathering(long)
Note
This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.
Return to this mailing list's archives
From: Whitney Quesenbery
Date: Thu, Feb 22 2007 10:20 AM
Subject: Shortcuts in documentation - data gathering(long)
<html>
<body>
Hello,<br><br>
This is a report back on some data gathering I did on documenting access
features (esp. keyboard shortcuts) in product documentation.<br><br>
I asked a question on a documentation/usability list to gather some info
on current thinking and practice in documenting keyboard
shortcuts. I expected better awareness than I found.
<br><br>
I asked the question without mentioning accessibility. Even people
who were careful about audience analysis and had clearly thought
carefully about documentation and usability were not focused on the needs
of people with disabilities. A few people mentioned that keyboard
shortcuts can be "discovered" in the user interface, clearly
showing that they were not thinking about accessibility.<br><br>
Note that this is a very small sample - <10 people on one list -
but the responses do illustrate the problem with providing
"accessible documentation on accessibility features." <br><br>
(I'm still doing the literature search, but there is not much so
far.)<br><br>
<br>
<b>1. Avoid repetition<br>
</b>There was general agreement that "four is too many", but
many people thought that two primary methods was acceptable. <br><br>
"A menu sequence, a keyboard shortcut, a right-click popup menu
option, and a toolbar icon. Would it be practical for us to include all
four options in a procedure every time multiple options exist? No
way!"<br><br>
<br>
The advice often boiled down to putting shortcuts and
"alternate" (eg. non-mouse) navigation in one place, most
commonly "a table" or "an appendix" - it is not
always clear if they are talking about online documentation, or how easy
it would be to navigate to this information. <br><br>
"It is always a good idea to have a reference topic for keyboard
shortcuts, clearly delineated as such."<br><br>
Some mentioned introducing all of the control options, to make readers
aware of their options, but usually in an introduction and not in all of
the procedural topics.<br><br>
"In the "user orientation" section of the documentation,
where the goal is to familiarize users with the system and the various
options for navigating and using the system, we actually often DO provide
all four means, just so they get the idea that they do in fact have
options and can adopt whichever one appeals to them the most. For
instance, to open a file, a typical procedure in this orientation<br>
material might go something like this:<br>
<x-tab> </x-tab>1. Perform
one of the following actions:<br>
<x-tab> </x-tab><x-tab>
</x-tab>* From the File
menu, select Open.<br>
<x-tab> </x-tab><x-tab>
</x-tab>* Press
CTRL+O.<br>
<x-tab> </x-tab><x-tab>
</x-tab>* Click the Open
File (<sample graphic>) icon.<br>
<x-tab> </x-tab><x-tab>
</x-tab>* Right-click in
the workspace, and from the context<br>
menu, select Open."<br><br>
They often seemed oriented towards printed documents, and to shortcuts as
a productivity option.<br><br>
"Regarding putting a list in the appendix--the user can print the
list out and use it as a reference. That's better than nothing--but as a
user I would definitely prefer to have the keyboard shortcuts right there
in the procedures."<br><br>
<br>
<b>2. Tailor the documentation to the "most common"
audience."<br>
</b>This could go either way, but the focus was always on use of the
application or business audience, not different personas within that
audience.<br><br>
"First, the most common (primary) navigation mode.... The
documentation is oriented to<br>
this mode. For example, Click Save."<br><br>
"I write for a business audience--users who were hired to do a job
and do it efficiently. So I list the keyboard shortcut first in the
documentation, then the slower way (e.g., Press F3 or click Exit [with
picture of icon]). Just providing those two options doesn't seem to make
it too cluttered."<br><br>
<b>3. Focus on the "most common" tasks<br>
</b>This was a secondary theme, but could lead to the most advanced
features, or those not easy to access in the control information
architecture being doubly hidden.<br><br>
"..include the shortcut when you are reasonably certain that the
feature will be one that is used often...For very obscure features buried
inside a sub-dialog box of a seldom used dialog box (very low frequency
of use) then don't include the keyboard shortcut in the
doc."<br><br>
"Anyway, what we do, typically, within a procedure is just to
provide whichever option seems to be the most efficient, or the one we
*think* our users would be most likely to want to use. I admit freely
that this is both tricky and dangerous--as well as subjective--, since we
*don't* have any research to back us up."<br><br>
<br>
A few other comments:<br><br>
"It should be in a table with the left column being the tasks in
alphabetical order and the right column being the shortcut. (It
should not be in alphabetical order by the shortcut. People do not look
up "What does CTRL-A do?" They look up "What's the
shortcut for opening a file?""<br><br>
"Most Microsoft products have a list of their keyboard shortcuts in
the Help. PowerPoint lists them by "Tasks" if you search
for "Keyboard Shortcuts" and allows you to open them all so
they can be printed. The complex Siebel CRM from Oracle actually
has a good list of keyboard shortcuts at the top of the generic help
which shows common feature and navigation shortcuts."<br><br>
<br>
This all points to the need for better ways of including people with
disabilities in general usability programs. Design choices driven by user
research can only be as broad as the research that was done. As one
person put it:<br><br>
"What I have tried to do is put myself in the place of my users, as
well as I know them."<br><br>
<br><br>
<x-sigsep><p></x-sigsep>
Whitney Quesenbery<br>
Whitney Interactive Design<br>
= EMAIL ADDRESS REMOVED = <br>
phone: 908-638-5467<br>
mobile: 908-328-5959 <br>
<a href="http://www.wqusability.com/" eudora="autourl">
www.WQusability.com<br>
</a><a href="http://www.usabilityprofessionals.org/" eudora="autourl">
www.usabilityprofessionals.org</a> <br><br>
"Warning: Objects in the calendar are closer than they
appear."</body>
</html>
WebAIM is an initiative of:
