- From: Jan Richards <jan.richards@utoronto.ca>
- Date: Tue, 06 Jun 2006 13:14:32 -0400
- 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 UTC