W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > April to June 2008

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

From: David Poehlman <poehlman1@comcast.net>
Date: Mon, 7 Apr 2008 11:26:17 -0400
Message-ID: <014101c898c3$ba0e4080$0901a8c0@HANDS>
To: "WAI-UA list" <w3c-wai-ua@w3.org>

Thanks Sean,

Perhaps the example could be re added and clarified then?  I think also that 
realtime may also be something worth noting here.

----- Original Message ----- 
From: "Sean Hayes" <Sean.Hayes@microsoft.com>
To: "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 11:15 AM
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
Received on Monday, 7 April 2008 15:28:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:51:56 GMT