FW: ATAG review

Here is my review of the ATAG 2.0 document.  I read the ATAG document itself thoroughly, and the parts of the glossary I needed to read to understand the document.  I skimmed the rest of the glossary and the implementation guide.

In general, I think it's quite good, and a significant improvement over ATAG 1.0.

Part A
Applicability Notes

*         Mentions of " image label."  Shouldn't that be "text alternative" instead?

A.1.2
I'm glad to see that there is now a single success criterion for non-web, instead of trying to map non-w3c specs to WCAG levels.

A.3.1.2 Drawing Keyboard Access
Note 2: This success criterion should not be interpreted as discouraging mouse input or other input methods in addition to keyboard operation.
It seems like this note applies to all of A.3.1 Keyboard, not just drawing.

A.3.1.3 Avoiding Content Keyboard Traps
The word "Avoiding" is problematic.  Some people think it means "don't do," and others think it means "try not to do."  This was a frequent source of confusion in WCAG 1.0, and WCAG 2.0 avoids (sorry, couldn't resist) the word.  Instead use "No Content Keyboard Traps" or "Prevent Content Keyboard Traps".

A.3.1.5 Keyboard Shortcuts
To what?  Key functionality?  Every possible function? How many are enough?  This needs more detail to be testable.

A.3.1.6 Drawing Keyboard Access (Enhanced)
Should the AAA one require direct access, rather than also allowing indirect access by editing properties?  I agree this makes sense for A and AA, but should it go all the way for AAA?

A.3.2.1 Data Saved
Note: For web-based authoring tools, this applies to any web content that has already been submitted to the server by the user agent.
I wonder if it would make sense to have a AAA SC that provides for automatically submitting content in such a system?

A.3.5.1 Text Search: The author(s) can perform text searches of web content in which all of the following are true: (Level AA)
(a) Search All Editable: The search can be within any information that is text and that the authoring tool can modify (e.g., text content, text alternatives for non-text content, metadata, markup elements and attributes, etc.); and

Does "The search can be" mean "The search MUST be" or "The search MAY be"?

Note: If the current editing view is not able to display the results of a search then the authoring tool may switch to a different editing view to display the results (e.g., to a source content editing view to display search results within markup tags).
I would hope that the authoring tool won't do this automatically, as that could be quite unexpected and jarring.  Perhaps this should say that the authoring tool could provide a mechanism for the author to switch?

Guideline A.3.6 [For the authoring tool user interface] Manage preference settings
Should there be an SC for honoring operating system settings for keyboard and display?
Alternatively, perhaps both honoring OS settings, and saving keyboard and display settings, are general software issues, and not specific to authoring tools?

A.3.7.2 Preview: If a preview is provided, then at least one of the following is true: (Level A)
*(a) Existing User Agent: the preview makes use of an existing user agent that is specified in the conformance claim (e.g., opening the content in a third-party browser, browser component, video player, etc.); or
I think that sometimes previews are done with the default browser on the system.  How would that be handled in the conformance claim?

A.4.1.3 Undo is Reversible: Authors can immediately reverse the most recent "undo" action(s). (Level AA)
Add "This is sometimes called 're-do' ".

Part B
Responsibility After Authoring Sessions: Authoring tools are not responsible for web content accessibility problems that result from carrying out instructions made by authors during authoring sessions (e.g., the content of a third-party feed specified by the author). Authoring tools are responsible if the web content accessibility problems are automatically generated (e.g., when the developer of a content management system updates its site-wide templates).
This paragraph is a little hard to parse.  I don't have immediate editorial suggestions, but I had to read this 3 times before I got it.

Guideline B.1.1 Support web content technologies that enable the creation of content that is accessible
The SC here are about being able to produce WCAG compliant content.  It doesn't talk about supporting Web technologies with Accessibility Supported Uses.  If the guideline is about WCAG, it should say that.  If it's about support of accessibility-enabling technologies, it should have SC about that.  Perhaps both are needed?

B.1.2.2 End Product Cannot Preserve Accessibility Information
An example would be nice here.  (e.g. saving a structured graphic to a raster image format)

B.2.1
Why is there a line between B.2.1.1 and B.2.1.2 when both are A?

B.2.2.1 Check Accessibility (WCAG Level A): At least one individual check is associated with each WCAG 2.0 Level A Success Criterion that the authoring tool has the functionality to modify web content to meet (e.g., an HTML authoring tool that inserts images should check for alt text; a video authoring tool with the ability to edit text tracks should check for captions). (Level A)
Note: While automated checking or more advanced implementations of semi-automated checking may improve the authoring experience, manual checking is the minimum requirement to meet this success criterion (as well as B.2.2.4 and B.2.2.10).

How does a tool create a manual check?  I know what it means for an author to do this, but I can't figure out what it would mean for a tool to do it.

B.2.2.4 Help Authors Locate: For any checks that require author judgment to determine whether a potential web content accessibility problem is correctly identified (i.e., manual checking and semi-automated checking), the relevant web content is identified (e.g., displaying the web content, displaying line numbers, etc.) (Level AA)

Maybe this should be A?  It's not very useful to know that there's an error somewhere, if you don't know where.  I'd make automatically taking the author to the line in question AA.

B.2.2.8 Metadata for Discovery: If the authoring tool records the accessibility status of web content, then authors have the option to associate this status with the web content as metadata to facilitate resource discovery by end users. (Level AA)
Do any authoring tools do this now?  This seems far less important, and far less proven, than B.2.2.4, yet they're the same level.  I'd make this AAA.

B.2.3.1 Repair Accessibility (WCAG Level A): For each WCAG 2.0 Level A web content accessibility problem that is identifiable during checking (required in Guideline B.2.2), repair assistance is provided. (Level A)
Note: While automated repair assistance or more advanced implementations of semi-automated repair assistance may improve the authoring experience, manual repair assistance is the minimum requirement to meet this success criterion (as well as success criteria B.2.3.2 and B.2.3.3).
I'm not sure I agree that automated repair improves the user experience.  Authors generally HATE it when tools change their content automatically.

See also: This guideline applies when non-text content is specified by the author(s) (e.g., an author inserts an image). When non-text content is automatically added by the authoring tool, see Guideline B.1.3.

B.2.4.1 Editable: Authors are able to modify alternative content for non-text content. This includes types of alternative content that may not typically be displayed on screen by user agents. (Level A)
I think this applies when text alternatives are automatically generated too.  One good approach to text alternatives is to generate them, and then expose them to author to edit or tweak.

B.2.4.2 Automated suggestions: During the authoring session, the authoring tool can automatically suggest alternative content for non-text content only under the following conditions: (Level A)

*(a) Author control: authors have the opportunity to accept, modify, or reject the suggested alternative content prior to insertion; and
*(b) Relevant sources: the suggested alternative content is only derived from sources designed to fulfill the same purpose (e.g., suggesting the value of an image's "description" metadata field as a long description).

These should be OR, not AND.  Providing a suggestion based on something like the file name is often a good starting point to get authors to put in something better.  If the author has the opportunity to change it, then the tool developer should be able to decide as part of his design work what sources are appropriate in a particular authoring scenario.

Guideline B.2.5 Assist authors with accessible templates and other pre-authored content
This needs SC about other pre-authored content, particularly controls.
Add a AAA about making the default template accessible?

Guideline B.3.1 Ensure that accessible authoring actions are given prominence
Add a AA or AAA about accessible options being MORE prominent than inaccessible ones?

Why does B.3.1 emphasize prominence, while B.3.2 emphasizes availability?  B.3.2's rationale talks about prominence in addition to availability.

Guideline B.3.4 Ensure that any authoring practices demonstrated in documentation are accessible
Should specifically mention sample code and sample apps, as these are frequently not accessible, and authors cut and paste from them.

Conformance
What about mixed level conformance?  For example, if a tool is AA on part B, but only A on part A?

Implementation Guide
General:  more whitespace around the boxes for the intent and examples would make it easier to read.  Maybe shade these sections too?  It was a little hard to figure out what parts were different than the main ATAG document.

Similarly, it would be nice if it was easier to find the beginning of each SC.  Perhaps making the Implementing Success Criterion x.x.x heading larger, and putting more vertical whitespace before it?  I also noticed that these aren't real headings (<h1>-<h6>).  They should be.

A.1.2
A link to the ISO software standards for accessibility would be good, or at least to a non-fee summary of it if there is one.

Implementing Guideline A.3.4 [For the authoring tool user interface] Enhance navigation and editing via content structure
It might be good to add a note that these sorts of keyboard optimizations are often very much appreciated by power users, whom one would expect in large numbers among certain types of web authors.

B.1.1 doesn't answer my question about what meeting WCAG has to do with Support web content technologies.   It certainly does have to do with the creation of accessible content.

B.1.2.2 need an example of when accessibility info can't be preserved.  Maybe saving to .jpg?

Appendix A
(15) onclick IS device independent in all implementations I'm aware of.  The word doesn't sound like it, but it does work.