- From: Jan Richards <jan.richards@utoronto.ca>
- Date: Tue, 29 Apr 2008 15:04:48 -0400
- To: w3c-wai-au@w3.org
Hi Michael, At the meeting on Monday, Ann, Andrew and myself agreed with your wording. How do others feel? If we get enough ok's on the list, I can drop it into a new Editor's draft. Cheers, Jan Michael A Squillace wrote: > 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 > > -- 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, 29 April 2008 19:03:54 UTC