DRAFT Responses to Comments on
ATAG 2.0 (7 December 2006) Public Draft:

1. BG: I like the organization of the requirements into parts A and B to address the user interface and the generated content.
2. BG: It is nice to see the same definitions of terms shared with WCAG
3. BG: Nice section on providing prompting! I was nervous when I first read the SC that said prompting was required (I really hate overly restrictive prompting) but the techniques document helps to clarify.
4. BC: The section "How the guidelines are organized" does a nice job of describing which sections and subsections of a guidelines are informative vs. normative. It might be useful to incorporate something similar in the WCAG 2.0 intro.

1. #1: BG: I have some concerns about the use of examples in parentheses within the Success Criterion (SC) text. While it is helpful to understand what the SC is about, I think it sometimes narrows the definition.
2. #2: LGR: Is WCAG still planning to publish Technique documents for specific content types? ATAG has links to what I think are obsolete techniques documents.
3. #3: BC: (bug) All of the icons used in part A and B of the draft implementation techniques documents include relative links to nonexistent anchors.
4. #4: MC: 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.
5. #5: MC: 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.
6. #145: EOWG: Introduce concepts and terms before they are used. For example, several things in the "Relative Priority Checkpoints" section are required to understand the point, but have not yet been introduced or explained; for instance: "Part A" & "Part B", "conformance profile", "content type-specific WCAG benchmark".
7. #147: EOWG: [editorial] In several places, the links cause some reading difficulties (since they are emphasized by both color and underline), especially when only part of compound nouns are linked. For example, in the introduction, in the second sentence, "...assisting authoring tool developers to...", the word "developers" gets lost and instead it should be the focus. In other places, links may be unnecessary, e.g. the links in '(e.g., an HTML editor with both code-level and WYSIWYG editing views)' go to the bullets right underneath; instead of links, put 'described below'.
8. #148: EOWG: Consider providing a resource like the WCAG 2.0 Quick Reference (note though that this may be renamed) where users can get a version of the ATAG 2.0 guidelines and techniques that apply specifically to their project by filtering based on options such as WCAG version, WCAG priorities, and type of tool. For example, users would choose the relative priority up front, and then the options for filtering would take care of sorting out the relevant priorities (since "relative priority" is a complicated concept to understand).
9. #149: EOWG: Add a link at the top of the document to the [Contents] (as is done in many W3C specifications).
10. #151: EOWG: Consider mentioning the following as one among several overarching principles (or a quick tip?) for the document: "If the authoring tool is Web-based, then the user interface should be WCAG-compliant, and the content that is produced should be WCAG-compliant."

1. #1: Agreed that this might be a problem, but as you say, it does help to clarify the meaning of the Success Criteria.
2. #2: We have fixed those references.
3. #3: Editorial: Fixed.
4. #4: We have reworked the introduction and conformance sections to meet this comment.
5. #5: We now use the WCAG 2.0 organization.
6. #145: We have attempted to do this where possible.
7. #147: Editorial: Fixed.
8. #148: "Relative Priority Checkpoints" concept had been removed which will hopefully simplify the situation.
9. #149: Editorial: Fixed.
10. #151: As the very first Guideline in a reordered Part A we believe this requirement now has better visibility.

1. #6: BC: Suggest moving the section "How the guidelines are organized" to a location earlier in the document. Knowing about Part A and Part B seems important to understanding much of what is in conformance (ex. relative vs. regular priority).
2. #7: MC: First sentence says “Authoring Tool Accessibility Guidelines (WCAG)”: correct acronym
3. #140: EOWG: The dependency between ATAG 2.0, and WCAG 1.0 and WCAG 2.0, needs to be clarified in the Introduction.
4. #141: EOWG: Briefly mention in the Abstract that ATAG 2.0 applies to both WCAG 1.0 and WCAG 2.0.
5. #152: EOWG: Since relative priority is such a key concept for ATAG conformance, introduce it in the Introduction.

1. #6: This has been achieved by moving the conformance section below the guidelines.
2. #7: Editorial: Fixed.
3. #140: Done
4. #141: OK
5. #152: The "Relative Priority Checkpoints" concept had been removed.

1. #8: MC: 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.
2. #9: UAWG informal: In Definition of Authoring tool - define plug-in
3. #118: CR: the Definition of Authoring Tool should extend to include a bullet that describe tools like Rational manual tester that generate web content as an Export feature.  This is a case that can be easily overlooked. I can exemplify with a basic example of images: have the ability to provide alt text to images they paste in the script in the RTE and that alt text must carry though on export.  This is likely the same text that should be supplied for the MSAA Name value.
4. #135: ERTWG: While the definition of an "authoring tool" is non-trivial and ideally addresses all components that are part of a Web development process, the currently proposed definition seems to be too broad. For example, image and plain text editors are regarded as Web authoring tools even when they are "used separately".
5. #150: EOWG: ATAG should apply to modular components (such as widgets) of the authoring tools as well as to the authoring tools themselves.

1. #8:The definition of "collection of software components" has been moved to the Glossary.
2. #9: Plug-in defined in the glossary.
3. #118: This should already be covered by the existing definition.
4. #135: We intended to cover image and plain text editors by the definition because these tools are often used to create Web content, either alone or in conjunction with other tools. However, if a developer does not wish to make an ATAG claim that is their choice.
5. #150: ATAG applies to whatever extras go into the conformance claim, so optional widgets can be covered. Non-optional widgets are always covered.

1. #10: MC: 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. #146: EOWG: The content in 1.2 does not entirely match the heading ("Role of authoring tools in Web accessibility"). Re-examine the content for suitability in this document, possibly moving some material out and pointing to it in another document(s); or break up the content into different sections; or broaden the heading.

1. #10: Editorial: This has been worked in.
2. #146: The important points in this section have been combined into the introduction.

1. #139: EOWG: Consider moving the conformance section after the guidelines themselves, though still keeping it a part of the main document (as opposed to putting it in an appendix);

1. #139: Editorial: This has been done.

1. #11: BC: Would removing the distinction between relative priority and regular priority checkpoints make conformance easier to understand? Given that there's no difference in a conformance claim (A, AA, and AAA the same thing regardless of checkpoint priority), I'm not sure it's necessary to make a distinction here. I found myself spending a lot of time trying to understand the difference between the two as I worked through the intro, but it seems like this is covered through requirements for conformance claims and sufficient techniques for the relative checkpoints.
2. #12: MC: 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.
3. #13: AL: What happen to the QA tool assist the author in some of the WCAG fulfillment but not 100% of it? For example, what type of claim can the tool claim if the only shortcoming is not being able to meet B.2.1 for WCAG 2.0 3.1.4. Do you think it is feasible for a QA tool to fully meet all requirements in part B fully consider the judgment required for meeting some of the WCAG requirements? Is there such a tool that can fully meet ATAG 2.0 priority 1 in the market today? You need to allow conformance claim for part A and part B separately because many products are pure author tools and some are pure QA tools. It would be impossible for the tool makers to make any claim unless the claim is bundled with another tool, likely from a different company. This would be inappropriate because it would require one vendor to make claim on product(s) belonging to other tool maker(s). It would likely not get out the door of most legal departments. The market confusion would multiply if different authoring tool makers make different evaluation on the same QA tool or vise versa. The situation may get even worse if multiple authoring tools and QA tools are needed. Separation is essential. Moreover, it is important to appreciate that good web accessibility requires tight development and QA "PROCESSES". I think it is misguided for anybody to think that a TOOL can handle QA auto-magically all by itself. It appears to be an assumption that the working group is focusing on a lone developer+QA scenario. That is not a good assumption at all, because almost all development environment for almost all commercial products/web services involves a dynamic combination of process control, management, skill/knowledge, and, to a relatively small degree, a set of tools. Without the other factors, no tool can produce accessible product in any degree of reliability.
4. #14: WL: "the whole business of relative priorities is dense/opaque/impenetrable and although I have no specific language that will change that, it is important that further effort be expended trying to make this dark thing clear."
5. #15: KHS: What are Part A and Part B? This information is not explained until much further in the document. Perhaps should be referred/linked to from Abstract or Intro. Suggestions:
   Change "Significance in Part A:" to....
   "Significance in Part A - Authoring Tool User Interface:"
   And link down to PART A in the document.
   Change "Significance in Part B:" to....
   "Significance in Part B - Content:"
   And link down to PART B in the document.

1. #11: The "Relative Priority Checkpoints" concept had been removed.
2. #12: We have now gone to the same structure as WCAG which has Conformance Levels followed by Success Criteria.
3. #13: We have created a "Partial" conformance mechanism to meet Part A or B separately. The definition of authoring tools already allows multiple tools to be group under one "umbrella" for a conformance claim.
4. #14: The "Relative Priority Checkpoints" concept had been removed.
5. #15: We believe we have clarified this.

1. #16: LGR: ATAG conformance appears to be user agent based, not technology based; conformance claims for web-based functionality must list the name and versions of user agents tested against. Oddly enough, for non-web-based functionality, comparable info is required for the OS, and the accessibility API must be listed, but there seems to be no requirement to test against AT.
2. #17: LGR: An ATAG conformance claim includes documenting how each SC was satisfied! I don't think we are going to see many ATAG conformance claims written up...
3. #18: MC: 2.2 - conditions: ... 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.
4. #19: MC: ...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.
5. #143: EOWG: Provide one or more example conformance statements. Put these in a separate document and point to them from the ATAG 2.0 specification.
6. #144: EOWG: Also note that the fourth point asks for a description of how the normative success criteria were met for each of the checkpoints that were required; that seems a lot to ask for. Perhaps the example would help clarify that this is a requirement for brief comments, and not detailed descriptions.

1. #16: The user agent reporting requirement is there as equivalent to the "platform" requirement for Web-based tools. Testing with an AT would be helpful to determine conformance to Part A and should appear as a note or technique.
2. #17: We have moved this to be an optional item: "A description of how the normative ATAG 2.0 success criteria were met where this may not be obvious."
3. #18: The subjective element of the Benchmark document means that public disclosure is required for transparency.
4. #19: Editorial: This is fixed.
5. #143: Agreed (we will pursue this for the Last Call draft).
6. #144: We have moved this to be an optional item: "A description of how the normative ATAG 2.0 success criteria were met where this may not be obvious."

• Content Type-Specific WCAG Benchmark

1. #20: BG: I have concerns with reliance on the "content-type-specific WCAG benchmark document" in the checkpoint and success criteria text. Since the definition indicates that the WCAG techniques document for a particular content -type meet this requirement. But, the WCAG techniques are informative and there are not necessarily techniques for every WCAG success criteria for every content-type. Where would the general WCAG techniques fit in? There are many HTML techniques but many fewer for CSS and scripting. What if someone creates a tool that uses ARIA (Accessible Rich Internet Applications from the WAI Protocols and formats group) techniques when creating content? There are currently very few WCAG scripting techniques to support ARIA. Since there are some techniques is there a sufficient content-type-specific WCAG benchmark document"? I think this needs further description / clarification. Also, currently WCAG does not publish the techniques for different content-types in separate documents.
2. #21: LGR: "ATAG 2.0 requires published content type-specific WCAG benchmark documents" - this seems worrisome. Who publishes these?
3. #22: LGR: ATAG makes WCAG techniques normative for a particular conformance claim. Given that we view those documents as non-normative, and that they will change over time, this seems problematic.
4. #23: BC: I have a number of concerns about the content type-specific WCAG benchmark...Who publishes benchmark documents? This is a major coordination point between the working groups that needs discussion.
5. #24: BC: Since WCAG 2.0 techniques say nothing about conformance to WCAG itself, the benchmark document should refer to some combination of the How to Meet and techniques documents. Not sure his model works unless the benchmark specifies sufficient techniques or combinations of techniques that meet WCAG 2.0. Has the ATAG WG created any sample benchmark documentation to illustrate how this might work?
6. #25: BC: All of the references to WCAG 2.0 techniques documents ([WCAG20-TECHS-GENERAL], [WCAG20-TECHS-CSS], [WCAG20-TECHS-HTML], [WCAG20-TECHS-SCRIPTING]) should refer to http://www.w3.org/TR/WCAG20-TECHS/ (the WG is no longer publishing tech-specific techniques documents)
7. #26: BC: "All of the requirements in the Benchmark become normative..." This implies that a benchmark document can define conformance to WCAG 2.0, but it's not clear how a benchmark document would address (1) situations in WCAG 2.0 How to meet documents and (2) situations where multiple sufficient techniques or combinations of techniques meet a criterion. The concern here is that it sounds like a benchmark can include only a subset of the WCAG 2.0 sufficient techniques and then be used to define (by example) WCAG 2.0 conformance.
8. #27: MC: 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.
9. #28: MC: 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.
10. #29: MC: 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.
11. #30: CS: Content Type-Specific WCAG Benchmark: when a conformance claim references a non-W3C benchmark, and this benchmark disappears (so no one can check the claim), how does this affect the validity of the conformance claim? If the benchmarks moves to a different URL, how does this affect the validity of the conformance claim? Please specify.
12. #31: CS: WCAG Techniques documents can be used as benchmarks referenced by conformance claims, but the WCAG 2.0 techniques documents are meant to evolve even after WCAG 2.0 is finalized. So if conformance claims reference benchmarks that evolve, references should always be to dated versions (e.g. dated URLs instead of "current version URLs" on W3C servers). (Or is that covered by § 3.c of "Components of an ATAG 2.0 Conformance Claim"?)
13. #32: CS: When referencing documents as a benchmark, should those documents fulfil certain requirements? The WCAG 2.0 Techniques document uses a format that, for example, always requires a test procedure and expected results. It seems useful to define (at least some) requirements that benchmark documents need to fulfil.
14. #119: RS: Comments on Section 2.2 Conformance claims. I think the concept of Baselines should be introduced here as it is appropriate. Is WCAG Benchmark a new name for Baseline?
15. #120: Also, the document seems to have blurred Part A and Part B here when the intent was to be separated.
16. #142: EOWG: Consider whether "Content Type-Specific WCAG Benchmark" belongs within the ATAG 2.0 spec. It seems better to put it in a separate document and point to it from the ATAG 2.0 spec.
17. #153: EOWG: The concept of content-type specific WCAG benchmarks is not sufficiently clear from the description, nor how to implement it; and the developer is pointed to too many resources for details on how to implement this. For example, EOWG readers had the following questions: Is "content-type specific WCAG benchmark" different from a Techniques document? Does "content-type specific WCAG benchmark" need to be normative? Should the authoring tool developer write the "content-type specific WCAG benchmark," or the vendor?

1. #20: The "content-type-specific WCAG benchmark document" idea is specifically intended to deal with the problems you point out: (1) WCAG techniques documents being informative rather than normative, (2) WAI creating techniques documents for only a few formats (and not always as separated docs as you say), (3) New formats being created all the time.
   To that end: (1) ANYONE can create a benchmark document (so an authoring tool developer doesn't have to wait for WAI), and (2) an informative techniques document BECOMES normative for a GIVEN conformance claim by the act of including a reference to the techniques document in the conformance profile of that conformance claim. This has been reworded for clarity.
2. #21: Anyone can create a benchmark document (so an authoring tool developer doesn't have to wait for WAI). The catch is that it must be made public. This has been reworded for clarity.
3. #22: ATAG 2.0 does not make WCAG techniques normative. It says that a tool will be held to the benchmark document that it specifies in a conformance claim. This has been reworded for clarity.
4. #23: Anyone can create a benchmark document (so an authoring tool developer doesn't have to wait for WAI). The catch is that it must be made public. This has been reworded for clarity.
5. #24: The WG has not created a sample but will as part of the process.
6. #25: Editorial: This is fixed.
7. #26: The benchmark creator can use any doc they like in the process. We aren't defining WCAG conformance because authoring tools don't "meet" WCAG. This has been reworded for clarity.
8. #27: Editorial: This is fixed.
9. #28: This has been reworded for clarity.
10. #29: This has been reworded for clarity.
11. #30: We reworded to say the Benchmark must be included in the claim information.
12. #31: The Benchmark doesn't reference outside material - it must be self-contained.
13. #32: An interesting idea.
14. #119: The Benchmark is a bit like a Baseline. It spells out what the developer understands to be the accessibility-related environemnt. However, it would probably be confusing to use the same word in two somewhat different situations (i.e., degree of support for technologies vs. a description of the accessibility features of technologies).
15. #120: Baseline can apply in Part A for Web-based functionality.
16. #142: We believe that with the rewording this concern should be diminished.
17. #153: We believe that with the rewording this concern should be diminished.

1. #159: EOWG: For the entire part A of the guidelines, the use of "For the authoring tool user interface" at the front of each checkpoint makes the checkpoints more difficult to understand. Consider bracketing this phrase and capitalizing the following phrase, for instance: "A.1.1 [For the authoring tool user interface] Provide text alternatives for all non-text objects. [Priority 1]" so as to keep the context you need, but allow your readers to focus on the primary information in each checkpoint.
2. #160: EOWG: The use of some terms from WCAG, such as "perceivable," is not clear in the context of ATAG. To the extent that these terms are being used in the same way as they are in WCAG -- which it mainly appears that they are, except the fourth one where the term has apparently changed to system-friendly -- they should be re-explained for this document. Consider adding a new section (up front, or in higher level document) that explains the use of these terms for this document.
3. #161: EOWG: Editorial suggestion:
   * /TR/ATAG20 is a formal Technical Specification/W3C Recommendation/Standard that is stable and referenceable. Keep it simple and succinct. Generally, include in /TR/ATAG20 only what is important for the actual technical specification. Move the supporting information to other documents, and in /TR/ATAG20 briefly mention the topics, and then point to the external documents.
   - Examples:
   "These guidelines have been written to address the requirements of many different audiences, including, but not limited to: policy makers, technical administrators, and those who develop or manage content. An attempt has been made to make this document as readable and usable as possible for that diverse audience, while still retaining the accuracy and clarity needed in a technical specification."
   "As an introduction to accessible authoring tool design, consider that the authors and end users of Web content may be using the tool and its output in contexts that are very different from that which may be regarded as typical. For example, authors and end users may:... have a text-only display, or a small screen.",
   "In addition, following the guidelines provides benefits for authors and end users beyond those listed in these various disability-related contexts. For example, a person may have average hearing, but still require captions for audio information due to a noisy workplace. Similarly, a person working in an eyes-busy environment may require an audio alternative to information they cannot view."
   - Rationale:
   In addition to simplifying the normative doc, this puts the explanatory information where it can be updated to reflect changes over time as necessary. It also limits the the need for repetition across documents, and the potential for that information to get out of synch.
   - Note:
   Shawn submitted a similar comment on WCAG 2.0:
   - http://lists.w3.org/Archives/Public/public-comments-wcag20/2006Jun/0224

1. #159: Editorial: Done
2. #160: A section has been added that explains the usage with much the same text as WCAG 2.0 does.
3. #161: Reworded to take these points into account, but still in one document. Rationales are still in.

1. #33: BG: I'm not sure how A.0.1 fits into the organizational scheme? From reading above about how the guidelines are organized it implies that checkpoints are associated with Guidelines? But A.0.1 is not associated with a Guideline - is that the point of using a A.0 designation? I originally just assumed that you were using a zero based numbering scheme but then I scrolled down and noticed that Part B begins with a Guideline and the numbering starts at B.1. I think that the positioning of A.0.1 needs to be clarified.
2. #34: LGR: I'm a bit confused by A.0.1. Even with the rationale and note, it took me a while to sort out that this only applies to aspects of the tool that are displayed on the web. For non-web-based authoring tools, this is probably nothing. For web-based authoring tools, they are web content; I guess this just says that web content needs to conform to WCAG.
3. #35: BC: A.0.1 SC1 seems like it should mention content rather than just functionality. (ex. Content that includes Web-based authoring tool user interface functionality must conform to WCAG.) WCAG 2.0's use of "functionality" (def. processes and outcomes achievable through user action) may be part of what's confusing about this.
4. #36: MC: 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.
5. #121: RS: A.0.1 There needs to be a discussion of the Benchmark or Baseline.

1. #33: This has been fixed. It is now A.1.1.
2. #34: Reworded as A.1.1..
3. #35: The definition of authoring tool user interface, Web-based has been changed to reflect this.
4. #36: This has been fixed. It is now A.1.1.
5. #121: "Any assumptions about user agents available to authors or end users." has been added to the list of items required in a Benchmark.

A.1.1 For the authoring tool user interface, provide text alternatives for all non-text objects. [Priority 1]

1. #37: LGR: A.1.1, SC 3 has an ambiguity: I first read it to say that text alternatives must be displayed in the content being edited, but I think it means to says that that there must be a way to display all text alternatives (and that text alternatives are required for non-text objects in the content). Similarly for A.1.2 SC 2. I'm not sure whether it would be clearer to paraphrase: "All editing views must include an option to display the text alternatives provided for non-text objects in the content being edited."
2. #38: LGR: Why does A.1.1 SC 2 address multimedia? Shouldn't that be an A.1.2 SC?
3. #122: RS: A.1 Text Alternatives should include short and long descriptions(help text) for non-text object. ODF and HTML both provide for these. Also ARIA has an aaa:describedby property to reference the long description.

1. #37: Agreed. A.2.1.1 reworded to take this into account.
2. #38: Agreed. Moved to A.2.2
3. #122: A.2.1 covers this.

1. #111: SR: A.1.2. Why isn't synchronized alternative for MM considered P1 consistent with WCAG?

1. #111: Agreed. This has been done.

1. #39: BG: For A.1.3 shouldn't there be a requirement that the authoring tool provides a mechanism to use the operating system display /audio selections (let the platform control the settings)? The requirement is there that the user must be able to select the same settings in the tool but it would be nice to have an option for automatically using the platform settings This would avoid users having to modify the tool to match the operating system display settings. I see that this is covered in the technique section. Perhaps it is standard practice in most operating systems to rely on the platform settings as the default settings that the ATAG group doesn't feel this needs to be made a requirement?
2. #40: AL: A.1.3 SC1--"...authoring tool must provide at least the same configurable properties with at least the same configuration ranges as the platform." I don't think that can be confirmed one way or the other unless the method of configuration between the authoring tool and the platform are exactly the same. They are usually not the same. That's goes the same with audio for part 2. You should also consider that authoring tools can provide additional configuration option "on-top-of" the platform. Thus, the authoring tools may extend the configuration options, even though its range may appear lesser than that of the platform.
3. #41: LGR: I'm worried that satisfying WCAG does not satisfy UAAG, and that WCAG relies on UAAG requirements to make effective use of programmatically determined properties of the content. In this case, the authoring tool is the user agent for this web content, I think. This seems related to A.1.3, but I haven't worked out how. In particular, I don't think that satisfying A.0.1 for web-based authoring tools will necessarily meet this checkpoint, depending on the characteristics of the user agent.
4. #4.2: KHS: In areas in the document where 'visual display' is used, contrast should be included with e.g..
5. #4.3: KHS: In areas in the document where 'audio display' is used, should voice control speed, emphasis, inflection and/or intonation be included in e.g.?
6. #123: RS: A.1.3  ... If the visual display (e.g., fonts, sizes, colors, spacing, positioning) is controlled by the authoring tool rather than by the platform , then the authoring tool must provide at least the same configurable properties with at least the same configuration ranges as the platform. Someone should make a request that UAAG follow a similar requirement. This is not specific to an authoring tool.

1. #39: We actually meant for this to be the case. It has been made more clear.
2. #40: We have reworded this and used the term "comparable" to be more flexible.
3. #41: The note re: Web-based tools meeting WCAG has been removed.
4. #42: Usually "contrast" is not set directly. Instead the user chooses the foreground and background color preferences separately.
5. #43: This change made in the glossary.
6. #123: Agreed

1. #44: UAWG informal: Wanted clarification of A.1.4 SC1 - maybe "final rendering of content"
2. #154: EOWG: A.1.4 is difficult to understand. It currently states "For the authoring tool user interface, ensure changes to the display settings of editing views do not affect the content being edited." How about instead: "For the authoring tool user interface, ensure that changes to the display settings of editing views do not affect the content." Then also remove "being edited" from the success criteria. Note that the lead-in phrase on success criterion 3 is ambiguous: "Editing views that have their display characteristics set by rendering the content being edited (e.g., WYSWYG editing views) must override these characteristics..."

1. #44: Wording clarified and the success criteria has been folded into the original A.1.3 which is now A.2.4.
2. #154: Wording clarified and the success criteria has been folded into the original A.1.3 which is now A.2.4.

1. #45: BG: A.1.5 - I'm not sure what a "semantic description" is. There is an example in SC 3 but an example for SC 2 would also be helpful - what is a semantic description of coloring misspelled words?
2. #46: LGR: A.1.5 SC 3 "the semantic description of the presentation" probably wants to be "the semantic description of the information encoded in the presentation". And given our WCAG discussions, I'm not sure this is always possible, at least for web-based authoring tools.
3. #47: LGR: It also seems as if A.1.5 SC 3 and SC 4 should be combined; color is just authoring tool-controlled presentation. Is SC 4 additional requirements on the use of color? Is color the only form of presentation that can be satisfied by an alternate version (per (b))?
4. #48: UAWG informal: A.1.5 SC3, 4: Confusing examples
5. #158: EOWG: For success criteria 2 and 3 under A.1.5, the phrase "the semantic description of the presentation must be available programmatically" was not understandable to EOWG readers despite considerable discussion. One interpretation included that this should be referring to the "semantic function" not "semantic description" but this was not clear; and in addition, the relationship to the authoring tool interface was not clear

1. #45: New text is "functional purpose" in A.2.3.3
2. #46: New text is "functional purpose" in A.2.3.3
3. #47: We just picked a bad example that involved colour. This has been fixed.
4. #48: Agreed and fixed.
5. #45: New text is "functional purpose" in A.2.3.3

1. #49: BG: A.2.1 - should there be something about supporting platform accessibility options for keyboard access (sticky keys and such?).
2. #50: BG: SC 4 is setting a very high bar for web-based authoring tools. For example, I'm not sure how I would implement going to the beginning / end of content within a rich text editor component on the web Undo/redo is also particularly difficult on the Web. I'm not disagreeing that this should be a requirement but it does make it highly unlikely that a web based authoring tool would ever achieve compliance with ATAG (at least in the near future on more than one user agent).
3. #51: BG: SC 5 (undo/redo) may be particularly difficult for Web based authoring tools. I guess if they don't provide any additional, selectable keyboard functionality then there is no need to save the preferences.
4. #53: AL: A.2.1 Success Criteria 5 is a convenient feature, but should not be priority 1. As long as user/author can use keyboard to activate the settings, it is accessible.
5. #54: LGR: A.2.1 SC 1 is task based! I'm not sure I see a definition of task or authoring task.
6. #55: MC: 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.
7. #112: SR: Keyboard access.  I do not agree with the success criteria that requires single key or key + modifier access to the listed functions.  This is not P1.  Access to the function with the keyboard is P1.  Specifying single key or key+ modifier is at most P2 since this is usable access and not accessibility.
8. #124: RS: A.2.1 Requiring single-key modifiers should be a P2. Also, drag and drop and in-context menus should fall under this section.
9. #125: RS: A.2.1 Should be synched with UAAG.

1. #49: Agreed - this has been added as A.1.3.1.
2. #50: SC4 did say "(if present)" but anyhow this has been reworded and broken up (A.3.1.4 and A.3.15 are "A" and A.1.3.6 is "AA")
3. #51: Undo/redo keyboard shortcuts are only required if undo/redo is present. "A.3.1.8 If the author has the option to modify the keyboard settings, any modifications must be saved between authoring sessions."
4. #53: It has been moved to Priority AA.
5. #54: "Task" wording has been removed.
6. #55: This has been addressed in the rewording.
7. #112: This has changed in the rewording, with most of the functions moved to Level AA.
8. #124: Most of the key requirements have been moved to Level AA, although the ability to TAB through the "chrome" remains Level A.
9. #125: Agreed. We will be in contact with them.

1. #56: LGR: A.2.2 - (a) do any applications let authors control the order of menu items in menus?
2. #57: LGR: (b) what does "available" mean in this context? Would keyboard shortcuts stop working if items weren't available? Does disabling an item count? Or removing it from the visible UI?

1. #56: Yes - MS Word etc. Anyhow this requiremnt has been removed.
2. #57: this requiremnt has been removed.

1. #58: AL: A.2.3 Success Criteria 1.  The SC statement draw out a condition of what is needed when time limit is not controlled by time-sensitive external constraints.  But it says nothing about conditions where the time limit is controlled by external constraints.  How are the authoring tools, or more appropriately the authoring environments, where time constraints are controlled by external constraints to fulfill this priority 1 requirement?  You need to make an explicit exception statement here or have instruction of what needs to be done.  As you should know, almost all commercial products are made in collaborative environments where such external time constraints are essential.
2. #59: MC: 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.
3. #52: AL: A.2.1 Should add an exception for analog, time-dependent input as in WCAG 2.0 2.1.1

1. #58: External constraints and collaborative constraints have now been made more explicit.
2. #59: This has been reworded but there are reasons (e.g. collaborative authoring scenario) why ATAG should differ from WCAG on this.
3. #52: New wording should not preclude this.

1. #60: BG: A.2.4 SC 1a - the author must be able to disable the flashing before it occurs. This technique does not seem sufficient: Technique A.2.4-1.1 [Sufficient for (a)]: If flashing begins, providing a single input action that stops the flashing immediately and for at least the rest of the session.
2. #61: BG: What if the flashing generates a seizure before the user can perform the single input action? How would the user know what the single input action is? I think a more appropriate technique would to warn the user of flashing content and provide a mechanism to disable it before it begins.

1. #60: This has been reworded in a way that adds more protection. It is difficult to prevent all flashing in rendered content since there are so many different ways this might occur.
2. #61: This is a difficult area because flashing can be caused in many different ways and once the flashing occurs it might be unlikely that the user could make use of an escape function.

1. #62: BG: I don't understand this technique: Technique A.2.5-1.3 [Advisory]: If loops are possible within the structured element set, providing a mechanism for alerting the author when they have completed a loop. An example would be helpful.
2. #63: AL: A.2.5 That is a usability feature.  It impacts people without disabilities just as much.  It should be removed.

1. #62: This refers to the (rare) case in which information structures may have loops (e.g. a node is both parent and child to another node. We will try to clarify with an example.
2. #63: So is a search feature but it is in ATAG because it is additionally important to users with certain disabilities. If we take it out, and a tool doesn't do it, we have no way of saying there is an accessibility problem.

1. #64: AL: A.2.6 search functionality is too specific. There may be other mode to locate things.
2. #65: UAWG informal: A.2.6 SC1: Clarify that it is ok to change editing views

1. #64: There may be others and we don't preclude them, but we have decided to require this basic set.
2. #65: This change has been made.

1. #66: AL: A.2.7 Not all functions can be "undoed", especially operations such as file save, delete, and most collaborative functionalities. Explicit exception is needed.
2. #67: MC: 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.

1. #66: We now define "reversible actions". Note this is now A.4.3.
2. #67: We have made this change.

1. #113: SR: A.2.8.  Having multiple sets of preferences and settings should be P3 and not P2.
2. #126: RS: A.2.8 Should be P3

1. #113: This has been done.
2. #126: This has been done.

1. #68: MC: A.2.9: Success Criterion 1 (get out of preview) also needs to be Priority 1. Tool breaks if you can't.
2. #69: UAWG informal: A.2.9 SC2: Add meeting UAAG as another item in the OR list

1. #68: This has been added.
2. #69: This has been added as an OR item.

1. #70: AL: A.3.1 where the term "observe" is not specific enough.
2. #71: MC: 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.
3. #72: UAWG informal: A.3.1 should be P1

1. #70: Reworded as "Follow"
2. #71: This has been done.
3. #72: This has been moved to P1. BTW: this is a P2 in UAAG 1.0 (7.3 Respect operating environment conventions (P2))

1. #73: AL: A.3.2 does not appear testable.

1. #73: We have harmonized with WCAG 2.0 on this..

1. #74: BG: A.3.3 SC1 - Why must a non-web based authoring tool provide web based documentation? Just because the tool creates Web content, I don't see why it must provide documentation in a Web based form. The SC does say that it doesn't have to be located on-line but if it must conform to WCAG then it would have to be Web content. This seems too restrictive. A non-web based authoring tool should be able to provide accessible non-web based documentation. I am guessing that this is mandated in order to have a guideline to judge the accessibility of the documentation against but I think conforming to Part A of ATAG would be sufficient.
2. #75: LGR: A.3.3 SC 1: while I can see why it is stated this way, it feels like the appeal to WCAG might disqualify something like the use of a Word document or OS-specific documentation format that is accessible on that platform, but not on the web.

1. #74: Agreed - other options have been added.
2. #75: Agreed this option has been added.

1. #76: BG: A.4.1 SC 2 is very confusing. Even after looking at the techniques I have no idea what I am supposed to "publish"? It sounds like, as an authoring tool author, I am supposed to document how I implemented the accessibility API. Part A seems to require that I document what level of accessibility api I have implemented. Part B seems to just be asking me to implement the accessibility API for each element which can receive focus. And Part C is again asking the author to document the level of support for the accessibility API. The techniques for this didn't help clarify as it is just, " Implementing the relevant accessibility platform architecture(s), such as:", and is incomplete. A.4.1 SC2 really seems to fall under A.4.2 ?
2. #77: AL: A.4.1 There are more way to make applications accessible to AT than the like of MSAA. MSAA and UIA are not capable of meeting all needs from author tool makers. Implementing only MSAA almost guarantees some functionalities will fail in some cases. If the rest of the requirements are met and it works with AT, why do you care how we do it from an architecture standpoint? This is far too prescriptive to be priority 1. Also, this requirement manipulates market dynamics between platform providers, ISPs, AT vendors. That is a bad idea.
3. #78: LGR: A.4.1 SC 2 seems confusing to me. Is it just requiring that the accessibility API support be documented for AT developers? Actually, I don't understand the distinction between A.4.1 and A.4.2.
4. #79: MC: 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.
5. #80: KHS: In areas in the document where 'Assistive technologies' is used, other AT should be included with e.g., such as voice recognition. The current examples appear too vision-disability centric.
6. #81: UAWG informal: A.4.1 Put some more AT examples in Rationale.
7. #82: UAWG informal: A.4.1 SC1: replace "the accessibility platform architecture" with "AN accessibility platform architecture".
8. #83: UAWG informal: A.4.1 SC2: Confusing wording.
9. #84: UAWG informal: A.4.1 SC3b: Need to clarifying that published means public
10. 127: SR: A.4.1 Has the group thought about keyboard conflicts with assistive technologies? ATs can change their UI regularly so conflicts can arise and it would be difficult to mandate that no kbd. conflicts should occur. However, they are source of contention.

1. #76: This was unclear. The whole section has been reworked as A.1.2.
2. #77: The requirement is flexible enough to meet this concern.
3. #78: This was unclear. The whole section has been reworked as A.1.2.
4. #79: This was unclear. The whole section has been reworked as A.1.2.
5. #80: This has been done.
6. #81: This has been done.
7. #82: This has been done
8. #83: This was unclear. The whole section has been reworked as A.1.2.
9. #84: This has been done.
10. #127: As the commenter says, this is something that is hard to mandate.

1. #85: AL: Part B in general--Due to potential legal risk associated with WCAG conformance, I don't think you will find too many commercial authoring tool makers who would that say within the tool itself that doing XYZ with a particular authoring tool would guarantee WCAG compliance content. This may be the case, even if the tool technically meets part B requirements. There is too much legal risk to make claims of fulfillment for part B.

1. #85: Well, technically, they aren't guaranteeing they always produce something that meets WCAG 2.0 for example. Instead they are saying they guide the author towards meeting a Benchmark document (that they can write) that is based on WCAG techniques. Of course, since the ATAG approach allows author freedom, the result may still not conform with WCAG.

1. #128: RS: B.1.1 Back to benchmarks and baselines. The baseline should be explicit stated.

1. #128: The benchmark requirement now includes user agent assumptions.

1. #129: RS: B.1.2 the accessibility information is available to end users in the result of the transformation or conversion , or   ... I would use the words "preserved for" vs. "available to"  and I would add that this should only be done if the target content-type supports the accessibility information. For example, ODF supports headers in rich text editor tables whereas MS Office does not. Also long description and short text alternatives are provided in ODF whereas MS Office only provides one text alternative.

1. #129: This has been done.

1. 130# RS: B.1 3 Will the techniques show how this is done through the accessibility api?

1. #130: We could include a technique for this.

1. #86: BG: Checkpoints B.1.4 and B.1.5 seem almost impossible to achieve. The note / exception about requiring accessibility information from the author helps. I can live with these but they will be very difficult to meet in non-web based tools and virtually impossible in web-based tools (although Web based tools will meet this by not implementing automatic generation).
2. #87: MC: 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.
3. #88: CS: B.1.4. The antecedent of "it" is ambiguous (the authoring tool or the content). Fortunately, the rationale and the success criterion clarify that "it" refers to the content.

1. #86: It certainly won't be easy, but the alternative is to auto-generate accessibility problems that it is then the author's responsibility to fix.
2. #87: This has been reworded for clarity.
3. #88: Reworded.

1. #89: BG: Example B.1.5.1.4 doesn't seem realistic. There may be cases where the alt text can not be determined until the image is used.
2. #90: BG: Not exactly sure what this is trying to say - there are extra words or tense issues: Technique B.1.5-1.4 [Advisory]: Ensuring that equivalent alternatives provided for pre-authored content are usable compatible with features to manage, editing, and reusing equivalent alternatives.
3. #91: MC: 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.

1. #89: Although context is very important, generic labels are possible. In the context of use, if they don't make sense the user can change them. If the author fails to change them it will impact accessibility, but perhaps not quite as much as no label at all.
2. #90: Techniques document is not the focus of this call for comments, although it will be updated.
3. #91: That might be hard to do. For example, Flash content might be read as being intended primarily for the Flash authoring tool - so would we want to ban Flash from providing links to third party repositories of Flash source?

1. #92: BG: B.2.1 SC 2 item B - I think you mean, "inform the author that NOT following the instructions would lead to Web content accessibility problems." I added the word "NOT" in front of the word "following".
2. #131: RS: B.2.1 I am a bit confused about relative priority. While I understand that this is relative to WCAG priority levels, ... Is the ATAG priority for a P1 to prompt for accessibility information defined in a P1 check point in WCAG? When there is dynamic content and states and properties are changed in ARIA, you should define techniques that show how the browser will display accessibility api state or property change event notifications

1. #92: It's actually worded correctly - but since it's confusing it has been reworded as: "Each instruction for creating content must meet the Web content accessibility benchmarks or include a warning that Web content accessibility problems will result from following the instructions."
2. #131: We have removed the "Relative Priority" concept. Agreed re: the ARIA techniques.

B.2.2 Check for and inform the author of accessibility problems. [Relative Priority]

1. #93: BG: Regarding: B.2.2 SC 1: An individual check must be associated with each requirement in the content type-specific WCAG benchmark document (i.e., not blanket statements such as "does the content meet all the requirements"). The content type specific WCAG benchmark has been defined as a WCAG techniques document - the techniques documents are not requirements so this SC doesn't make sense. I think this revolves around my confusion of what exactly is a content-type-specific WCAG benchmark document?
2. #94: BG: Must an authoring tool provide its own accessibility checking? I think it should be allowed to work with a separate tool. Also, when content is auto-generated from server side languages, it is often very difficult for the tool to test for accessibility problems. If I can create a page using JSP, is the tool that allows me to enter the JSP tag required to interpret the tag code and know that it will be inserting an image and that there is no alt text? This entire checkpoint seems overly restrictive as currently worded. This is fine for simple HTML generation tools but becomes much more complicated for more advanced tools that use JSP, JSF, PHP, etc.
3. #95: BG: This example of automated checking doesn't appear to meet the ATAG guidelines since information is conveyed using color. You may want to include a statement that the accessibility problems can also be determined in some other manner in addition to just the blue font. Example of Automated Checking (3): This illustration shows an authoring interface of an automated check in a code-level authoring view. The text is: "<body><p>Image:</p><img href="pic123.gif"/><hr/><blink>Blinking text</blink></body></html>".In this view, the text of elements with accessibility problems (img and blink) is shown in a blue font, instead of the default black font. (Source: mockup by AUWG)
4. #96: AL: B.2.2 So, everytime we have non-text-content, the author tool as to explain to the user/author how to meet 1.1.1 in WCAG 2.0? That seems like a lot to ask for an authoring tool to handle something objective like this.
5. #132: RS: B.2.2  Success Criteria 2 should not be limited to the element type. The author may place an ARIA role on the element which redefines what states and properties it should support. ATAG should allow for a comparison of the states/properties set with the states and properties allowed for that role type. For example, IBM has a tool called RAVEn which will compare this information against the states and properties defined for a role in the Role taxonomy.
6. #136: ERTWG: There was no clear consensus or a specific suggestion from ERT WG but in general a clearer definition of the interaction between authoring and evaluation tools may be helpful. For example mentioning the possibility of providing APIs for plugin evaluation tools where appropriate (such as B.2.2 & B2.3) may be helpful.

1. #93: The Web Content Accessibility Benchmark document is not a WCAG techniques document and it IS made normative by the act of including a reference to it in the ATAG conformance profile. (see above for more discussion of the benchmark documents)
2. #94: ATAG 2.0 does allow the authoring tool to rely on a third-party tool to do the checking and repair and simply include it in a conformance claim. Also the bar is set quite low - allowing manual checking
3. #95: This is a technique and will be examined.
4. #96: It depends on how smart the tool wants to be about it. The tool can handle purely decorative non-text content without asking the user at all, some alternatives can be pulled from other sources, and special-purpose UI's can be built to make adding ALT easier.
5. #132: Agreed that we should make this checkpoint more technology independent.
6. #136: Maybe we should refer more formally to Evaluation and Repair Tools as a defined term. RE: APIs: Maybe we can include the provision of such APIs as a technique.

1. #97: AL: B.2.4 Why do we need this if we already have B.2.2 (both seem overly demanding)?
2. #98: MC: 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.
3. #114: SR: B.2.4.  I am concerned about the testability of this checkpoint.  I think providing text equivalents for non-text content is Priority 1, but assisting the authors to ensure the alternative is "accurate and fits the content" is Priority 2 at best.  It is not a Priority 1 requirement.

1. #97: This Guideline has been reworked as Guideline B.2.4 Assist authors to manage, edit, and reuse equivalent alternatives for non-text objects.
2. #98: This Guideline has been reworked as Guideline B.2.4 Assist authors to manage, edit, and reuse equivalent alternatives for non-text objects.
3. #114: This Guideline has been reworked as Guideline B.2.4 Assist authors to manage, edit, and reuse equivalent alternatives for non-text objects.

B.2.5 Provide functionality for managing, editing, and reusing equivalent alternatives. [Priority 3]

1. #115: SR: B.2.6.  Is there a reason why the group made providing a summary of accessibility status a P3?  I would view this as P2 given the other requirements.
2. #133: RS: B.2.6 I agree this should be a P3. It will be difficult to do this for dynamic content unless it were a snapshot in time.
3. #138: ERTWG: Despite EARL 1.0 being in draft stage, it may be useful to provide an optional provision for exporting and importing reports in a structured format. This may further improve the interaction between authoring and evaluation tools by promoting the integration and exchange of data.
4. #156: EOWG: Checkpoint and success criterion B.2.6 seem to be saying that an authoring tool must have evaluation functionality on board. If this is what is meant, then it should be stated more clearly, even if you also include the precise statement here of the evaluation tool functions that are expected. (There was some but not conclusive EOWG discussion as to whether plug-in capability of evaluation functions should be a sufficient success criteria, instead of requiring authoring tools to have evaluation functionality on board, but in our discussions we focused primarily on the understandability of the document.)

1. #115: It is now a Level AA item B.2.2.6
2. #133: If there are cases this success criteria would be inapplicable we may need to call them out.
3. #138: This is definitely a good technique. I've wondered for a while if we want to say anything about saving user decisions to avoid asking the same questions over and over...maybe a P3 thing.
4. #156: This status report can be displayed with a third party checker if that's the case.

1. #116: SR: B.2.7.  There should be a definition of "tutorial" for "Provide a tutorial on the process of accessible authoring."  The success criteria is clear that the tutorial is specific to the tool, but the language of the checkpoint leaves it open to interpretation.  Also, how is B.2.7 different than B.3.5. to document accessibility features of the tool?  What specifically is different about a "tutorial"?  

1. #116: A definition has been added - the tutorial requirement is now B.3.4.2.

1. #99: BG: B.3.1 SC 1 is confusing: "When the author has more than one authoring option for a given task (e.g., emphasizing text using semantic markup rather than inappropriately using header markup), then any options that conform to WCAG must have equal or higher prominence than any options that do not. " Header markup is semantic markup so I think this needs clarification.
2. #100: MC: 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…”.
3. #101: CS: B.3.1 - success criterion 2. "that does not conforms" should be "that does not conform".
4. #117: SR: B.3.1 and B.3.3.  I am concerned about the testability of "prominence" to meet these checkpoints.  I suppose it is vague enough that we could justify meeting the criteria in our tools.
5. #134: RS: B.3 This section should provide information to the author in the case of a model-based authoring tool about whether reusable objects have previously been tested for accessibility with assistive technologies. This would help promote accessibility solution construction and perhaps reduce the load on the developer.

1. #99: Agreed, reworded.
2. #100: Reworded.
3. #101: Editorial: This will be fixed.
4. #117: Reworded
5. #134: Good idea - but maybe this fits best under B.1.5 (pre-authored content)?

1. #102: MC: 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.

1. #102: Addressed with multi-priority level structure.

1. #103: LGR: Glossary: "accessibility problem, Web content A Web content accessibility problem is an aspect of Web content that fails to meet some requirement of WCAG. The severity of a given problem is relative and is determined by reference to WCAG"
   This reflects the misunderstanding of WCAG 2 conformance levels as correlated to levels of accessibility. It may be appropriate for WCAG 1 conformance levels.
   
2. #104: LGR: "content type A content type is a data format, programming or markup language that is intended to be retrieved and rendered by a user agent (e.g., HTML, CSS, SVG, PNG, PDF, Flash, JavaScript or combinations). The usage of the term is a subset of WCAG 2.0's [WCAG20] current usage of the term "Technology"."
   How is it only a subset? What is excluded?
   
3. #105: BC: While some terms common to ATAG 2.0 and WCAG 2.0 are defined the same way, it seems that others are not. (ex ATAG "equivalent alternative" seems to be the same as WCAG "alternative version") It would be a good idea for the documents to agree on definitions where possible. Note that some WCAG definitions have changed since our last TR draft based on public comments and ATAG definitions may need to be updated accordingly. Also, some definitions (ex. red and general flash threshold may still change based on WCAG 2.0 comments.)
4. #106: BC: definition of "available programmatically" - This seems only to say that it's possible for the information to be communicated, not that it has been. Is there something in ATAG that requires that information that "should" be available to AT actually is available? The concern here is that these SC would be met if the info is available regardless of whether AT actually make use of it.
5. #107: GV: 7.) definition of "available programmatically" - This seems only to say that it's possible for the information to be communicated, not that it has been. Is there something in ATAG that requires that information that "should" be available to AT actually is available? The concern here is that these SC would be met if the info is available regardless of whether AT actually make use of it.
   One example of this is: If a company creates a new technology (and an author tool for it), should the technology be considered accessible if the author tool exposes information in a way that is not compatible with any existing AT? What is the good? It is not directly accessible and it is not compatible with any AT. It could SOMEDAY be accessible – but not today. And it may never be. Should we say that that is better than closed with no possibility of access? Probably. But shouldn't it be different than technologies that can actually be used by people with disabilities? Current draft does not seem to do this.
   In WCAG ‘programmatically determined' relies on ‘accessibility-supported' technologies.
6. #137: ERTWG: Defn of Semi-Automated checking: In ERT WG we have been discussing the definition of semi-automated checking. In the latest EARL 1.0 Last Call Working Draft [5], we took an approach based on the *primary responsibility* for determining the outcome of a check to differentiate between the different types of testing. For example, consider the following tow scenarios:
   • A person uses a tool to evaluate a site. The tool asks the user if the color-contrast is sufficient, and uses this input directly as an outcome of a test (such as WCAG 1.0 CP 2.2).
   • A tool uses a person to evaluate a site. The tool asks the user if a table is used for layout or data purposes, and uses this input for carrying out other tests (such as WCAG 1.0 CP 5.1).
   • (We have received some review comments on this topic and will be processing them in the coming weeks. ERT WG would like to coordinate with AUWG on a common definition for manual, semi-automatic, and automatic testing of Web content.)
7. #157: EOWG: Consider whether these terms (perceivable, understandable, operable, etc.) ought to be in your glossary.

1. #103: Fixed.
2. #104: Fixed by new joint defn.
3. #105: A renewed effort was made to harmonize terms.
4. #106: Guideline A.1.2 has been reworded to take care of this.
5. #107: Guideline A.1.2 has been reworded to take care of this.
6. #137: We coordinated with ERTWG on a solution to this.

1. #108: CS: Editorial comments:
   * Colons are not necessary to introduce a list that is just the next phrase in the syntactic structure, so the colons can be removed from the following locations: "including, but not limited to:" (Introduction); "This document consists of:" (Introduction); "ATAG 2.0 defines an 'authoring tool' as:" (Definition of authoring tool); "authors and end users may:" (Role of authoring tools...); "indicate whether it is either:" (Components of ... Conformance Claim).
2. #109: CS: Conformance claim § 3.b.ii: full stop at the end is missing.
3. #110: Suggest use other AT's in examples: voice rec, etc.

1. #108: Editorial: This will be fixed.
2. #109: Editorial: This will be fixed.
3. #110: Added