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

Re: Call for Review: Authoring Tool Accessibility Guidelines 2.0 Working Draft

From: Jan Richards <jan.richards@utoronto.ca>
Date: Thu, 11 Jan 2007 12:13:50 -0500
Message-ID: <45A6704E.3060401@utoronto.ca>
To: "Li, Alex" <alex.li@sap.com>
CC: w3c-wai-au@w3.org, Michael Cooper <cooper@w3.org>

Hi Alex,

Thank you very much for your comments. The working group will let you 
know our responses as soon as possible.


Li, Alex wrote:
> A.1.3 SC1--"...authoring tool/ must/ provide at least the same 
> configurable properties with at least the same configuration ranges as 
> the platform."  I don't think that can be confirmed one way or the other 
> unless the method of configuration between the authoring tool and the 
> platform are exactly the same.  They are usually not the same.  Thatís 
> goes the same with audio for part 2. You should also consider that 
> authoring tools can provide additional configuration option "on-top-of" 
> the platform.  Thus, the authoring tools may extend the configuation 
> options, even though its range may appear lesser than that of the platform.
> A.2.1 Should add an exception for analog, time-dependent input as in 
> WCAG 2.0 2.1.1
> A.2.1 Success Criteria 5 is a convenient feature, but should not be 
> priority 1.  As long as user/author can use keyboard to activate the 
> settings, it is accessible.
> A.2.3 Success Criteria 1.  The SC statement draw out a condition of what 
> is needed when time limit is not controlled by time-sensitive external 
> constraints.  But it says nothing about conditions where the time limit 
> is controlled by external constraints.  How are the authoring tools, or 
> more appropriately the authoring environments, where time contraints are 
> controlled by external contraints to fulfill this priority 1 
> requirement?  You need to make an explicit exception statement here or 
> have instruction of what needs to be done.  As you should know, almost 
> all commercial products are made in collaborative environments where 
> such external time contraints are essential.
> A.2.5 That is a usability feature.  It impacts people without 
> disabilities just as much.  It should be removed.
> A.2.6 search funtionality is too specific.  There may be other mode to 
> locate things.
> A.2.7 Not all functions can be "undoed", especially operations such as 
> file save, delete, and most collaborative funcationalities.  Explicit 
> exception is needed.
> A.3.1 where the term "observe" is not specific enough.
> A.3.2 does not appear testable.
> A.4.1 There are more way to make applications accessible to AT than the 
> like of MSAA.  MSAA and UIA are not capable of meeting all needs from 
> author tool makers.  Implementing only MSAA almost gurantee some 
> functionalities will fail in some cases.  If the rest of the 
> requirements are met and it works with AT, why do you care how we do it 
> from an architecture standpoint?  This is far too prescriptive to be 
> priority 1.  Also, this requirement manipulates market dynamics between 
> platform providers, ISPs, AT vendors.   That is a bad idea.
> Part B in general--Due to potential legal risk associated with WCAG 
> comformance, I don't think you will find too many commercial authoring 
> tool makers who would that say within the tool itself that doing XYZ 
> with a particular authoring tool would qurantee WCAG compliance 
> content.  This may be the case, even if the tool technically meets part 
> B requirements.  There is too much legal risk to make claims of 
> fulfillment for part B.
> B.2.2 So, everytime we have non-text-content, the author tool as to 
> explain to the user/author how to meet 1.1.1 in WCAG 2.0?  That seems 
> like a lot to ask for an authoring tool to handle something objective 
> like this.
> B.2.4 Why do we need this if we already have B.2.2 (both seem overly 
> demanding)?
> *Alex Li*
> Manager, Accessibility Standards and Policies
> *SAP Labs, Inc.*
> 3410 Hillview Ave
> Palo Alto, CA 94304
> T (650) 687-4770
> F (610) 492-2961
> M (202) 492-4592
> mailto: _____alex.li@sap.com_ <mailto:alex.li@sap.com>
> _http://www.sap.com_ <http://www.sap.com/>
> This e-mail is confidential and may contain privileged information. If 
> you are not the addressee it may be unlawful for you to read, copy, 
> distribute, disclose or otherwise use the information in this e-mail. If 
> you are not the intended recipient please notify us immediately.

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 Thursday, 11 January 2007 17:14:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:39:54 UTC