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

Hi Jan,

Ok, I understand the distinction and if we have to leave it in, we can do it 
see proposal below but I maintain that with direct and sequencial 
navigation, free form drawing can be done so maybe the drawing example is a 
bad one.  We argued this in sec508 discussions but they weren't buying.

<<<proposal>>>
4.1.1 Keyboard Operation: All functionality shall be *operated via the
keyboard* using *Sequential* and/or *Direct* keyboard commands except
functions that (today), depend on the path of the user's movement in real 
time and not just
 the endpoints which may rely on *Spatial
> keyboard commands*.
>>>proposal<<<

I added shall which may or not be appropriate and dropped the example while 
also adding the word (today) so that moving forward, this restriction may 
possibly be lifted.
----- 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 10:31 AM
Subject: Re: UAAG2 Guideline 4.1 Level A Only (following 3 April 2008 Call)



Hi Dave,

I think the reason for the exception is that there is an important
distinction to make between what we usually call keyboard access (direct
and sequential keyboard commands) and mouse emulation with the keyboard
(spatial commands).

Basically, the direct and sequential commands are in use by a broad
range of users (low mobility, low or no vision, "power" users) and clear
conventions and OS support exist for developers to follow. On the other
hand, mouse emulation (i.e. for drawing - I'm not including "mouse
cursor" in Jaws, etc.) is usually an assistive technology software that
generally requires sight to be used since spatial-visual feedback is
usually required.

Cheers,
Jan




David Poehlman wrote:
> 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 15:09:51 UTC