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.
5. (AL) Part A contains inconsistencies and unnecessary duplications. An example of inconsistency is the timing guideline. A3.2.2 restricts that the only solution to deal with time limit is to extend the timeout by 20 second response. Yet A1.1 & A1.2 point to WCAG 2.0 and WCAG 2..0 2.2.1 offers much wider range of options including turn off, adjust, extend, real-time exception, essential exception, and 20 hour exception. If ATAG 2.0 A3.2.2 takes all the WCAG 2.0 2.2.1 options off the table except one, very explicit statement has to be made and rationale must be given. Timing is just an example, this inconsistency can be found for animation and other topics. As to duplication, I see A3.1.2, A3.7.1, and WCAG 2.0 2.1.2 as duplicative. Such duplication creates inconsistency and confusion.
6. (AL) Check for testability issues throughout, especially in part B.
7. (AL) Part B is about QA. But QA in the development world is a system of business processes, people, and tools. Yet, the guidelines are relying too much on the tools as the primary method to achieve accessible outcome
8. (IBM) Organization: Since an effort was made to organize the requirements according to WCAG principles, why not also put them in the same order? Perceivable, Operable, Understandable, Facilitating access by AT.

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.
2. (JB) The abstract needs clarification. The non-parallel structure makes it sound as though ATAG 2.0 addresses accessibility of the tool, and only as an incidental consequence supports the production of accessible Web content. Needs to strongly and clearly state up front that this document addresses two separate but important aspects of accessibility and authoring tools.
3. (JB) Introduction, 2nd bullet, this rationale is limited. Point of ATAG is not just because of an assumption that many authors will not be familiar with end user needs, but because of the importance of increased efficiency of support for production of accessible content. I'm not suggesting that wording exactly but think that you need to make that theme more evident here in the introduction.

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.
2. (JB) Notes on the Definition (of authoring tools), first sub-bullet: I think that the use of '"conventional" web page authoring tools' may "date" the document; I believe that the majority of content on the Web is already not produced by these so-called "conventional" tools, and this will be even more the case in the future. No modifier is needed here.
3. (JB) Notes on Def, cont, bullet 2: It is unclear how this note relates to situations where people have limited authoring permissions for one or more areas or aspects of a Web page; e.g. the note seems to carry the assumption that author permission is binary.
4. (JB)Notes on Def, cont, bullet 3: How stable is this definition of "live content authoring tools"? If it is stable, please add it to the glossary. The conformance exclusion that you propose here seems major, and should be addressed within the conformance section; perhaps I am missing it there? The parenthetical explanation left me thinking through various live archiving modes of authoring and wondering if in fact none of Part B should apply, and the note about "many guidelines in Part B may still usefully apply"
5. (IBM) text editors should not be included. We discussed this at length in TEITAC and specifically excluded them in the definition: Any software intended to create or modify electronic CONTENT for publication in one or more formats that support compliance with the user interface and CONTENT provisions. Note: Simple text editors that can only create or modify content in conforming formats by directly editing the code are not considered authoring tools under this definition.
6. (IBM) The Notes on the Definition of what ATAG 2.0 applies to should include - debugging tools for web delivered content. Mozilla is funding a Firebug extension that assists the author in debugging rich internet applications for accessibility - in particular WAI-ARIA. This is a first for the industry and is essential.

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. (JB) Relationship to WCAG 2.0, benchmarks: Perhaps benchmarks needs a definition? Not immediately clear what you mean by benchmarks based on the available context.
2. (JB) Same paragraph as #6, and multiple places in the document, is this usage of "outputted" grammatical?

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"?
2. (JB) Understanding levels of conformance, first list item, "access issues for pwd" -- shouldn't this (and in multiple places) be "accessibility issues"? (And immediately after "the issue be specific" -- word missing?)

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. Accepted. Applicability note is deleted.

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. Accepted: A.1.2.1 Non-Web-Based Accessible (Level A): Non-Web-based authoring tool user interfaces follow (and cite in the conformance claim) accessibility standards and/or platform conventions that support accessibility. (Level A) The applicability note is removed.
2. EDITORIAL - done.

1. (IBM)This is about non-text content - why not state that? Provide access to text alternatives for any non-text content in rendered views of Web content.
2. (IBM)A.2.1.1. The definition of alternative content is inadequate to address this guideline. you may in fact have a flexible system which may require full equivalent replacements for the content defined by user preferences such as a table or accessible datagrid equivalent for a complex visualization. The system may in fact generate alterative content that would be more accessible to an individual user. Although WCAG does not address this ATAG certainly could while still supporting WCAG. How the user specifies this equivalent will be based on their need. ... Think Access for All or ISO DRD/PNP

1. Adopted: A.2.1 Make alternative content available to the author. and Rationale: Some authors require access to alternative content in order to interact with the Web content that they are authoring.
2. We agreed that it is a great example. We aren't precluding it. IBM's point is more generic. We aren't precluding it, we just aren't saying that it is the only means. We can make it available in a universal way. A.2.1.1 Recognized Alternative Content: When recognized alternative content is available@@define??@@ for Web content being edited, the authoring tool makes the alternative content accessible to the author(s).

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.
3. (IBM) 2.2 wording needs to harmonize with WCAG; i.e. use "programmatically determinable" instead of "available via the platform

1. [DRAFT] Proposal: still working on it. Action 160, Jan.
2. EDITORIAL - done.
3. same as #1.

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. Accepted: A.2.3.1 Independence of Display: Editing views that render content (e.g., WYSIWYG) allow the authors' own display preferences @@JR DEFINE@@ to take precedence in the editing view without affecting the Web content being edited (i.e., no effect on markup, style sheets, etc.). (Level A)
   

1. (AL) I cannot discern the rationale for the operations requiring shortcuts per A3.1.1 except that they are popular in desktop apps. The list is largely invalid outside of the desktop application space.
2. (IBM) A.3.1.1 - Most OS platforms have standard accelerator keys for these functions. If they don't, should we really require it for authoring tools? Seems like that would put the authoring tools out of sync with the platform?

1. A.3.1.1 Keyboard: All functionality of the authoring tool is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. (Level A)
2. A.3.1.3 Keyboard Shortcuts: The authoring tool provides keyboard shortcuts. (Level AA)
3. A.3.1.4 Customize Keyboard Access: The authoring tool allows authors to customize keyboard access. (Level AAA)

1. (LGR): SC A 3.2.3: Why is this limited to components that accept mouse input?
2. (AL) A3.2.2 restricts that the only solution to deal with time limit is to extend the timeout by 20 second response. Yet A1.1 & A1.2 point to WCAG 2.0 and WCAG 2..0 2.2.1 offers much wider range of options including turn off, adjust, extend, real-time exception, essential exception, and 20 hour exception. If ATAG 2.0 A3.2.2 takes all the WCAG 2.0 2.2.1 options off the table except one, very explicit statement has to be made and rationale must be given. Timing is just an example, this inconsistency can be found for animation and other topics. As to duplication, I see A3.1.2, A3.7.1, and WCAG 2.0 2.1.2 as duplicative. Such duplication creates inconsistency and confusion.
3. (IBM) A.3.2.2 should be deleted as it duplicates and is more restrictive than WCAG 2.0 2.2.1.
4. (IBM) A.3.2 - since moving targets doesn't seem to have anything to do with time limits. Maybe A.3.2 should be more broadly worded. I think the original wording (from the techniques document Enable time-independent interaction. makes more sense.

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.
2. Used the WCAG text.
3. Used the WCAG text.
4. Accepted: Rationale: Some authors who have difficulty typing, operating the mouse, or processing information can be prevented from using systems with short time limits or requiring a fast reaction speed, such as clicking on a moving target.

1. (JB) Guideline A.3.3 "photosensitive epilepsy". Please use the more generic term, "photosensitive seizure disorder" instead of photosensitive epilepsy, so that it is also inclusive of non-epileptiform stimuli-sensitive disorders, for instance photomyoclonus, paroxysmal non-kinesigenic dyskinesia, etc. I believe that this correction has been requested previously.

1. Accepted.

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.
2. (IBM) A.3.4.1 The definition of structured element sets is too limiting. It should not just in include organized elements. Headings are considered structural yet in and by themselves they do not imply a collection of organized elements. ARIA landmarks should be included as well. The definition of structured element should be that of a significant semantic areas of the page which in turn support the structure of the web page. You might even refer to the WAI-ARIA taxonomy to see how we defined our ontology for the structured elements.
3. (IBM) A.3.4.3 - what if the structured element set doesn't have a "heading" element? what if there are no headings in the content being edited? "Heading" seems very technology specific. WAI-ARIA has a concept called "landmarks". Moving focus to the previous landmark would be the same concept but not required by this SC because it's specific to "heading". Regarding A.3.4.3 Navigate By Headings: I think you need to define "heading"?
4. (IBM) A.3.4.4 Navigate Tree Structures: I would refer to a hierarchical structure rather than a tree structure - hierarchical is a more generic term to me. A.3.4.3 Your definition of structured element sets would not appear to include headings but it should.

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.
3. (IBM) dont understand use of web content here, shouldn't this apply to editing views, this applies that the web content is output of the tool, should this be covered in B

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. It is part of the user interface to provide the search. We changed the text of A.3.5 to Provide text search of the content. and
3. Adopted: Rationale: Authors who have difficulty typing or operating the mouse benefit from the ability to navigate to arbitrary points within the Web content being authored.

1. (IBM) A.3.6.1 and A.2.6.2 - If these are configurable from the desktop are they also require by the authoring tool? - If authoring tools are required to be WCAG compliant, why are previews a special case? It would seem that they should be subject to the same set of rules. - Why is there a reference to UAAG 1.0? Has the ATAG working group looked at UAAG 1.0 and identified guidelines that if employed would be counter WCAG 2.0 and ATAG 2.0 objectives or today's best practices? For example, guideline 4.1 is outdated in UAAG. All user agents today provide full magnification rather than just text which is much more accurate. Should you still be require font size increases.

1. They only apply when the authoring tool is controlling its own settings and not passing through the platform settings.

1. (IBM) Guideline A.3.7 [For the authoring tool user interface] Ensure that previews are as accessible as existing user agents. I understand what it means after I read the additional material but this is a case where the definition of "previews" doesn't really help me to understand this text. I think you mean the authoring tool's rendering of the Web content in a WYSIWYG manner must be accessible (and A.3.7.2 provides the accessibility requirements). I don't think you should compare to "existing user agents" as not all of them may meet the criteria set forth in A.3.7.2. How can you have an authoring session without an author available? Author Availability: Any success criteria in Part B that refer to authors only apply during authoring sessions when authors are available. A.3.7.2 - agree with Rich that this is a little weird but not for the same reason. First of all, principles A.2, A.3, and A.4 only apply to editing views. So, the exception for previews is already there. And it doesn't make sense to include preview requirements under a principle that applies A.4.2.1 and A.4.2.2 - needs editorial work. When I first read it, I didn't get it as all product features are required to meet part A. But then I realized it's trying to say that if your product has implemented functions in support of the requirements in Part A, you have to document those functions An example would help to clarify this:

1. It is a preview, so it may not yet be fully accessible. It is valuable to the author to know how the current content will be rendered. It is covered by the UAAG guidelines, because it is a user agent at that point.

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

1. EDITORIAL - done.

1. (JB) Guideline A4.2 rationale: The logic of this rationale seems odd; it seems to imply that undocumented features are intuitively designed, which is probably rarely the case.
2. Success criteria A.4.2.2 "Tutorials are provided for some of the features" seems to need more precise quantification to be testable.

1. Adopted
2. Removed because it is important for Part B and impractical to require for Part A.

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

1. Adopted: "Existing Technologies: The success criteria in Part B only apply to support for production of Web content using the Web content technologies that are included in the conformance profile. "

1. (IBM) B.1.1.1 Tool Choice of Technologies: Only accessible technologies are ever automatically selected by the authoring tool. (Level A) Guideline B.1.1 This seems to restrictive. An authoring tool may support include support for all kinds of markup. If one markup, like SVG, which does not fully support assistive technologies is chosen the whole rest of the tool fails? Recommend that the author be given the choice of choosing only accessible technologies. In that mode it should be considered to satisfy this guideline - unless there are none. This section should also allow for the selection of equivalent alternatives that are accessible. Take a Mashup authoring tool. A chart may be inaccessible but a table equivalent may be acceptable. You might even take into account user preferences. The section refers to accessible Web content but the definition of accessible web content refers to a particular level of WCAG. Why should an ATAG 2.0 compliant tool support WCAG 1.0 when in fact the guidelines for being ATAG 2.0 compliant require that the authoring tool meet WCAG 2.0 requirements? I disagree that this should include all versions of WCAG. Need to make sure this can be tested.

1. (LGR): SC B.1.1.2: What does it mean to provide Web content technology options? does this mean choices of output format?
2. (JB) Success criteria B.1.1.2 (Author choice...) If I did not already think that I knew what this meant, due to having mulled over it a fair amount in the past, I am not sure that I would understand what it means from how it is phrased here. I suggest further rephrasing.

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?
3. (JB) Success criteria B.1.2.1. (Preserves info...) Ditto my comment in #12, but slightly more so. (If I did not already think that I knew what this meant, due to having mulled over it a fair amount in the past, I am not sure that I would understand what it means from how it is phrased here. I suggest further rephrasing.)
4. (JB) B.1.2.3.(a) "that it can detect is not accessibility" suggested replacement "that it can determine not to be accessible"
5. (IBM) There may be a situation when the target markup does not support an accessibility feature of original content. For example, a document markup may provide for short text equivalents and long descriptions on a drawing object but the target document may not. There is nothing the tool can do about it. So, the point is that you should allow some leeway.

1. EDITORIAL - done.
2. [DRAFT] Proposal: Remove "if possible"

1. (IBM) The checking and repair guidelines are problematic to me. You will allow manual checking - which essentially means the tool has to do nothing but provide documentation on how to make content accessible - but then require support for repair? Can assisting with repair be satisfied also by providing documentation on how to make content accessible? That seems to let the tools completely off the hook. It might allow a text editor to pass but I don't think that a more sophisticated tool should be allowed to get away with that - although I guess that is why we have different levels. Hopefully the more sophisticated tools will conform to higher levels. But, I would hate to allow a tool like Dreamweaver to be able to claim level A compliance and also a text editor like TextPad to also claim level A compliance.

1. (JB) B.2.1.1., B.2.1.2, B.2.1.3.: "then automatic prompts are also included for any..." the use of "included" here seems unclear. Instead, perhaps "available" or "turned on"?
2. (IBM) Could Guideline B.2.1 Guide authors to create accessible content. be met by prompting the author to run an accessibility checker tool (linked to or provided with the authoring tool software) before closing a document and then relying on the tool to provide a list of errors that need to be fixed? Wait, after I read this a few times I realized that a11y prompting is only applicable if the authoring tool prompts for some information. Thus, this wouldn't apply to a text editor.

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".
5. (IBM) WCAG 2.0 is very vague on how to meet robust in terms of interoperability with assistive technologies. This section should:
   - Ensure that assisting authors in checking even as the document changes dynamically even when script is used to change the document as you operate it. This is a huge problem with today's tools
   - Authoring tools SHOULD test that custom components in RIAs conform to common design patterns. For example, if an author creates a tree widget it should conform to ARIA best practices guides. At the very least this should be a Level AA requirement. We recommend the ATAG group look at this web site: http://www.openajax.org/member/wiki/Accessibility . Although this site is in wiki form and not in what we would call cleaned up it should give you some insight.
6. (IBM) B.2.2.4 - help authors decide what?
7. (IBM) B.2.2.8 - until we have standards for such metadata, it should be a AAA requirement, not AA

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?
2. (JB) B.2.3.1., 2.3.2., 2.3.3. "repair assistance is provided" -- is there a clear expectation of what "provided" means here?

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.
5. (IBM) Guideline B.1.2.4 Do you want to notify when the target markup does not support an accessibility feature? This is a problem as it is not clear WCAG 2.0 specifies that web content is accessible but what if the host language has a hole. For example the keyboard navigation problems in HTML 4.0 is a problem. Authors can work around a lot of it by using anchor elements. However, some document formats have more accessibility features than others and WCAG does not quite address the deficiency. I am avoiding a reference to particular document formats.
6. (IBM) Guideline B.2.4.2 the statement is made: During the authoring session, the authoring tool can automatically suggest alternative content for non-text content under the following conditions: (Level A)

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. (IBM) This suggests that only accessible templates be allowed. Should this be based on an accessible mode? B.2.5.3, B.2.5.5 - 2.5.8 - since most templates, clip art images, widgets, etc. are simply selected from a standard file directory, this would seem to indicate a requirement to attach the accessibility status to the file somehow. Since neither the file formats nor the file systems support that today, it seems like too onerous a requirement to impose at AA. This should be moved to AAA.
2. B.2.5.3, B.2.5.5 - 2.5.8 - since most templates, clip art images, widgets, etc. are simply selected from a standard file directory, this would seem to indicate a requirement to attach the accessibility status to the file somehow. Since neither the file formats nor the file systems support that today, it seems like too onerous a requirement to impose at AA. This should be moved to AAA.

1. (IBM) While this is an excellent guideline it may be difficult for the ATAG author to know when they are done in all scenarios as there are no tools to assist them.

1. (IBM) B.3.3.1 - this may be a show stopper for some tool developers. In an enterprise type of content management system, I can see how you would want an administrator function to enforce this. But it seems unreasonable to require this of all ATAG A conforming tools. It should move to level AAA.

1. (IBM) B.3.4 - rationale doesn't make sense if B.3.3.1 remains at level A. :)

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. (JB) Conformance: Disclaimer: AUWG acronym is AUWG not WAI-AUWG, please remove "WAI" here (two instances)

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