RE: Not described in words

OK

Pulling it together we have: 

2.1.1 Keyboard:   Except where the underlying task requires time-dependent,
analog input
<http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20070220/#analog-tim-dep-inputdef
> , all functionality of the content is operable through a keyboard
interface
<http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20070220/#keybrd-interfacedef>
without requiring a specific duration for any individual keystroke.

Note:  Tasks that would require an inordinate number of keystrokes instead
of one time-dependent, analog input are considered to require
time-dependent, analog input.

Note: This does not preclude and should not discourage the support of other
input methods (such as a mouse) in addition to keyboard operation.

 

Revised INTENT section 

 

The intent of this success criterion is to ensure that, wherever possible,
content can be operated through a keyboard or keyboard interface. When
content can be operated through a keyboard or alternate keyboard, it is
operable by people with no vision (who cannot use devices such as mice that
require eye-hand coordination) as well as by people who must use alternate
keyboards or input devices that act as keyboard emulators. Keyboard
emulators include speech input software, sip-and-puff software, on-screen
keyboards, scanning software and a variety of assistive technologies and
alternate keyboards. Individuals with low vision also may have trouble
tracking a pointer and find the use of software much easier (or only
possible) if they can control it from the keyboard.

The phrase "without requiring a specific duration for any individual
keystroke" is used ensure that speech recognition, Morse code, macros and
many other alternate ways of 'typing' can be used that do not allow users to
hold individual keys down for specific periods of time. [LC-1164
<http://www.w3.org/WAI/GL/WCAG20/issue-tracking/viewdata_individual.php?id=1
164> ] 

The phrase "except where the task requires analog, time-dependent input" is
included to separate those things that cannot reasonably be controlled from
a keyboard. For example, a watercolor application where the stroke is
defined by the movement and speed of movement and/or pressure is not
something that can be controlled from a keyboard except by entering an
almost infinite number of incremental move commands combined with the
duration effect (e.g. width of line at each point).  The use of MouseKeys
also would not satisfy this success criterion because it is not a keyboard
equivalent to the application; it is a mouse equivalent (i.e. it looks like
a mouse to the application).   If the application itself implemented a
MouseKeys like interface it would violate either the "key duration"
provision (if holding the key down was used) or the 'inordinate number of
commands" provision if one keystroke for each pixel" was required.   Thus
MouseKeys, although very valuable for allowing access to non-conforming
content, cannot be used to meet this provision. 

Again, it is emphasized that making things mouse operated as well as
keyboard operated is not discouraged and is in fact strongly encouraged. 

Note: The time-dependent analog input is not a time limit situation, so is
not covered by 2.2.1.

When considering whether analog, time-dependent input is required for the
underlying task (what you are trying to do) a critical question is, could
you achieve the same functionality in a different way using an input device
that was not analog, time-dependent (e.g. using a keyboard). Another quick
test is to ask whether the command or its outcome could be described in a
sentence having only one clause.  [LC-922
<http://www.w3.org/WAI/GL/WCAG20/issue-tracking/viewdata_individual.php?id=9
22> ] 

 

Examples 1:  A 'Frogger' game is designed so that the user can operate it
from the keyboard.  When the spacebar is pressed the frog jumps. The jump
command is keyboard operated and not a function of time. The game itself
involves timing (e.g. person needs to tell the frog to jump at the right
time) but that timing is covered by 2.2.1 since the timing doesn't affect
'what' the input is, just 'when'.

Example 2:  A physics lesson allows the user to learn about ballistic motion
by changing the angle and pressure of a cannon.  The user can adjust the
angle and pressure and then watch the different paths and distances the
cannonball travels.   If designed to operate with a mouse only it would fail
this SC.  It would also fail if it was designed so that holding down a key
raised the barrel until released - and another key was held down to increase
the cannon pressure until the key is released when it fires.    However it
would pass if it was designed so that the person could enter the angle and
pressure from the keyboard (or change them with a few key presses) and then
fire the cannon. 

 

 

 

 


Gregg

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

Gregg C Vanderheiden Ph.D. 
Professor - Depts of Ind. Engr. & BioMed Engr.
Director - Trace R & D Center