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

Re: WD-WAI-USERAGENT-19991105 review

From: Bryan Campbell <bryany@pathcom.com>
Date: Fri, 03 Dec 1999 17:16:31 -0500
Message-Id: <>
To: Håkon Wium Lie <howcome@opera.com>,.w3c-wai-ua@w3.org
2:01 AM 02-12-99 +0100, Håkon Wium Lie wrote:

> > Allow the user to change and control the input configuration. Users
> > should be able to activate a functionality with a single-stroke (e.g.,
> > single-key, single voice command, etc.). [Priority 2]

>I would suggest reversing the priorties here -- it's more important
>that the UA supports (say) single-key functionality than that it
>supports an API for changing the UI.

There are enough keys to make all common browser commands 1 key commands.
Opera uses the main alphanumeric key area of keyboards to do it. Please
visit Opera's keyboard command page http://www.opera.com/keyboard.html The
software keyboard Mouse, "Mouse Keys" (which turns NumPad into 1 keystroke
mouse commands), is a prime example of using keyboards in a different manner
to give people with physical disabilities a usable command structure.
Moreover "Mouse Keys" proves that such innovation doesn't bother & perhaps
isn't even know to regular users because it can be turned On & Off or
Time-out itself. It isn't that the resources (in this case available keys)
don't exist, it feels like an unknown prevents imaginative steps to be taken
to truly enhance Web usability for people with disabilities. To illustrate
what can be with the main keyboard area an example of 1 key commands for Web
navigation follow below.


->"Cyberspace dwarfs all outer space because cyberspace is only limited by
human imagination!"

In keyboard driven browsing the page control keys just right of ENTER are
important so the Web navigation keys should be around ENTER [which gets a
link]. The enhanced keyboard is huge for anyone using just 1 digit, be it
head or hand; & key combinations add tiring, extra work while individual
keys go unused. Example: SHIFT-TAB to get the previous Anchor means 2
keystrokes which is hard as I'm unsteady (To get an idea of what how some
folks work put the keyboard Repeat Delay to very short & Repeat rate to very
fast, key combinations become a huge challenge, to say the least) & apt to
miss the desired link so it can take 4 keystrokes to pick a link. Just as
Page Up & Down are paired on the Keypad area Web navigation controls must be
paired on the main keyboard (Less movement around keyboards helps folks with
muscle degeneration as they tend to have slow or reduced mobility).

Some pairs I mean are move Anchor highlight up & down & next page & back to
previous page. Vertical or horizontal pairing might provide a cue about what
movement occurs, 
perhaps a UI designer could comment. BACKSPACE for page back & the "=" key
for page ahead. The "[" key for Anchor up and ";" key for down [this is only
for links]. Form boxes should be selected via TAB & SHIFT-TAB, for limited
use a key combo is fine because it actually lessens chances users get into
an unwanted mode. Using O or Zero seems too confusing so lets use 9 for
Previous Frame & I as Next Frame [& Anchor movements should cycle within a
Frame, not the whole page]. DHTML Layers K as Up & "," as Down with U to
Activate events. The 9, I, K, & "," keys are roughly in line vertically yet
key rows are offset so its harder to slide up or down then left or right,
where the sides of keys fully in line making a mistaken push easier. Because
Frames & Layers divide pages up it would help if browsers used sound files
to say Frames &/or Layers are on a page. Moving between HTML Headings hasn't
been too helpful as many Web pages are non-linear so Headings doesn't
resemble Pg-Down command to get to a lower sub-section, H & N will do.
Received on Friday, 3 December 1999 17:19:30 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:25 UTC