W3C home > Mailing lists > Public > w3c-wai-au@w3.org > October to December 2007

Re: AUWG Poll #6: 12 November 2007

From: Jan Richards <jan.richards@utoronto.ca>
Date: Wed, 21 Nov 2007 21:10:36 -0500
Message-ID: <4744E51C.1050403@utoronto.ca>
To: WAI-AUWG List <w3c-wai-au@w3.org>

Thanks Greg, Tim and Roberto. I'll put out a new Editor's Draft on Thursday.

 From there we need to update 3 documents:

1. the Techniques
2. the Checklist, and
3. the Comparison of ATAG 1.0 guidelines to ATAG 2.0


I can do biggest piece...(1)...Roberto would you like to do (2)? and 
Gregg you mentionned that you could do (3), is that still possible?

If so I can send you the most up-to-date versions.

Cheers,
Jan





Greg Pisocky wrote:
> Everything's fine with one recommended change from the proposal...
> 
> Change number [2] Rationale to read: "Some authors will benefit from
> support for understanding unusual words
> or abbreviations" 
> 
> 
> Greg Pisocky, Adobe Systems
> gpisocky@adobe.com 
> 703.883.2810p | 703.883.2850f | 703.678.3541m
> 
> -----Original Message-----
> From: w3c-wai-au-request@w3.org [mailto:w3c-wai-au-request@w3.org] On
> Behalf Of Jan Richards
> Sent: Monday, November 12, 2007 10:46 AM
> To: WAI-AUWG List
> Subject: AUWG Poll #6: 12 November 2007
> 
> 
> Hi All,
> 
> I though that was a very productive F2F...resulting in this Editor's
> Draft:
> 
> http://www.w3.org/WAI/AU/2007/WD-ATAG20-20071112/WD-ATAG20-20071112.html
> 
> There are just a few minor things (marked with "@@") to clear up before
> I start the publication process (I would really appreciate responses by
> Friday, Nov. 16th.):
> 
> 
> [1]  A.1.2.2: I propose we reword this (my rationale is that it is
> unrealistic to expect AT's to chase after custom API extensions for each
> authoring tool as the current wording does) - NEW WORDING:
> 
> A.1.2.2 Accessible Alternative (user interface "chrome", content
> display): If any non-Web-based authoring user interface functionality is
> not supported by the implemented accessibility platform architecture(s),
> then a separate accessible alternative for that functionality that is
> supported by the implemented accessibility platform architecture(s) is
> provided and a description of the inaccessible functionality appears in
> the conformance claim.
> 
> 
> [2] A.4.1: Rationale: Some authors will benefit from support with
> unusual words or abbreviations.
> 
> 
> [3] In "What does a Web Content Accessibility Benchmark document 
> include?", bullet 4, I propose the parenthetical statement in "Any 
> assumptions about user agents available to authors or end users (related
> 
> to the "user agent supported" concept in WCAG 2.0)".
> 
> My Rationale: Was to explain why we were asking for this info.
> 
> 
> [4] Definition of "user interface component" - I propose adding the 
> second sentence in the following:
> 
> @@A part of the user interface "chrome" or content display (including 
> renderings) that is perceived by authors as a single control for a 
> distinct function. In ATAG 2.0, the term is used to denote any part of 
> the user interface of the authoring tool involved with display or
> control.@@
> 
> My Rationale: To be more clear since we use this term a lot.
> 
> 
> Cheers,
> Jan
> 
> 
> 
> 
Received on Thursday, 22 November 2007 02:10:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 22 September 2008 15:53:07 GMT