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

Jan,

This is fine, but if it can be done through the keyboard, why would it not 
be required?

Thanks!

----- Original Message ----- 
From: "Jan Richards" <jan.richards@utoronto.ca>
To: "David Poehlman" <poehlman1@comcast.net>
Cc: "WAI-UA list" <w3c-wai-ua@w3.org>
Sent: Monday, April 07, 2008 9:50 AM
Subject: Re: UAAG2 Guideline 4.1 Level A Only (following 3 April 2008 Call)



Hi Dave,

The wording was designed to only exclude drawing paths. Choosing tools
from pallets and drawing vector-based shapes was intended to be
included. But all the same, maybe we can soften the exception by using
the *Direct*, *Sequential* and *Spatial* keyboard command concepts to be
more clear....

How about:

4.1.1 Keyboard Operation: All functionality can be *operated via the
keyboard* using *Sequential* and/or *Direct* keyboard commands except
functions that depend on the path of the user's movement and not just
the endpoints (e.g., freeform drawing), which may rely on *Spatial
keyboard commands*.


Cheers,
Jan





David Poehlman wrote:
> There are two ways that were propposed and they were both rejected as far 
> as
> I know lausing the keyboard to controll the drawing tool and:
> 2> using characters as paints.  you type a character and then you move it
> around or you use the keyboard to pick from a pallet.  In any case, there
> are lots of way to do it.  The problem we run into is realtime.  if 
> realtime
> motion is required, we cannot trap that with the keyboard but drawing we 
> can
> do.
> st I heard.
>
> 1>
> ----- Original Message ----- 
> From: "Jan Richards" <jan.richards@utoronto.ca>
> To: "David Poehlman" <poehlman1@comcast.net>
> Cc: "WAI-UA list" <w3c-wai-ua@w3.org>
> Sent: Friday, April 04, 2008 4:39 PM
> 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

Received on Monday, 7 April 2008 14:10:33 UTC