W3C home > Mailing lists > Public > w3c-wai-au@w3.org > January to March 2007

Additional IBM ATAG 2.0 comments

From: Barry Feigenbaum <feigenba@us.ibm.com>
Date: Tue, 13 Feb 2007 14:02:10 -0600
To: w3c-wai-au@w3.org
Message-ID: <OFA7259E0B.DF7DA9C7-ON86257280.00714F21-86257281.006E1099@us.ibm.com>
More input from IBM accessibility folks:


>From Shannon Rapuano

Review of Part A which focuses on accessibility of the tool:
A.1.2.  Why isnt' synchronized alternative for MM considered P1 consistent 
with WCAG?

A.2.1.  Keyboard access.  I do not agree with the success criteria that 
requires single key or key + modifier access to the listed functions. This 
is not P1.  Access to the function with the keyboard is P1.  Specifying 
single key or key+ modifier is at most P2 since this is usable access and 
not accessibility.

A.2.8.  Having multiple sets of preferences and settings should be P3 and 
not P2.


Review of Part B which focuses on output of authoring tool:

B.2.4.  I am concerned about the testability of this checkpoint.  I think 
providing text equivalents for non-text content is Priority 1, but 
assisting the authors to ensure the alternative is "accurate and fits the 
content" is Priority 2 at best.  It is not a Priority 1 requirement.

B.2.6.  Is there a reason why the group made providing a summary of 
accessibility status a P3?  I would view this as P2 given the other 
requirements.

B.2.7.  There should be a definition of "tutorial" for "Provide a tutorial 
on the process of accessible authoring."  The success criteria is clear 
that the tutorial is specific to the tool, but the language of the 
checkpoint leaves it open to interpretation.  Also, how is B.2.7 different 
than B.3.5. to document accessibility features of the tool?  What 
specifically is different about a "tutorial"? 

B.3.1 and B.3.3.  I am concerned about the testability of "prominence" to 
meet these checkpoints.  I suppose it is vague enough that we could 
justify meeting the criteria in our tools.


>From Cori Ryan


So my feedback is that the Definition of Authoring Tool should extend to 
include a bullet on that describe tools like Rational manual tester that 
generate web content as an Export feature.  This is a case that can be 
easily overlooked.

I can exemplify with a basic example of images:
have the ability to provide alt text to images they paste in the script in 
the RTE and that alt text must carry though on export.  This is likely the 
same text that should be supplied for the MSAA Name value.



>From Rich Schwerdtfeger


Comments on Section 2.2 Conformance claims. I think the concept of 
Baselines should be introduced here as it is appropriate. Is WCAG 
Benchmark a new name for Baseline?

Also, the document seems to have blurred Part A and Part B here when the 
intent was to be separated. 

A.0.1 There needs to be a discussion of the Benchmark or Baseline.

A.1 Text Alternatives should include short and long desriptions(help text) 
for non-text object. ODF and HTML both provide for these. Also ARIA has an 
aaa:describedby property toreference the long description.

A.1.3  ... If the visual display (e.g., fonts, sizes, colors, spacing, 
positioning) is controlled by the authoring tool rather than by the 
platform, then the authoring tool must provide at least the same 
configurable properties with at least the same configuration ranges as the 
platform. Someone should make a request that UAAG follow a similar 
requirement. This is not specific to an authoring tool.

A.2.1 Requiring single-key modifiers should be a P2. Also, drag and drop 
and in-context menus should fall under this section.

A.2.1 Should be synched with UAAG.

      A.2.8 Should be P3

      A.4.1 Has the group thought about keyboard conflicts with assistive 
technologies? ATs can change their UI regularly so conflicts can arise and 
it would be difficult to mandate that no kbd. conflicts should occur. 
However, they are source of contention.

      B.1.1 Back to benchmarks and baselines. The baseline should be 
explicit stated.

      B.1.2 the accessibility information is available to end users in the 
result of the transformation or conversion, or   ... I would use the words 
"preserved for" vs. "available to"  and I would add that this should only 
be done if the target content-type supports the accessibility information. 
For example, ODF supports headers in rich text editor tables whereas MS 
Office does not. Also long description and short text alternatives are 
provided in ODF whereas MS Office only provides one text alternative.

      B.1 3 Will the techniques show how this is done through the 
accessibility api?

      B.2.1 I am a bit confused about relative priority. While I 
understand that this is relative to WCAG priority levels, ... Is the ATAG 
priority for a P1 to prompt for accessibility information defined in a P1 
check point in WCAG? When there is dynamic content and states and 
properties are changed in ARIA, you should define techniques that show how 
the browser will display accessibility api state or property change event 
notifications 

      B.2.2  Success Criteria 2 should not be limited to the element type. 
The author may place an ARIA role on the element which redefines what 
states and properties it should support. ATAG should allow for a 
comparison of the states/properties set with the states and properties 
allowed for that role type. For example, IBM has a tool called RAVEn which 
will compare this information against the states and properties defined 
for a role in the Role taxonomy.

      B.2.6 I agree this should be a P3. It will be difficult to do this 
for dynamic content unless it were a snapshot in time.

B.3 This section should provide information to the author in the case of a 
model-based authoring tool about whether reusable objects have previously 
been tested for accessibility with assistive technologies. This would help 
promote accessibility solution construction and perhaps reduce the load on 
the developer.



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

Accessibility ARB Representative on SWG ARB
W3C AUWG Representative
Austin IBM Club BoD
Interface Technologies IDT 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 Tuesday, 13 February 2007 20:02:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 22 September 2008 15:53:06 GMT