ATAG comments

Here are my personal comments on the 7 December 2006 ATAG Working Draft 
<http://www.w3.org/TR/2006/WD-ATAG20-20061207/>. Michael


General: hard to tell normative from informative sections. I've seen a 
bit of "this section is normative" and "this section is informative" but 
not on every section.

Priorities: It appears that priority is at the Guideline level, not the 
Success Criterion level. There were some success criteria that I felt 
should be at a different priority than the guideline. While I recognize 
that it would be quite a structural change to accommodate this, I will 
call out those suggestions in my review in order to explain the 
rationale on the individual cases.

1: First sentence says "Authoring Tool Accessibility Guidelines (WCAG)": 
correct acronym

1.1: Simplify definition. The main thing that gets in the way is the 
clause that begins "where a collection of software components"; suggest 
moving everything from there to end of sentence to a definition for 
"collection of software components" and link to it in the beginning part 
of the definition, as is already done for "author" and "web content". If 
this suggestion is not taken, a serious rewording needs to be done.

1.2: Third real para "consider that the authors...may be using the 
tool...in contexts that are very different from...typical". Add a 
sentence to the effect of "also consider that authors may not be 
familiar with the specific needs of people with disabilities and require 
support from the authoring tool to fill the knowledge gap.

2.1: Switch the order of the subsections "Conformance Levels and 
"Checkpoint Priorities". I found that reading the first depended on an 
understanding of the second, so it would read better to put the second 
first.

2.2 - conditions: 1) Why is it required that a conformance claim be 
published on the Web? There could be many reasons an organization would 
want to follow the mechanics of making a conformance claim, but not 
actually publish it for all the world to see. 2) Remove clause "...W3C 
does not act as an assuring party <del>but it may do so in the future, 
or it may establish recommendations for assuring parties</del>". I don't 
think we should be saying anything about this as it's too speculative.

2.2 -- Content Type-Specific WCAG Benchmark: 1) I think this should be 
prior to the "Components of an ATAG ... Claim", again because of forward 
references that would be easier to understand if we encountered this 
first. 2) "The Benchmark document is just the WCAG Techniques document 
when one exists for a content type" should not be a requirement (which 
is how I read it now), merely a recommendation. WCAG techniques are non 
normative, and other organizations are free to create better techniques, 
or to add to the WCAG techniques. Since the techniques essentially 
become normative by being absorbed into ATAG conformance requirements, 
it's especially important to preserve the integrity of the intention to 
allow other organizations to create techniques. The second bullet 
"Benchmark can be created by any person or organization" appears to 
acknowledge this, but I wasn't clear what that mean with respect to the 
statement earlier. 3) I think the WCAG 2.0 reference should be moved out 
to an external support document. The techniques are already not 
organized in the way indicated here, and their organization will 
probably change again.

A.0.1: not sure why this is a separate guideline. It seems awkward to 
have everything fit into a described numbering scheme, and then have 
this one outside. Makes it easily overlooked, yet it's one of the most 
core guidelines for Web-based authoring tools.

A.2.1: SC 6 says "the current keyboard settings..." does this mean 
"<ins>Documentation about</ins> the current keyboard settings"? If so, 
insert that; if not I didn't understand the SC.

A.2.3: This sounds very much like WCAG SC 2.2.1; note this has gone 
through some morphing and may need to be reharmonized.

A.2.7: Success Criterion 1 (undo function) should be Priority 1. Undo is 
high priority though I can agree the rest of this is P2.

A.2.9: Success Criterion 1 (get out of preview) also needs to be 
Priority 1. Tool breaks if you can't.

A.3.1: Success Criterion 1 seems like it would make more sense as a SC 
of A.2.1. SC 2 should be a SC of A.2.2. They lose context here as a 
separate guideline.

A.4.1: Success Criterion 2, bullet 2 seems elaborate, difficult, and not 
of significant value to the user. As I read it, every little control of 
the UI has to be listed in the documentation with fairly complete 
information about accessibility properties. I think if those properties 
are properly set, they won't need to be documented. If the control needs 
to be documented, there's something else wrong. Strongly recommend 
removing this. This is useful for evaluators, but I don't see that 
there's really evaluator-targeted guidelines other than this, so it 
sticks out.

B.1.4: I'm thinking of Flash when I try to understand "authored by 
hand". Flash content isn't exactly automatically generated, as you get 
pretty close control over what appears (in contrast to WYSIWYG HTML 
authoring tools, where you could get elaborate table or nested div 
structures automatically generated with just a couple authoring steps). 
However, Flash is most certainly not authorable by hand in the way HTML 
is, the author has no option to edit the code. So where does it fit with 
respect to this guideline? I can't answer that, and therefore can't 
determine applicability and conformance of this. I think it needs a 
fairly substantial rework to take into account the capabilities and 
possible authoring styles of different content types.

B.1.5: Suggest adding that content designed exclusively for the 
Authoring Tool be included in the set of content that must conform. 
E.g., templates, clip art, etc., that is not bundled with the tool, and 
is not preferentially licensed to users of the tool, but only works with 
the tool, would slip through the cracks. It may be there needs to be an 
exception that this only applies to content produced by the authoring 
tool manufacturer, but I also suggest that instead it should be a 
requirement that it not be possible to create content samples that work 
only with one authoring tool (and are probably only creatable using that 
authoring tool) and don't meet WCAG.

B.2.4: This doesn't seem to add anything that would not be required 
under B.2.1 (make sure content conforms to WCAG) and therefore I suggest 
it should be removed. SC 1 about suggesting text alternatives out of 
image databases etc. should be techniques of B.2.1. SC 2 should be made 
more generic -- authors must be able to accept, modify, or reject *any* 
tool-suggested accessibility properties.

B.3.1: I'm concerned that SC 2 is difficult to verify. There are many 
choices authors can make that lead to content not conforming to WCAG. 
Sometimes the tool can know for sure that will be the case (e.g., going 
out of the way to omit an alt attribute), other times it might suspect a 
problem (the author puts in a the image file name as alt text), and 
other times it might not really be able to tell (the author puts "Search 
Engine Optimization" spam into the alt text). I would either remove this 
SC as untestable, or add a clause that "Any choices of content types or 
authoring option presented to the author...that <ins>the authoring tool 
determines will or may</ins> lead to the creation of content that does 
not conform to WCAG...".

B.3.4: SC 1 and 3 need to be higher priority than P3, I think P1 for 
both. Without SC 3, you could break the accessible functions of the tool 
on your first day (kinda like opening a Christmas present and 
immediately snapping off that crucial piece). Without SC 1, for most 
users the tool might as well not have bothered to conform to ATAG at all 
as they'll never discover and turn on the "author accessible content" 
option.

-- 

Michael Cooper
Web Accessibility Specialist
World Wide Web Consortium, Web Accessibility Initiative
E-mail cooper@w3.org <mailto:cooper@w3.org>
Information Page <http://www.w3.org/People/cooper/>