Usability considered (UA review: Resend)

[Some links needed manuel formatting, the Resend fixes that & clarifies a
few items.]

Hello,

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.

Not to say 1 technology is inherently easier to use than another, that is
determined by control design. Computer programs have great usability only if
frequently used commands are readily available without making people think
where to find command. For 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 pointer usability means 1
or at most 2 key presses execute 1 command, avoiding 3 or 4 steps to use a
menu item. In programs where Save is often used I've always put the Save
command sequence into a keyboard macro activated by F11 making Save a 1 key
command in-turn creating a usable & consistent interface for low keystroke
typing. Other 1 keystroke commands are common, in current browsers F3 is
Find, a 2nd example of a 1 key command. For more on 1 key command layout
please read my note on page
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0574.html

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

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 <A
HREF="http://www.zdnet.com/pcmag/stories/opinions/0,7802,2385241,00.html">
"Jim Seymour"</A> 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 <A
HREF="http://www.zdnet.com/pcmag/stories/reviews/0,6755,2385263,00.html">
"keyboard Internet controls"</A> in the first paragraph of its review. 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" on page
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0479.html
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} An example of that is some main browsers use Tab,
Shift-Tab, & Enter as the primary link navigation keys. That arrangement is
very difficult & too tiring to run because Tab is a vast distance away from
Enter while Shift-Tab employs 2 key pushes (which with missed keys often
becomes 4 keystrokes for people who are unsteady) to move back one link.
Accessibility requires more than merely replicating mouse clicks via another
device: ease of operation must be checked to ensure that equal usability is
provided by the Accessibility interface. For about 4 years NCSA Mosaic &
Opera have featured effective keystroke browsing establishing a de facto
standard for the existence of key-driven Web navigation building on that
foundation best enhances Accessibility.

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
illustrate
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
Guildlines.

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 here:
<A HREF="http://www.zdnet.com/pcmag/stories/reviews/0,6755,2385295,00.html">
"Speech Recognition"</A> 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 works 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. Usability
makes Accessibility a true force for independence at the computer!

Received on Sunday, 5 December 1999 20:01:58 UTC