W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 1999

Usability considered (last call review)

From: Bryan Campbell <bryany@pathcom.com>
Date: Wed, 01 Dec 1999 18:27:54 -0500
Message-Id: <>
To: w3c-wai-ua@w3.org

This review deals with the usability of navigation tools & UA setup. As
someone with Cerebral Palsy I've typed with a headwand for 37 years, 21
years on small computers (12 years with DOS & Windows) while watching
technological developments. Use of macro programs to reduce work loads &
distances traveled over the keyboard while running programs led to
experience on optimizing keystroke commands. Checking key pad layout is a
theme with me as I can work TV & VCR remote controls (& other devices) with
my left hand if the buttons are not too small, not too far to 1 side, & have
space around them (some similar spacing also makes browser keystroke
commands more usable). Making keystroke commands most attractive is that
keyboards are system constants which work in the absence of other technology.

Which isn't to say 1 technology is inherently easier to use than another,
that is determined by the nature of the controls. Computer programs have
great usability only if frequently used commands are readily available
without making people think about where the commands are. For the purposes
of this review usability means a program can be run for hours without undue
fatigue or annoyance at the command structure. For people using 1 hand, a
few fingers, or a headwand's lone pointer usability means 1 or at most 2 key
presses execute 1 command, avoiding 3 or 4 steps to use a menu item. The
Save command is often used (in some programs) so I've always put the command
sequence into a keyboard macro activated by F11 making Save a 1 key command;
in current browsers F3 starts Find, a 2nd example of a 1 key command.

Of course, Find itself isn't so easy to use since forming search strings
entails much travel over a keyboard. For people with reduced mobility or
motor control (making typing less accurate) current keyboards are a large
area to cover so use of the whole thing is something to avoid (the Function
keys are useful enough not to switch keyboard styles). To UAs that means
some forms of Direct access wont be as beneficial as it seems at first
blush. To make it more useful the Guildline should state that Direct access
must load a link & move the link highlight to that link (as an option), then
when users return to the page they'll be in place to key to other links.
Decreasing hand travel is mentioned by Jakob Nielson on this page
http://www.zdnet.com/devhead/alertbox/991114.html he cites "Fitts' law" that
states short mouse moves are better than long ones as it is faster to click
items that are closer to your current position. Movement is basically
movement whether it is across a screen or keyboard, to me only the target
type differs as one is virtual & the other physical. When specifying what is
needed where needs some attention.

A link from Dr. Nielson's page led to ideas that should be used as guides
for placing commands & determining the usefulness of Direct access. Bruce
Tognazzini on this page http://www.asktog.com/basics/firstPrinciples.html in
a section titled "Efficiency of the user" explains that even making a system
do extra work makes people more efficient. His point is that it is faster
for a person to set a microwave oven timer for 1:11 (1 minute & 11 seconds)
than for other 3 digit times since 1:11 (or 2:22) entails no finger movement
& little thought about the next push. Making a microwave run a bit longer
takes less time than for folks to select 3 different numbers like 1:09. For
people with disabilities the ability to use one button repeatedly is much
more efficient than repositioning over a 2nd button. I say repositioning
because it gives a better sense of how people with reduced dexterity reach
the next button or key with accuracy decreasing as the distance to
subsequent keys goes up. The ease of Sequential access is underplayed in
Guildline 10.3 in a manner that could lead developers not to pursue
Sequential access enough to make it more effective! Direct access is
appealing, but the point needn't be made at the expense of other methods.
The microwave example shows that searching out a search string has its own

Important to note is that keyboards have dedicated Web keys to enhance the
Web experience. The strength of the tend is seen in Microsoft's 2 updated
keyboards with dedicated Web navigation keys: 'Microsoft Natural Keyboard
Adds Web, CD Keys' page http://cgi.zdnet.com/slink?11110:803742 Microsoft
Internet Keyboard page
http://www.winmag.com/reviews/hardware/column/1999/1099/1029.htm PC
Magazine's Jim Seymour page
http://www.zdnet.com/pcmag/stories/opinions/0,7802,2385241,00.html loves the
Internet Keyboard saying, "it's the first to win me over to the new
dedicated-button approach to using the Internet." PC Magazine's hottest
"Editor's Choice" among new PCs lists Internet keys in the first paragraph
of the review page
http://www.zdnet.com/pcmag/stories/reviews/0,6755,2385263,00.html If the
keyboards weren't built for 2 handed use they'd be getting my rugous tests.

UA developers need to be told about ideas like well laid 1 key commands to
make their programs truly usable for people with disabilities. Perhaps the
most words important I've read on the UA list are from Scott Luebking
<phoenixl@netcom.com> 30 Nov 1999 in "A couple of comments" page
Suggesting how the Guildline opens Mr. Luebking says, {Quote "It probably
should say that the guidelines can help avoid pitfalls, but it is quite
possible to follow the guidelines and still end up with an inaccessible user
agent." Unquote} Accessibility doesn't often equal usability. An example of
that is mainstreams UA using Tab, Shift-Tab, & Enter as the primary
navigation keys. That arrangement is very difficult to run because Tab is a
vast distance away from Enter while Shift-Tab employs 2 key pushes (which
often becomes 4 keystrokes for people who are unsteady) to move back one
link. That contrasts the highly usable 4 year old standard for keystroke
browsing set by NCSA Mosaic & Opera.

The hardware trend clearly endorses dedicated Web keys as have been
available in software for many years so by making 1 key browsing commands a
Priority 1 the UA Group will merely extend the trend to the folks that can
most use it! The priority is only for main UAs. Gregory J. Rosmaita
<unagi69@concentric.net> in a note to the UA Group at page
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0268.html says
that in many programs the Accessibility 'bar' is very low & that this
Guildline must bring the 'bar' to a reasonable height. Part of raising the
'bar' will only be fulfilled by stating the importance of 1 key browser
commands using the main alphanumeric character area of keyboards. The
software keyboard Mouse, "Mouse Keys", is a prime example of hugely changing
the regular interface without bothering regular users. Such options should
be very easy to turn On & then Off so that worries about 'interface
inconsistency' for regular users needlessly leads to Accessibility features
that are difficult to use.

To avoid that people with disabilities should be involved in program design
as Mr. Luebking mentioned his note (2nd link up). Yet I can see practical
difficulties in making that happen so input for efforts like this Guildline
must gleaned on indirectly created whenever possible. For keyboard issues I
can help; & point to Bill McMurray's <billmcm@earthlink.net> home page
http://home.earthlink.net/~billmcm/ remarks about Opera to give more insight
into 1 keystroke browser commands. More generally the AT professionals on
W3C WAI lists should give approximations of how people with various
disabilities run computers so developers can work from rough compasses. To
here is a way to approximate a lack of motor control: Put the keyboard
Repeat Delay to very short & Repeat rate to very fast (or whatever rate is
bothersome) when the slightest touch or accidental bump generates a key
press typing is wholly different & key combinations become a huge challenge
to say the least. We'd do well to try such experiments before writing

Most importantly such tests would allow creation of input layouts so
developers & users wouldn't have to continually reinvent the wheel.
Guildline 10.3 says users should control input which would likely be a
complex task for most folks. With the proper information to use Guildline
10.3 could say provide a selections users to choose from, that will likely
be easier for programmers to do than for UAs to have what amounts to
miniature keyboard macro programs. Guildline 4 should do the same for CSS.
Besides getting folks off to quick starts developers will receive less
questions about how to configure UAs.

As for Speech Recognition a new PC Magazine review says it succinctly on
this page
http://www.zdnet.com/pcmag/stories/reviews/0,6755,2385295,00.html Speech
Recognition works well if you have the equipment {Quote "and the ability to
speak clearly at all times" Unquote} which isn't promising for people with
physical disabilities. In preparing for the future we mustn't overlook what
now & for the mid-term.

On a specific Guildline 7 talks of *tabbing* in regard to Sequential access:
that should be changed to keying through because using the word Tab implies
uses of the Tab key itself which is too far away from other Page movement
keys. Indeed, all browser commands should be near the Cursor-Pad area where
Page Up & Down etc. are to reduce traverses across the keyboard.

Bryan Campbell

--> "Just because we call it the Web does not mean it should tangle people up!"
Received on Wednesday, 1 December 1999 18:29:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:38:24 UTC