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

Hi Alex,

I tried to answer you on the call yesterday, so maybe I'll
try to take another attempt. My comments are in-line.

Li, Alex wrote:
> 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.  

I'm not quite sure what you mean. Your example (WCAG 2.0 3.1.4) is a 
Level 3 Success Criteria, so conceivably a tool could not meet it and 
still conform to ATAG 2.0 Level Double-A.

But if you meant to pick a Level 1 example, no, there would be no ATAG 
conformance level available for a tool that, for example, did not prompt 
for captions for pre-recorded audio (required by WCAG 2.0 1.2.1 L1).

> 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?

The need for judgment is one of the reasons that ATAG 2.0 does not 
require automated checking and repair. Instead, we require manual 
checking and manual repair instructions, which provides developers with 
much scope for informing the judgment of authors.

>  Is there such a tool that can fully meet 
> ATAG 2.0 priority 1 in the market today?

There are some perhaps overly simple tools that would probably meet ATAG 
  2.0 or are very close, but other more comprehensive tools are also 
getting there.

> 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.

I think it's worth talking about partial conformance (see my email at 
http://lists.w3.org/Archives/Public/w3c-wai-au/2007JanMar/0016.html).

That said, I have trouble with your example. We do want to ensure that 
all tools, authoring or QA, are accessible to people with disabilities 
who might have those job responsibilities.

> 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. 

This is a difficult issue because, while we understand the problem of 
relying on third party tools as part of a claim, if we were to drop the 
QA requirements on authoring tools completely, in hopes that users would 
use a separate QA tool, we would be awarding ATAG conformance to tools 
on faith.

Our compromise was to keep checking and repair requirements, but set the 
bar at manual (non-automated), in hopes that this would make authors 
aware of accessibility checking and those that wished could trade up to 
the more powerful third-party QA services.

> 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.

The AUWG certainly is not operating under an "auto-magic" assumption. 
While we are a "tools" guideline, we have taken a workflow approach that 
allows several tools (potentially used by different people within an 
organization) to be bundled within one claim. As you say in your last 
paragraph, it is the corporate legal departments that seem to be looking 
at tools in isolation.

Cheers,
Jan




> 
> _____________________________________________
> *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_ <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.
> 
> 

-- 
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, 15 January 2007 19:10:17 UTC