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.