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. [DRAFT] It is important to note that ATAG 2.0 is not intended to be a "one-stop shop" for guidance on creating accessible Web-based or desktop applications in general. ATAG 2.0 guidelines A.1.1 and A.1.2 require developers to consult relevant existing guidance for this general purpose. The rest of Part A focuses, instead, on the set of accessibility issues that are more specific to authoring tools. That said, we will consider how to provide different views of the techniques.
2. [DRAFT] When previous drafts of ATAG 2.0 had these formulated as one "Relative Priority" Checkpoint, it was a source of confusion for commenters. That said, the AUWG is open to suggestions for more intuitive phrasing.
3. [DRAFT] ATAG 2.0 doesn't have an "Understanding" document as WCAG 2.0 does. The AUWG has been trying to ensure that the e.g.'s are not required for comprehension.
4. [DRAFT] The AUWG will examine each "Applicability Note" to make sure it is really necessary, but in WCAG 2.0 the Success Criteria don't always "stand on their own" either. For example, the extra normative requirements in the Conformance Requirements often affect their applicability. As much as possible the AUWG will try to push the applicability notes into the consolidated lists at the start of Part A and B.

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. [DRAFT] The AUWG tried to follow WCAG 2.0's lead in the use of definition links. We will consider providing a version with all definition links switched off.
2. [DRAFT] The AUWG will examine how other examples could be worked in.

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. [DRAFT] Proposal: Add text "The Introduction includes both normative and informative sections, as noted."

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. [DRAFT] Proposal: "ATAG 2.0 applies equally to authoring tools that are Web-based, Non-Web-based or a combination (e.g., a non-Web-based markup editor with a Web-based help system, a Web-based content management system with a non-Web-based file uploader client)."

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. [DRAFT] Proposal: "When authoring tools or parts of authoring tools (e.g., Web-based help systems) are Web-based, conforming to WCAG 2.0 will facilitate access by all people, including those using assistive technologies along with their user agents."
2. [Draft] Proposal: Move the text up to the authoring tool definition.

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. [DRAFT] The AUWG has already looked at the ISO reference, but since it is not currently free, it couldn't be a normative reference. The AUWG does agree however that the "functionally equivalent" formulation is tricky. Proposal: A.1.2.1 Non-Web-Based Accessible (Level A): Non-Web-based authoring tool user interfaces follow (and cite in the conformance claim) standards and/or platform conventions that benefit accessibility. (Level A)
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. [DRAFT] Proposal: "Authors need access to the information signified by presentation added by the authoring tool. Within editing views that render content, authors need access to the presentation that will be experienced by end users, since the ability to constantly monitor the end user experience is an important part of the workflow when using these editing views."
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. [DRAFT] The reason is that being able to click on an an object with the mouse is a special class of time limits. The issue doesn't affect keyboard users in the same way because presumably they could TAB to the control even it was in motion.

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. [DRAFT] Headers are a special case because they are a group of related but not identical elements. A.3.4.2 says if you are on an H2, you can go to the next or previous H2, but it says nothing about the next or previous H3. Because of the utility of header navigation the WG wanted to ensure it was covered.

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. [DRAFT] Since markup attributes and their values are "information that is text" , they would already be covered by checkpoint A.3.5.1 unless the authoring tool could not be used to modify the content (e.g., a WYSIWYG HTML editor might display SVG without being able to edit it). To help readability, we have changed the e.g. to: "(e.g., text content, text alternatives for non-text content, metadata, markup elements, markup attributes, etc.)." We MIGHT consider another checkpoint if we wanted to add the condition that the search work on views where the elements/attributes were rendered. Currently condition (d) allows the tool to move the user to the view in which the elements/attributes are displayed as text.
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. [DRAFT] Propose replace with: "The success criteria in Part B only apply to support for production of the Web content technologies that are included in conformance profile. "

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. [DRAFT] ???

JR's proposal (http://lists.w3.org/Archives/Public/w3c-wai-au/2009AprJun/0057.html):

1. In B.1.1...

REMOVE Guideline B.1 (this would actually match WCAG 2.0 which doesn't have their "accessibility supported" stuff as a success criteria - instead it is a "conformance requirement")

2. In the ATAG 2.0 conformance profile...

5(b) Included Technologies: A list of the *Web content technologies* (including version numbers) produced by the *authoring tool* that the Claimant is *including* in the conformance claim.
- The *authoring tool* must meet the requirements of ATAG 2.0 during the production of each technology on the list.
- The list must include any *Web content technologies* that are automatically selected by the *authoring tool* (e.g., for *automatic content generation*, as the default technology for *author-generated content*).
- For each *Web content technology*, provide information on how the technology might be used to create accessible Web content (e.g., provide links to technology-specific techniques)

5(c [was d]) Excluded Technologies: A list of any *Web content technologies* produced by the the *authoring tool* that the Claimant is *excluding* from the conformance claim.
- The *authoring tool* is not required to meet the requirements of ATAG 2.0 during the production of the technologies on this list.
- *Web content Technologies* may only be excluded that are not automatically selected by the *authoring tool*.

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.
2. [DRAFT] Proposal: Remove "if possible"

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. [DRAFT] If this was done, the best a tool could do would be to partially conform since almost any tool can have its content changed after authoring (e.g., author swaps in a different image, breaking the alt text). BUT the concept is at least partially covered in Applicability Note 2 of Part B as a whole.
2. [DRAFT] We do include Manual checking as an option. It is up to a dveloper to ensure that the Manual checking process fits with their tool's workflow. Our techniques will clarify the need to reduce the "noise".
3. [DRAFT] This SC just clarifies that the checking must be available at some point before publishing - not just after publishing.
4. [DRAFT] See (2) above.

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. [DRAFT] Proposal: "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 the success criteria for this guideline. "

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. [DRAFT]: Automated suggestion is never required. Here is a proposal to make it clear when automated suggestion is allowed: "During the authoring session, the authoring tool can automatically suggest alternative content for non-text content only under the following conditions: (Level A)"
2. EDITORIAL - done.
3. [DRAFT] Proposal: "After the end of an authoring session, the authoring tool does not attempt to repair alternative content for non-text content using text values that is equally available to user agents (e.g., the filename is not used)."
4. [DRAFT] Checking with HTML4, it actually advises "Do not specify irrelevant alternate text when including images intended to format a page...". Proposal: Remove this checkpoint and rely on WCAG 2.0 to specify the use of these features.

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. [DRAFT] "Limited"? (http://thesaurus.reference.com/browse/partial)

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. [DRAFT] Agreed.
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. [DRAFT] See B.1.1 outcome

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. [DRAFT] Agreed but it doesn't hurt to ask.

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. [DRAFT]
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