Keyboard operation

There has been a lot of discussion here and in other standards regarding the
language to use for Keyboard operation.  The goal is to have everything
accessible from they keyboard whenever possible

 

 

If all functionality
<http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20070426/Overview.html#functionde
f>  can be achieved using the keyboard, it can be accomplished by keyboard
users, by speech input (which creates keyboard input), by mouse (using
on-screen keyboards), and by a wide variety of assistive technologies that
create simulated keystrokes as their output. No other input form has this
flexibility or is universally supported and operable by people with
different disabilities.  There is a limitation however in that it is not
possible to make everything operable from the computer.  

While much can be done there are things like freehand sketching or
watercolor painting or threading a helicopter through a barrage of flack and
obstacles that cannot be done from the keyboard without an in-ordinate
number of keystrokes.  (e.g. For watercolor painting one could specify for
each pixel along the travel path the exact direction and width / depth of
color to apply but it would be hundreds or thousands of keystrokes to
represent one brush stroke.) 

To capture the dividing line between what is practical and what is not, a
number of things have been proposed. These include

1)      ....whenever the action or its outcome can be described in words

a.       This works unless you allow an inordinate number of words.  The
length and simplicity of the sentence then becomes the dividing line and the
discussion continues as to how to draw a line there.  Also there was
confusion as to whether this required things to be controlled by typing in a
sentence describing the outcome (i.e. it was confusing why this was the
'bright line').

2)      ... except when the underlying function requires time-dependent
analog input

a.       This tries to get at the cause of the restriction (i.e. why it is
and exception) but there is a lot of discussion about the fact that any
analog input can be described as an infinite number of discreet motions (see
above).  The time-dependent seems to eliminate the ability to use an
infinite number of commands but then this appears to overlap with the 'time
limit' provision which has exceptions.

3)      ...except if the underlying function requires path dependent input

a.       Free hand drawing, watercolor painting, and flying a helicopter
through an obstacle course are all examples of functions that require path
dependent input.   Drawing straight lines, regular geometric shapes, sizing
windows and dragging objects to a location (when the path to that location
is not relevant) do not require path dependent input.

The suggestion is to use #3.  Comments are sought as to problems with this
approach (#3) or whether it was the best approach or not (for drawing the
line between what should have to be controllable from a keyboard and what
should not be required at the basic level of accessibility).

NOTE: there is a higher level of accessibility that requires ALL content to
be controlled from a keyboard to be VERY accessible. 


Gregg

------------------------

Gregg C Vanderheiden Ph.D. 
Professor - Depts of Ind. Engr. & BioMed Engr.
Director - Trace R & D Center 
University of Wisconsin-Madison 
< <http://trace.wisc.edu/> http://trace.wisc.edu/> FAX 608/262-8848  

DSS Player at http://tinyurl.com/dho6b 

If Attachement is a mail.dat try  <http://www.kopf.com.br/winmail/>
http://www.kopf.com.br/winmail/

 <http://trace.wisc.edu:8080/mailman/listinfo/>