W3C home > Mailing lists > Public > w3c-wai-au@w3.org > April to June 2006

ATAG 2.0 - reworking A.4.1

From: Jan Richards <jan.richards@utoronto.ca>
Date: Tue, 06 Jun 2006 13:14:32 -0400
Message-ID: <4485B7F8.5070202@utoronto.ca>
To: w3c-wai-au@w3.org

Here is my take on how A.4.1 and the new A.4.2 might look after today's
discussion (plus some additional rewriting of the success criteria for 
A.4.2):

Definition of PLATFORM: For functionality that is not Web-based,
"platform" this refers to the operating system(s), virtual machine, GUI 
toolkit(s), etc. used in development (and listed in the conformance 
profile). For Web-based functionality, the term applies more generically
  to user agents in general (although for purposes of evaluating 
conformance, specific user agents are listed in the conformance profile).


A.4.1 Support interoperability with assistive technologies. [Priority 1]

Rationale: Assistive technologies that are used by many authors with 
disabilities (e.g. screen readers, screen magnifiers, etc.) rely on 
software applications to provide data and control via prescribed
communication protocols.

Success Criteria:

1. The authoring tool must follow the accessibility platform 
architecture(s) relevant to the development platform (e.g. MSAA
for Windows applications, Java Access for Java applications, etc.).

2. The conformance claim must list the accessibility architecture(s) 
used as well as details any deviation from their proper use (i.e., lack 
of use, incomplete use, inappropriate use) as defined by their 
documentation.

3. If there is any authoring tool user interface functional that is not 
supported by the relevant accessibility platform architecture(s), then 
at least one of the following must be done:

a) providing an accessible equivalent for the functional that is 
supported by the relevant accessibility platform architecture(s).

b) providing an alternative interoperability mechanism with published 
documentation so that the functional would be available to an assistive 
technology implementing the mechanism.

c) describing the inaccessible functional in the compliance claim.


A.4.2 Document how the authoring interface makes use of existing
accessibility architectures. [Priority 3]

Rationale: When the use of accessibility architectures is fully 
documented, assistive technology developers are able to provide enhanced
user interface access.

Success Criteria:

1. All of the following information must be provided:
- For each GUI component that can receive focus, information related to 
the implementation of accessibility architectures (e.g. accessible name, 
accessible description, accessible role, etc. as defined by the 
accessibility architecture used).
- Whether only the support provided by the default architecture (if any) 
is used. [BAF may have thoughts on this]
- Describe the nature and use of the information provided (e.g. is the 
long description the same or different from any associated tool tip and 
should it be presented automatically or only on request).






-- 
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 Tuesday, 6 June 2006 17:15:28 GMT

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