DRAFT Responses to Comments on
ATAG 2.0 (21 May 2009) Public Drafts:

1. (MG1): I'm finding it difficult with both WCAG 2.0 & ATAG 2.0 to have web accessibility & desktop accessibility merged together like this. Perhaps it is useful for the sake of the overlap in standardized approaches. However, for a web developer working with a popular open source content management system (Drupal), I find that most folks get lost in the documentation. Stripping it down to what is relevant for particular audiences is key. It's disappointing that W3C isn't taking the initiative to provide concise guides for different developer communities. Would really aid adoption I am sure. Web based interfaces are a big enough challenge for accessibility that they could use having a shorter checklist, tailored using more standardized web specific language, and with links to best practices which are available in existing open source packages if possible. The desktop software people speak a different language I assume.
2. (MT2): I think it's worth considering to merge success criterias which differ in wcag level only, e.g: B.3.1.1 Accessible Options Prominent (Level A) B.3.1.2 Accessible Options Prominent (Level AA) B.3.1.3 Accessible Options Prominent (Level AAA) Some of these success criterias are listed one after the other, in other cases different success criterias are in between the "similar-except-for-wcag-level" criterias.
3. (WCAGWG): Several Success Criteria have clarifying examples “(e.g., …)” in their body. These should be avoided. They can be converted to notes or moved to the understanding document. (FWIW, WCAG does have some normative use of “e.g.”, mostly in definitions, but never in SC.)
4. (WCAGWG): Some guidelines end with “Applicability Notes”. The formating and location makes it less than obvious that these apply to all Success Criteria within a Guideline. Suggest moving these before Success Criteria (within a Guideline grouping), or repeating for each Success Criteria. The Success Criteria should stand on their own, and Success Criteria can be anticipated to be extracted from Guideline context, so this these Applicability Notes are problematic as used.

1. ?
2. ?

1. (MT3): All the links in documents like this makes the content more difficult to read especially when using synthetic speach....It would have been nice if these links could have been "switched off", and if you wanted to read definitions you could have opened a separate pane (or window) with the definition list.
2. (LGR): Examples in the success criteria statements (e.g. parentheticals in the success criteria) nearly always refer to text alternatives for images. Are there any other examples that could be used? One comes away with the impression that authoring for accessibility is all about alt text....

1. ?
2. ?

1. (WCAGWG): The introduction says "This section is informative, except where noted." This seems confusing. It might be better to label the information and normative subsections as such.

1. ?

1. (LGR): Do the new examples of authoring tools in the Introduction sufficiently illustrate and differentiate between web and non-web functionality? The examples are helpful for understanding the wide range of authoring tools, and where authoring is a small piece of a larger application. However, as commented below, I think the introduction doesn't clarify web and non-web functionality, and that an authoring tool may be one or the other or a mixture.

1. ?

1. (LGR): In the "Understanding Levels of Conformance" section, "essential" is described as "even the authoring tool user interface cannot make content accessible" I don't understand what this means, since the UI is not making the content accessible. Perhaps this should be "the author cannot use the authoring tool user interface to make content accessible"?

1. EDITORIAL - done.

1. (LGR): I found this paragraph difficult to understand from the wording. I did finally understand the point, but it took work. Suggest: "The authoring tool is responsible for ensuring that the content being edited is accessible to people with disabilities (e.g., ensuring that an image label in the content is available via the platform). However, where an authoring tool user interface accessibility problem is caused directly by a Web content accessibility problem in the content being edited (e.g., if an image in the content lacks a label), then this would not be considered a deficiency in the accessibility of the authoring tool user interface."

1. EDITORIAL - done.

1. (LGR): I can't understand the rationale; there is something odd about the way the different ideas in the sentence are being related to one another. Is this trying to point out that Web applications can be authoring tools, and that they need to conform themselves? Does it only cover web applications because this is a W3C web accessibility spec?
2. (LGR): In the applicability notes [for A.1.1, A.1.2] , perhaps you want to start with something like "An authoring tool may combine web-based functionality with non-web-based functionality." Or perhaps this distinction needs to be introduced earlier. The use of "also" in the applicability note is confusing, particularly without introducing the concept of applications that are partly web-based and partly non-web-based/

1. ?
2. EDITORIAL - done.

Guideline A.1.2 [For the authoring tool user interface] Ensure that non-Web-based functionality is accessible.

1. (WCAGWG): We believe that what it means for a non-web-based authoring tool to be functionally equivalent to WCAG 2.0 is undefined. This is very important, but it is a large task and may not be a WAI problem to solve. Could/should desktop accessibility standards like ANSI/HFES 200 Part 2 / ISO 9241-171 be used instead? e.g. "Non-Web-based authoring tool user interfaces follow accessibility standards for desktop software. The following are some example software accessibility standards: ISO, Section 508 1194.21." We don't think that multiple levels are necessary. (A122, A123). These standards don't necessarily have comparable levels.
2. (LGR): Suggest dropping "that are not user agents" from the rationale. Although by the glossary definition, user agents refer to renderers for web content, I think the distinction between a browser that is displaying web content and the same browser displaying a local HTML file will be lost on most readers.

1. ?
2. EDITORIAL - done.

1. (LGR): The rationale is very hard to understand again. "information signified by presentation added by the authoring tool"? "content rendering editing views"?
2. (LGR): SC A.2.2.3: It is confusing that one of the examples used (text size) is already covered by A.2.2.2. You might just omit the examples completely as part of the success criterion.

1. ?
2. EDITORIAL - done.

1. (LGR): SC A.2.3.1 "content rendering editing views" again. Maybe introduce this concept in the introduction? and maybe use a simpler phrase?

1. EDITORIAL - done.
   

1. (LGR): SC A 3.2.3: Why is this limited to components that accept mouse input?

1. (MT4) Yes, this is a good feature! However, isn't this already covered by: A.3.4.2 Navigate By Element Type: If an editing view displays a structured element set, authors can move the editing focus forward/backward to the next instance of the same element.

1. ?

1. (MT1): When working with contents produced by others I also often search for attributes: bold, underline, spesific colours, font size, ... These attributes are hard to find when using a screen reader (at least in contents using several different markings). Therefore I also think attribute/formatting search should have been included in ATAG.
2. (LGR): SC A.3.5: It is confusing that the guideline says "for authoring tool user interface" when the text search appears to address searching the web content. The guideline seems to imply that users should be able to use text search to find menu commands, for instance.

1. ?
2. EDITORIAL - done.

1. (LGR): Applicability notes: Typo: "to to"

1. EDITORIAL - done.

1. (LGR): Part B applicability notes #3: It is very hard to understand the first sentence.

1. (LGR): SC B.1.1.2: What does it mean to provide Web content technology options? does this mean choices of output format?

1. (LGR): SC B.1.2.2 typo: "output of a the transformation"
2. (LGR): SC B 1.2.2 (a): Why "if possible"? does this introduce testability problems?

1. EDITORIAL - done.

1. (WCAGWG): The last “Applicability Notes” for this Guideline includes a rather large exception for third-part content. We recommend handling this with a Statement of Partial Conformance (like WCAG).
2. (LGR): SC B 2.2.1, 2.2.5, 2.2.9: Do reasonable authoring tool checks exist for all success criteria? This could introduce a lot of "noisy" checks that just ask authors to perform a manual check. This tends to clutter up the checking workflow and encourages authors to ignore it.
3. (LGR): SC B 2.2.2: Is this checking the same checking as in SC 2.2.1? If so, is a separate guideline needed?
4. (LGR): Guideline B.2.2 Applicability notes: I don't understand the comment about manual checking, and how this relates to 2.2.1, etc. I hope this doesn't require "checks" of the nature "perform the following manual check".

1. ?
2. ?
3. ?

1. (LGR): SC B.2.3.3: What is "repair assistance"? What does it mean to provide it? Does this just mean that it is possible to repair the error?

1. (LGR): Is it clear how Guideline B.2.4 ("Assist authors with managing alternative content for non-text content.") would apply to website authoring tools? Is it clear how it would apply to content management systems or photo repository sites? See comments below on specific issues with some of these SC. The phrasing of B.2.4.2 leaves things a little vague wrt testing. "can automatically suggest ... under the following circumstances" sounds like it is also ok to suggest under different circumstances, or not to suggest under these circumstances.
2. (LGR): SC B.2.4.1 typo: This includes types of alternative content that may not typically <ins>be</ins> displayed on screen by user agents.
3. (LGR): SC B 2.4.3: Suggest using "data" or "values" rather than "text content", since the latter sounds like it is limited to rendered content, while the repair text is likely to be derived from some sort of metadata.
4. (LGR): SC B 2.4.4: Whose recommendations? It is hard to know whether you have met this SC without knowing that, especially if there are conflicting recommendations from different sources. And for the specific example of null alt text, the authoring tool can't determine whether a null alt is needed or is being used appropriately.

1. ?
2. EDITORIAL - done.
3. ?
4. ?

1. (LGR): "Partial" conformance: ATAG's use of the term partial conformance is different from WCAG's use of the concept, which only applies when a web page contains content that is not provided by the author. Partial conformance does not mean that only some of the SC at a level have been satisfied. Many people misunderstand WCAG's partial conformance to mean something more like ATAG's. Would it be possible to use a different term, to minimize that confusion?

1. (LGR): I suggest not including status as part of a conformance claim. people should not be claiming conformance to a working draft.
2. (LGR): Note on Required Components of an ATAG 2.0 Conformance Claim, item 4: What is the significance of this note? The burden of what? The substance was already covered by pointing out that anyone can make a conformance claim. The note somehow implies that authoring tool developers shouldn't be asked about their products.
3. (LGR): Required Components of an ATAG 2.0 Conformance Claim, 5(b): Must a claim cover all the technologies that can be generated by an authoring tool? can a claim be made for the use of a tool to generate technology X? - oops, I see this is addressed by 59(d). Can (b) be worded so it is clearer? Maybe "(b) A list of the Web content technologies edited/produced by the authoring tool that are covered by the conformance claim."

1. ?
2. JR: EDITORIAL: Note: As stated above, the sole responsibility for the conformance claim is on the conformance claimant. It is not on the developer of any of the software components that make up the authoring tool.
3. ?

1. (LGR): "Progress Towards Conformance" Statement: Iit is extremely unlikely that developers will be able to provide timeline information, even if they have development plans. "encouraged" is ok, but will still probably be the exception.

1. (LGR): Does the Glossary definition of "prominence" provide guidance for objective testing? See comment on definition for a problem with the current definition. Prominence: Bullet c) works if you are comparing the prominence of 2 items, but when there are more than 2 items, it becomes impossible for more than 2 to have the same prominence. This is a problem. the definition probably needs to be generalized to groups of items having the same prominence.
2. (LGR): Accessibility information: "added to" - the implication being that the information would not be present except to provide accessibility. Does adding heading markup or other semantic mark-up count as accessibility information?

1. ?
2. JR: EDITORIAL: Any information that Web content is required to contain in order to conform with WCAG 2.0

1. (LGR): Appendix Editors: Missing close parens: Roberto Scano (IWA/HWG

1. JR: EDITORIAL - done