Re: UAAG2 Guideline 4.1 Level A Only (following 3 April 2008 Call)

Hi Dave,

You're right in theory, but it's a question of complexity (and thus 
practicality). When a drawing pad is used to "paint" a "brush stroke" on 
an electronic "canvas" the result is "just" a static bitmap...but it is 
an extremely complex one that took as input the stylus's speed, pressure 
and movement in 2-D space over hundreds of time points as inputs. While 
these could be specified by a large number of numeric parameters, there 
is a practical limit.

Cheers,
Jan

David Poehlman wrote:
> so you are saying free hand drawing cannot be done via the keyboard?  I 
> agree flying a vehicle or even driving one might be collosally difficult if 
> possible, but Unless I'm missing something, anything that is stationary can 
> be done with a keyboard.
> 
> ----- Original Message ----- 
> From: "Gregg Vanderheiden" <gv@trace.wisc.edu>
> To: "'Sean Hayes'" <Sean.Hayes@microsoft.com>; "'Jan Richards'" 
> <jan.richards@utoronto.ca>; "'David Poehlman'" <poehlman1@comcast.net>
> Cc: "'WAI-UA list'" <w3c-wai-ua@w3.org>
> Sent: Monday, April 07, 2008 2:00 PM
> Subject: RE: UAAG2 Guideline 4.1 Level A Only (following 3 April 2008 Call)
> 
> 
> 
> The exception (which is in TEITAC and WCAG) is
> 
> [Except where]  the underlying function requires input that depends on the
> [full] path of the user's movement and not just the endpoints.
> 
> 
> So the exception isn't about drawing that can be done with rubber band lines
> or anything that can be (easily) specified without a near infinite number of
> data points  -   but rather to things like freehand drawing.
> 
> This provision interacts with the timing provision to also not require
> keyboard access to things like flying a helicopter in real-time.
> 
> We are doing some work to look at the limits of different types of input
> devices for different tasks.  It is interesting and challenging when you get
> down to the details.
> 
> 
> 
> Gregg
>  -- ------------------------------
> Gregg C Vanderheiden Ph.D.
> If Attachment is a mail.dat try http://www.kopf.com.br/winmail/
> 
> 
> 
>> -----Original Message-----
>> From: w3c-wai-ua-request@w3.org
>> [mailto:w3c-wai-ua-request@w3.org] On Behalf Of Sean Hayes
>> Sent: Monday, April 07, 2008 10:15 AM
>> To: Jan Richards; David Poehlman
>> Cc: WAI-UA list
>> Subject: RE: UAAG2 Guideline 4.1 Level A Only (following 3
>> April 2008 Call)
>>
>>
>> The TEITAC exception does not cover all drawing, only that
>> which really requires real time capture (such handwriting
>> analysis, or as exhibited by some paint type applications
>> where pressure and velocity affect the final stroke). Basic
>> line drawing, shapes and stuff like that could be done via
>> the keyboard.
>>
>> Sean Hayes
>> Media Acessibility Strategist
>> Accessibility Business Unit
>> Microsoft
>>
>> Office:  +44 118 909 5867,
>> Mobile: +44 7875 091385
>>
>> -----Original Message-----
>> From: w3c-wai-ua-request@w3.org
>> [mailto:w3c-wai-ua-request@w3.org] On Behalf Of Jan Richards
>> Sent: 04 April 2008 21:40
>> To: David Poehlman
>> Cc: WAI-UA list
>> Subject: Re: UAAG2 Guideline 4.1 Level A Only (following 3
>> April 2008 Call)
>>
>>
>> Hi Dave,
>>
>> I'm not very comfortable with exceptions either...and didn't
>> take it lightly writing it...
>>
>> How would you want to handle drawing, etc.? Driving the mouse
>> with keys or do you have something else in mind?
>>
>> Cheers,
>> Jan
>>
>>
>>
>> David Poehlman wrote:
>>> We had a big discussion about this in the ITTac.
>>> "available. The only exception is for underlying functions
>> that depend
>>> on the path of the user's movement and not just the
>> endpoints (e.g., drawing)."
>>> Suffice it to say that I take exception with the exception.
>>>
>>>
>>>
>>> ----- Original Message -----
>>> From: "Jan Richards" <jan.richards@utoronto.ca>
>>> To: "WAI-UA list" <w3c-wai-ua@w3.org>
>>> Sent: Friday, April 04, 2008 4:08 PM
>>> Subject: UAAG2 Guideline 4.1 Level A Only (following 3 April 2008
>>> Call)
>>>
>>>
>>>
>>> The other thing we were doing on the 3 April 2008 UAWG call was
>>> looking at the Level A requirements of 4.1. I made some
>> notes from the
>>> discussion and have tried to turn them into a proposal that also
>>> attempts to bring in the requirements for "visual indicators":
>>>
>>> ORIGINAL Wording:
>>> http://www.w3.org/TR/UAAG20/#principle-operable
>>>
>>> NEW Wording Ideas:
>>>
>>> Level A Success Criteria for Guideline 4.1
>>>
>>> 4.1.1 Keyboard Operation: All functionality can be
>> *operated via the
>>> keyboard*, even if pointing device-only modes of operation are also
>>> available. The only exception is for underlying functions
>> that depend
>>> on the path of the user's movement and not just the
>> endpoints (e.g., drawing).
>>> 4.1.2 Keystroke Precedence: The precedence of keystroke
>> processing is
>>> documented (e.g., user agent interface, then user agent extensions,
>>> then content features administered by the user agent such as
>>> accesskey, and then executable content).
>>>
>>> 4.1.3 No Keyboard Trap: When the content display has focus,
>> a standard
>>> keyboard command is always available that can "back out"
>> the focus by
>>> one level in the content hierarchy. From the top level of the
>>> hierarchy, this command moves focus to the user agent's
>> chrome (e.g.,
>>> the address bar).
>>>
>>> 4.1.4 Caret Text Navigation: Views that render text also
>> support the
>>> standard text area conventions for the platform (e.g., "arrow" key
>>> navigation, shift-to-select mechanism).
>>>
>>> 4.1.5 Indicating Direct Keyboard Command (Chrome): A mode
>> is provided
>>> in which any *direct keyboard commands* associated with the
>> currently
>>> displayed controls in the user agent chrome are indicated:
>>> (a) visually at the location of the control (e.g. with an accesskey
>>> underlined, with an overlay), and
>>> (b) centrally in a programmatically available fashion
>> (e.g., the menu
>>> system).
>>>
>>> 4.1.6 Indicating Direct Keyboard Command (Content Display):
>> A mode is
>>> provided in which any *direct keyboard commands* associated
>> with the
>>> currently displayed controls in the content display are indicated:
>>> (a) visually at the location of the control (e.g. with an overlay),
>>> and
>>> (b) centrally in a programmatically available fashion
>> (e.g., a list of
>>> accesskeys).
>>>
>>>
>>>
>>>
>>> NOTES:
>>>
>>> 4.1.4 Separate Activation: REMOVED -DUPLICATES 3.12.11
>>>
>>> 4.1.7 "Chrome" Navigation: REMOVED - IMPLICIT IN 4.1.1
>>>
>>>
>>>
>>>
>>> Cheers,
>>> Jan
>>>
>>>
>>>
>>>
>>>
>> --
>> Jan Richards, M.Sc.
>> User Interface Design Specialist
>> Adaptive Technology Resource Centre (ATRC) Faculty of
>> Information Studies University of Toronto
>>
>>    Email: jan.richards@utoronto.ca
>>    Web:   http://jan.atrc.utoronto.ca
>>    Phone: 416-946-7060
>>    Fax:   416-971-2896
>>
>>
>>
>>
>>
>>
> 
> 
> 
> 

-- 
Jan Richards, M.Sc.
User Interface Design Specialist
Adaptive Technology Resource Centre (ATRC)
Faculty of Information Studies
University of Toronto

   Email: jan.richards@utoronto.ca
   Web:   http://jan.atrc.utoronto.ca
   Phone: 416-946-7060
   Fax:   416-971-2896

Received on Tuesday, 8 April 2008 00:39:05 UTC