- From: Michael A Squillace <masquill@us.ibm.com>
- Date: Fri, 25 Apr 2008 13:17:58 -0500
- To: w3c-wai-au@w3.org
All: Here is my proposed rewording: Guideline A.1.2 [For the authoring tool user interface] Support interoperability with assistive technologies. Rationale: Assistive technologies that are used by many people with disabilities (e.g., screen readers, screen magnifiers, on-screen keyboards, voice recognition systems) rely on the authoring tool to provide data and control via prescribed communication protocols. These protocols are typically implemented via an accessibility architecture, which provides a means by which content authors and aplication developers can export additional semantic information to assistive technologies in order to effect alternative presentations. Level A Success Criteria for Guideline A.1.2 A.1.2.1 Accessibility Platform Architecture (user interface "chrome", content display): Non-Web-based authoring user interfaces (and their components) implement an accessibility platform architecture relevant to the platform or leverage existing implementations of the architecture. [Developers of authoring tools are encouraged to choose platforms that offer a robust and proven accessibility architecture.] A.1.2.2 Accessible Alternative (user interface "chrome", content display): If any non-Web-based authoring user interface functionality is not supported by the implemented accessibility platform architecture(s), then a separate accessible alternative for that functionality that is supported by the implemented accessibility platform architecture(s) is provided and a description of the inaccessible functionality appears in the conformance claim. AA and AAA success criteria remain unchanged, with the possible exception of adding the bracketed text above in A1.2.1 as an additional AAA criterion, A1.2.5. I would prefer to leave it in A1.2.1 as is. Guideline A.2.3 [For the authoring tool user interface] Ensure that the interface is enabled for alternative presentations. Rationale: Authors need to have access to and control over both the functional significance of presentation and also, in the context of authoring, the presentation that will be experienced by the end user. This is especially important for user interface components that do not implement an accessibility platform architecture or leverage existing implementations (e.g. custom user interface components built via JavaScript and CSS). Success criteria remain unchanged. --> Mike Squillace IBM Human Ability and Accessibility Center Austin, TX W:512.823.7423 M:512.970.0066 masquill@us.ibm.com www.ibm.com/able
Received on Friday, 25 April 2008 18:19:07 UTC