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

This is from Barry, who is unable to send to the list (I have contacted WAI 
about this):


----- Forwarded message from Barry Feigenbaum <feigenba@us.ibm.com> -----
    Date: Mon, 17 Apr 2006 12:16:17 -0500
    From: Barry Feigenbaum <feigenba@us.ibm.com>
Reply-To: Barry Feigenbaum <feigenba@us.ibm.com>
 Subject: Re: AUWG group activities leading towards next F2F
      To: Jan Richards <jan.richards@utoronto.ca>

For:
GUIDELINE A.4: Authoring Interface must be Access System Friendly 
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 must follow accessibility platform 
architectures (e.g. MSAA, Java Access, etc.). 
2.      If there is any authoring tool functionality or information that 
is not addressed by available accessibility platform architectures, 
another published interoperability mechanism must be provided so that all 
authoring tasks can be accomplished in at least one way by an assistive 
technology implementing the mechanism. 
For Web-Based Interface Components: Meeting Checkpoint A.0.1 will serve to 
meet this checkpoint. 

Comments:


A.4.1 Support interoperability with assistive technologies. [Priority 1]
1.      [6] "Authoring system must be access system friendly" is not 
strong enough.  Being "friendly" doesn't mean that it works with AT.  I 
recommend something more like  "Authoring system must work with current 
assistive technology" which is more consistent with the WCAG principle 
that "...content must be robust enough to work with current and future 
technology".  Working and being "friendly" are two different things. 
2.      [10] Suggest documenting accessibility implementation for AT 
vendors be a P3? For example, this would encompass what MSAA APIs were 
supported per widget. 
3.      [12] Concern over how tough this is to enforce (i.e., what version 
number of JAWS, which AT products?) 
1.      
http://lists.w3.org/Archives/Public/w3c-wai-au/2006JanMar/0023.html
"Authoring system must work with current assistive technology" works for 
me. 
2.      [NEW]
This sounds like it makes sense as a new checkpoint (i.e. A.4.2). What do 
people think? 
3.      [NEW]
The success criteria don't actually point at AT's. They are more focussed 
on API support, so this probably isn't a problem, though we might want to 
restate the checkpoint. Perhaps something like as: "Provide 
interoperability mechanisms for compatibility with assistive 
technologies." 



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.
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).


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



Jan Richards <jan.richards@utoronto.ca> 
Sent by: w3c-wai-au-request@w3.org
03/31/2006 08:45 AM

To
w3c-wai-au@w3.org
cc

Subject
Re: AUWG group activities leading towards next F2F







Hi,

On Mar 6 the group decided to do a thorough review of ATAG 2.0's 
checkpoints - in random order to correct for attentional bias to earlier 
  checkpoints. This is the random order I have been working from as well 
as the group's progress.

If you would like to do a review just pick the next checkpoint off the 
list. And remember to check the list archives for existing proposals 
(this should help:
http://lists.w3.org/Archives/Public/w3c-wai-au/2006JanMar/att-
0027/12_2005_comment_responses.html
)

B.2.4 - GP - done
http://lists.w3.org/Archives/Public/w3c-wai-au/2006JanMar/0042.html
updated: 
http://lists.w3.org/Archives/Public/w3c-wai-au/2006JanMar/0040.html

B.1.1 - JR - done
http://lists.w3.org/Archives/Public/w3c-wai-au/2006JanMar/0036.html
updated:
http://lists.w3.org/Archives/Public/w3c-wai-au/2006JanMar/0040.html

A.1.4 - RS - done
http://lists.w3.org/Archives/Public/w3c-wai-au/2006JanMar/0043.html

B.2.6 - GP

A.4.1 - BAF, could you take a look at this one?

B.2.7 - JR
B.1.3
A.2.2
B.2.8
B.1.4
A.1.1
A.3.1
B.1.2
A.0.1
A.1.5
A.2.8
B.2.2
A.1.2
B.2.1
A.3.3
A.2.9
B.3.1
A.2.3
B.2.3
B.3.2
B.3.3
B.2.5
A.2.4
A.2.7
B.3.4
A.1.3
A.2.6
A.2.1
B.2.9
A.3.2
A.2.5

Cheers,
Jan



----- End forwarded message -----