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

I want to add one more comment, which I brought up at the WCAG call.
But I did not feel like it was fully answered.  The question is--what
happen to the QA tool assist the author in some of the WCAG fulfillment
but not 100% of it?  For example, what type of claim can the tool claim
if the only shortcoming is not being able to meet B.2.1 for WCAG 2.0
3.1.4.  Do you think it is feasible for a QA tool to fully meet all
requirements in part B fully consider the judgement required for meeting
some of the WCAG requirements?  Is there such a tool that can fully meet
ATAG 2.0 priority 1 in the market today?

You need to allow conformance claim for part A and part B separately
because many products are pure author tools and some are pure QA tools.
It would be impossible for the tool makers to make any claim unless the
claim is bundled with another tool, likely from a different company.
This would be inappropriate because it would require one vendor to make
claim on product(s) belonging to other tool maker(s).  It would likely
not get out the door of most legal departments.  The market confusion
would multiply if different authoring tool makers make different
evaluation on the same QA tool or vise versa.  The situation may get
even worse if multiple authoring tools and QA tools are needed.
Separation is essential.  

Moreover, it is important to appreciate that good web accessibility
requires tight development and QA "PROCESSES".  I think it is misguided
for anybody to think that a TOOL can handle QA auto-magically all by
itself.  It appears to be an assumption that the working group is
focusing on a lone developer+QA scenario.  That is not a good assumption
at all, because almost all development environment for almost all
commercial products/web services involves a dynamic combination of
process control, management, skill/knowledge, and, to a relatively small
degree, a set of tools.  Without the other factors, no tool can produce
accessible product in any degree of reliability.

> _____________________________________________ 
> From: 	Li, Alex  
> Sent:	Wednesday, Jan 10, 2007 14:51 PM
> To:	w3c-wai-au@w3.org
> Cc:	'Michael Cooper'
> Subject:	Re: Call for Review: Authoring Tool Accessibility
> Guidelines 2.0   Working Draft
> 
> 
> 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
> http://www.sap.com <http://www.sap.com/> 
> THE BEST-RUN BUSINESSES RUN SAP 
> 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.
> 
>