Re: AUWG group activities leading towards next F2F (from BAF)

Thanks for the input Barry. More comments are marked with [JR].



> Suggested changes:
> 
> GUIDELINE A.4: Authoring interface must work with current assistive 
> technology or provide an alternative 
> A.4.1 Support interoperability with assistive technologies. [Priority 1] 
> Rationale: Assistive technologies (e.g. screen readers, screen magnifiers, 
> etc.) used by many authors with disabilities rely on software applications 
> to provide data and control via prescribed communication protocols.
> 
> Techniques: Implementation Techniques for Checkpoint A.4.1 
> Success Criteria:
> 1.      The authoring tool should follow the relevant accessibility 
> platform architectures (e.g. MSAA, Java Access, etc.) wherever possible. 
> The accessibility architecture(s) used must be listed in the conformance 
> criteria. Any deviation from proper use (i.e., lack of use, incomplete 
> use, inappropriate use) of the accessibility architecture must be detailed 
> in the conformance criteria.

[JR] Can we eliminate the "should" somehow? All of these statements need to be 
normative so perhaps we can reword this as: "Wherever possible, tools must..."?


> 2.      If there is any authoring tool functionality or information that 
> is not addressed by available relevant accessibility platform 
> architectures, either: 
> a) the authoring interface must provide an accessible equivalent or 
> b) a published interoperability mechanism must be provided (or referenced) 
> so that all authoring tasks can be accomplished in at least one way by an 
> assistive technology implementing the mechanism. 
> c) document the inaccessible function or information in the compliance 
> criteria.
> 
> A.4.2 Document how the authoring interface makes use of existing 
> accessibility architectures. [Priority 3] 
> Rationale: Allows assistive technology developers to provide enhanced 
> alternative user interfaces for the authoring interface.
> Techniques: Implementation Techniques for Checkpoint A.4.1 
> Success Criteria:
> 1.      The authoring tool should describe how it provides accessibility 
> related information (such as accessible name, accessible description, 
> accessible role, etc. as defined by the accessibility architecture used) 
> for each GUI component that can receive focus. If only the default 
> architecture provided support (if any) is used, that should be indicated 
> as well. 
> 2.      It should describe the nature and use of the information provided 
> (for example, is the long description the same or different from any 
> associated tool tip and should it be presented automatically or only on 
> request).

[JR] Two more "shoulds". This is a P3, so its already optional to do this. 
Couldn't we just replace the "should"s with "must"s? Other than like, I like 
your suggestions.


Cheers,
Jan





> 
> 
> Need to add section to the compliance criteria for the above. 
> 
> Barry A. Feigenbaum, Ph. D.
> Tool Architect
> Human Ability and Accessibility Center - IBM Research
> www.ibm.com/able, 
> w3.ibm.com/able 
> voice 512-838-4763/tl678-4763
> fax 512-838-9367/0330
> cell 512-799-9182
> feigenba@us.ibm.com
> Mailstop 904/5F-021
> 11400 Burnet Rd., Austin TX 78758
> 
> AARB representative
> W3C AUWG Representative
> IBM Club Representative
> IEB Member
> QSE Development TopGun
> 
> Sun Certified Java Programmer, Developer & Architect 
> IBM Certified XML Developer; OOAD w/UML
> 
> This message sent with 100% recycled electrons
>

Received on Monday, 17 April 2006 19:50:38 UTC