W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 2007

RE: Not described in words

From: Sean Hayes <Sean.Hayes@microsoft.com>
Date: Wed, 21 Mar 2007 21:43:24 +0000
To: Gregg Vanderheiden <gv@trace.wisc.edu>, "'Slatin, John M'" <john_slatin@austin.utexas.edu>, "'Bailey, Bruce'" <Bruce.Bailey@ed.gov>
CC: "w3c-wai-gl@w3.org" <w3c-wai-gl@w3.org>
Message-ID: <7261AC2A5F73904CA41773C8F00813FF1C73E79D@EA-EXMSG-C309.europe.corp.microsoft.com>
Except for preferring replacing the comma with 'or' I like this wording.

From: Gregg Vanderheiden [mailto:gv@trace.wisc.edu]
Sent: 21 March 2007 01:05
To: 'Slatin, John M'; 'Bailey, Bruce'; Sean Hayes
Cc: w3c-wai-gl@w3.org
Subject: RE: Not described in words


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=1164>]

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=922>]

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 C Vanderheiden Ph.D.
Professor - Depts of Ind. Engr. & BioMed Engr.
Director - Trace R & D Center
Received on Wednesday, 21 March 2007 21:44:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:34:02 UTC