RE: Operable with Keyboard only provision - Revised version based on comments in WCAG and in TEITAC

Hi Andi

Wouldn't that limit the guideline to pointers.  It should apply to other
input devices as well.  Gesture input for example.


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



> -----Original Message-----
> From: w3c-wai-gl-request@w3.org
> [mailto:w3c-wai-gl-request@w3.org] On Behalf Of Andi Snow-Weaver
> Sent: Monday, May 07, 2007 3:15 PM
> To: w3c-wai-gl@w3.org
> Subject: Re: Operable with Keyboard only provision - Revised
> version based on comments in WCAG and in TEITAC
>
>
>
>
> I suggest modifying "path of the user's movement" to "path of
> the pointer movement".
>
> Andi
>
>
>
>
>
>              Gregg
>
>              Vanderheiden
>
>              <gv@trace.wisc.ed
>           To
>              u>                        "w3c-wai-gl@w3.org"
>
>              Sent by:                  <w3c-wai-gl@w3.org>
>
>              w3c-wai-gl-reques
>           cc
>              t@w3.org
>
>
>      Subject
>                                        Operable with Keyboard
> only
>              05/06/2007 01:45          provision - Revised
> version based
>              PM                        on  comments in WCAG
> and in TEITAC
>
>
>
>
>              Please respond to
>
>              "gv@trace.wisc.ed
>
>                     u"
>
>              <gv@trace.wisc.ed
>
>                     u>
>
>
>
>
>
>
>
>
>
>
> New version for comment
>
>
>
>
> 2.1.1 Keyboard: All functionality of the content is operable
> through a keyboard interface without requiring specific
> timings for individual keystrokes, except where the
> underlying function requires input that depends on the path
> of the user's movement and not just the endpoints.
> (Level A)
>
>
> Note: This exception relates to the underlying function, not
> the input technique. For example, if using handwriting to
> enter text, the input technique (handwriting) requires path
> dependent input but the underlying function (text input) does not.
>
>
> Note: This does not forbid and should not discourage
> providing mouse input or other input methods in addition to
> keyboard operation.
>
>
>
>
>
>
>
>
>
>
>
> Modified Intent of UNDERSTANDING  2.1.1:
>
>
> 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
>
>
> Examples of "specific timings for individual keystrokes"
> include situations where a user would be required to repeat
> or execute multiple keystrokes within a short period of time
> or where a key must be held down for an extended period
> before the keystroke is registered. [LC-1164]
>
>
> The phrase "except where the underlying functionality
> requires path dependent input" is included to separate those
> things that cannot reasonably be controlled from a keyboard.
>
>
> 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.
>
>
> The use of MouseKeys 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).
>
>
> 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/> FAX 608/262-8848 DSS Player at
> http://tinyurl.com/dho6b If Attachement is a mail.dat try
> http://www.kopf.com.br/winmail/
>
>
>
>
>
>
>
>

Received on Monday, 7 May 2007 22:10:58 UTC