RE: Keyboard operation

To clean this up a bit it might look like 

 

 

2.1.1 Keyboard (Except): All functionality
<http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20070426/#functiondef>  of the
content is operable through a keyboard interface
<http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20070426/#keybrd-interfacedef>
without requiring specific timings for individual keystrokes, except where
the underlying functionality requires path dependent input. (Level A)
<http://www.w3.org/WAI/GL/WCAG20/WD-UNDERSTANDING-WCAG20-20070426/Overview.h
tml#keyboard-operation-keyboard-operable>  

 

2.1.2 Keyboard (No Exception): All functionality
<http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20070426/#functiondef>  of the
content is operable in a non-time-dependent manner through a keyboard
interface
<http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20070426/#keybrd-interfacedef> .
(Level AAA) 


 


path dependent input


input that depends on the path of  the users movement and not just the
endpoints. 

Note: This relates to the underlying function - not the input technique.
For example, using gestures to enter text is an input technique where the
outcome is dependent on the path of the users movements but the underlying
functionality is just text input (which does not require that one use an
interface that records or passes on the user's movement paths). 

Note: Most actions carried out by a pointing device can also be done from
the keyboard (for example, clicking, selecting, moving, sizing). However,
there is a small class of input that is done with a pointing device that
cannot be done from the keyboard in any known fashion without requiring an
inordinate number of keystrokes.   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, re-sizing windows and dragging objects to a
location (when the path to that location is not relevant) do not require
path dependent input.

 

 

 


Gregg
 -- ------------------------------ 
Gregg C Vanderheiden Ph.D. 

 

 


  _____  


From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
Of Gregg Vanderheiden
Sent: Tuesday, May 01, 2007 3:41 PM
To: w3c-wai-gl@w3.org
Subject: 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/>