FINAL Comment Responses for ATAG 2.0 Last Call WD (8 July 2010)

Applicability Notes: For PART A: Make the authoring tool user interface accessible:	Comments	AUWG Responses
Scope of authoring tool user interface: The Part A success criteria apply to all aspects of the authoring tool user interface that are under the control of the authoring tool developer. This includes views of the web content being edited, and features that are independent of the content being edited, such as menus, button bars, status bars, user preferences, documentation, etc.	UAWG1: What about authoring systems that offer end-to-end publishing and web server publication/configuration. It should be clear where any line for AU responsibility ends. If you do expand this, you might want to give examples to more clearly define what you mean by "authoring systems that offer end-to-end publishing and web server publication/configuration". Would that include Web-based authoring tools such as when Drupal provides forms where the user can author or edit content that it hosts, using either text markup or WYSIWIG mode, and their choice of Web browsers?	AUWG: ATAG 2.0 certainly applies to Drupal and other CMS systems. This is clear from the following in the definition of authoring tools: " software for generating/managing entire web sites (e.g., content management systems, courseware tools, content aggregators)"[APPROVED http://www.w3.org/2011/03/28-au-minutes.html#item01]
GL34. MINOR: UI is not always under the control of the tool. In "PART A: Make the authoring tool user interface accessible", "Applicability Notes", "1. Scope of authoring tool user interface: The Part A success criteria apply to all aspects of the authoring tool user interface that are under the control of the authoring tool developer. This includes views of the web content being edited and features that are independent of the content being edited, such as menus, button bars, status bars, user preferences, documentation, etc." it is worth noting that things like menus can be completely under the control of the authoring tool (as in its own menus), or completely under the control of the author (as in "fake" menus created by scripts in the Web content), or a hybrid of the two (as in menus created specified by the authored content but implemented by the authoring tool (such as XUL menus).	AUWG: We have added a new Part A Conformance Applicability Note as follows: "Developer control: The Part A success criteria only apply to the authoring tool user interface as it is provided by the developer. It does not apply to any subsequent modifications by parties other than the authoring tool developer (e.g. by plug-ins, user modifications, etc.)."[APPROVED http://www.w3.org/2011/03/28-au-minutes.html#item01]
IBM12: Applicability Notes: Scope: appears that this applies to all views of the content being edited. But authoring tools support multiple content formats, some of which might not support accessibility. Is this a problem?	AUWG: We have clarified this by saying: "Part A success criteria apply to all aspects of the authoring tool user interface that are concerned with producing the "included" web content technologies...."[APPROVED http://www.w3.org/2011/03/28-au-minutes.html#item01]
Reflected web content accessibility problems: The authoring tool is responsible for ensuring that editing views display the web content being edited in a way that is accessible to authors with disabilities (e.g., ensuring that a text alternative in the content can be programmatically determined). 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.	GG1: "(e.g. if an image in the content lacks a label)" may be confused since labels in HTML, refer to a component of a form. Perhaps use "e.g. image in the content lacks a text alternative".	AUWG: The suggestion ("e.g. image in the content lacks a text alternative". ) is accepted.[APPROVED http://www.w3.org/2011/03/28-au-minutes.html#item01]
AC1: I found this phrase "Reflected web content accessibility problems" difficult to understand even after reading the following paragraph. The explanation seems very verbose, perhaps because it contains complete text from the glossary entries ("an authoring tool user interface accessibility problem is caused directly by a web content accessibility problem in the content being edited"). It could be written more concisely, like this: "However, where an accessibility problem is caused directly by 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 user interface."	AUWG: We have clarified the wording as follows: "The authoring tool is responsible for ensuring that editing-views display the web content being edited in a way that is accessible to authors with disabilities (e.g., ensuring that text alternatives in the content can be programmatically determined). However, where an accessibility problem is caused directly by the content being edited (e.g., if an image in the content lacks a text alternative), then this would not be considered a deficiency in the accessibility of the authoring tool user interface." [APPROVED http://www.w3.org/2011/03/28-au-minutes.html#item01]
User agent features: Web-based authoring tools may rely on user agent features (e.g., keyboard navigation, find functions, display preferences, undo features, etc.) to satisfy success criteria. If a conformance claim is made, the claim cites the user agent.
Features for meeting Part A must be accessible: The Part A success criteria apply to the entire authoring tool user interface, including any features added to meet the success criteria in Part A (e.g., documentation, search functions, etc.). The only exemption is for preview features, as long as they meet Guideline A.3.7. Previews are treated differently than editing views because all authors, including those with disabilities, benefit when preview features accurately reflect the actual functionality of user agents.

Applicability Notes: For PART B: Support the production of accessible content:	Comments	AUWG Responses
Author availability: Any Part B success criteria that refer to authors only apply during authoring sessions.
Applicability after the end of an authoring session: For author-generated content, the requirements of Part B only apply during authoring sessions. For example, if the author includes a third-party feed in their web content, the authoring tool is not required to provide checking for web content accessibility problems in that feed after the end of the authoring session. In contrast, for automatically-generated content, Part B continues to apply after the end of the authoring session. For example, if the site-wide templates of a content management system are updated, these would be required to meet the accessibility requirements for automatically-generated content.	MS1: Part B Application Notes #2 The examples seem contradictory because both examples pertains to automated content, yet they are treated differently. Please revise the example to reconcile the contradiction.	AUWG: We have clarified the wording as follows: "Applicability after the end of an authoring session: Authoring tools are responsible for the accessibility of web content that they automatically generate after the end of an author's authoring session (see Success Criterion B.1.1.1). For example, if the developer changes the site-wide templates of a content management system, these would be required to meet the accessibility requirements for automatically-generated content. Authoring tools are not responsible for changes to the accessibility of content that the author has specified, whether it is author-generated or automatically-generated by another system that the author has specified (e.g. a third-party feed)." [APPROVED http://www.w3.org/2011/03/28-au-minutes.html#item01]
IBM38: Part B: Support the production of accessible content-Applicability Notes, bullet 2: I don't understand this example: "In contrast, for automatically-generated content, Part B continues to apply after the end of the authoring session. For example, if the site-wide templates of a content management system are updated, these would be required to meet the accessibility requirements for automatically-generated content."	AUWG: Please see response to MS1[APPROVED http://www.w3.org/2011/03/28-au-minutes.html#item01]
Authoring systems: As per the ATAG 2.0 definition of authoring tool, several software tools (identified in any conformance claim) can be used in conjunction to meet the requirements of Part B. (e.g., an authoring tool could make use of a third-party software accessibility checking and repair tool).	GG2: "...and repair tools" repair tools are in most cases only relevant to static Web sites. These days the vast majority of sites are dynamically generated. Perhaps drop the words "and repair." A "repair tool" generally infers some form of automated fixing of HTML. Do such tools exist in todays world of dynamically generated Web site? APrompt was one, but it is no longer usable in the "repair tool" sense.	AUWG: We have removed "repair tools" from this example for clarity.[APPROVED http://www.w3.org/2011/03/28-au-minutes.html#item01]
Features for meeting Part B must be accessible: The Part A success criteria apply to the entire authoring tool user interface, including any features added to meet the success criteria in Part B (e.g., checking tools, repair tools, tutorials, documentation, etc.).
Multiple author roles: Some authoring tools include multiple author roles, each with different views and content editing permissions (e.g., a content management system may separate the roles of designers, content authors, and quality assurers). In these cases, the Part B success criteria apply to the authoring tool as a whole, not to the view provided to any particular author role.	GL15. MEDIUM: Features should be available to all applicable roles. In "Implementing PART B: Support the production of accessible content", "Applicability Notes" it says "5. Multiple author roles: Some authoring tools include multiple author roles, each with different views and content editing permissions (e.g., a content management system may separate the roles of designers, content authors, and quality assurers). In these cases, the Part B success criteria apply to the authoring tool as a whole, not to the view provided to any particular author role." This seems a bit overly broad, as individual features required by ATAG part B should be visible in any mode where they would be useful. As an extreme example, syntax checking should be visible and available to authors and QA, so it should be insufficient to have them available only to system administrators.	AUWG: We are trying to be sensitive to the workflows of enterprise systems. We have added this final sentence for clarity: "Accessible content support features should be made available to any author role where it would be useful."[APPROVED http://www.w3.org/2011/03/28-au-minutes.html#item01]

Guideline	Success Criteria	Comments	AUWG Responses
General		WCAGWG1: Consolidate WCAG 2.0 related SC: A number of the guidelines include SC that reference conformance to WCAG 2.0 at various conformance levels. Consider combining these to reduce the overall number of success criteria and to minimize repetition and cross-references in the implementation guide. For example, combining the three SC listed in A.1.1 might look like: A.1.1.1 Web-Based Accessible (WCAG Conformance): Web-based authoring tool user interfaces conform to WCAG 2.0 at one of the following conformance levels. * Level A: For Level A conformance, web-based authoring tool user interfaces conform to WCAG 2.0 Level A. (Level A) * Level AA: For Level A conformance, web-based authoring tool user interfaces conform to WCAG 2.0 Level AA. (Level AA) * Level AAA: For Level A conformance, web-based authoring tool user interfaces conform to WCAG 2.0 Level AAA. (Level AAA) A similar approach should be considered for the B.1.1.x, B.1.3.x, B.2.2.x, B.2.3.x, B.2.5.x, etc.	AUWG: We agree to make this change throughout the document. [APPROVED http://www.w3.org/2011/04/04-au-minutes.html#item07]
		JM1: I do suggest that it make clear that an authoring tool should produce accessible content with its default settings. Currently, I interpret the guidelines as recommending that such settings be as prominent as other configuration choices. I think it is important, however, that an author has to make a conscious decision to depart from a mode in which accessible content is the result. In this way, accessible content is the norm for developers who do not think about accessibility and use the authoring tool as is, without customizing its settings. I also suggest that the guidelines incorporate more explicit references to web 2.0-type web pages that create value from user-generated content. On such a page, the reader is often an author as well. The user agent, e.g., web browser, is an authoring tool, too. The user may enter text, upload audiovisual media, or simply express preferences -- e.g., rating an article. This combining of reading and writing capabilities blurs distinctions between audiences of the Authoring Tool Accessibility Guidelines and the User Agent Accessibility Guidelines. Spontaneous, user-generated content makes it more important than ever that accessible content is produced via default settings of both live user agents and offline authoring tools.	AUWG: We believe that the "accessible by default" issue is covered by B.1.1.1 (Content Auto-Generation After Authoring Sessions (WCAG)), B.1.1.2 (Content Auto-Generation During Authoring Sessions (WCAG)), and B.4.1.1 (Features Active by Default). We have attempted to take into account "Web 2.0" use cases, for example with language such as this in the introduction: "It is important to note that, while the requirements for meeting these two sets of user needs are separated for clarity within the guidelines, the accelerating trend toward user-produced content means that, in reality, they are deeply inter-connected. For example, when a user participates in an online forum, they frequently author content that is then incorporated with other content authored by other users. Accessibility problems in either the authoring user interface or the content produced by the other forum users would reduce the overall accessibility of the forum." [APPROVED http://www.w3.org/2011/04/04-au-minutes.html#item07]
		AC2: I think it is relevant to explain to readers why the two seemingly independent requirements, of (1) access to authoring tools and (2) production of accessible content, are covered in the same document. I remember once someone from WAI (Judy or Shawn?) explain something along the line that only when people with disabilities can create Web content in equal conditions will web accessibility become a reality. ATAG 1.0 contains a partial explanation, "Since the Web is both a means of receiving information and communicating information, it is important that both the Web content produced and the authoring tool itself be accessible." With the current trend toward user-produced content this is now even more true than when ATAG 1.0 was published (see Jamal's comment [1] about Web 2.0 content). This idea of a two-way process is the clearly (to me) the reasoning for including both requirements in the same recommendation, but an explanation seems to be needed.	AUWG: We have modified the Introduction as follows: "Accessibility, from an authoring tool perspective, includes addressing the needs of two overlapping user groups with disabilities: * authors of web content, whose needs are met by ensuring that the authoring tool user interface itself is accessible (addressed by Part A of the guidelines), and * end users of web content, whose needs are met by ensuring that all authors are enabled, supported, and guided towards producing accessible web content (addressed by Part B of the guidelines). It is important to note that, while the requirements for meeting these two sets of user needs are separated for clarity within the guidelines, the accelerating trend toward user-produced content means that in reality they are deeply inter-connected. For example, when a user participates in an online forum they frequently author web content that is then incorporated with other content authored by other users. Accessibility problems in either the authoring user interface or the web content produced by the other forum users would reduce the overall accessibility of the forum".[APPROVED http://www.w3.org/2011/04/04-au-minutes.html#item07]
		GL9. MEDIUM: Broaden definition of essential. The section "Understanding Levels of Conformance" says "factors evaluated when setting the level in Part A included: ...whether the success criterion is essential (in other words, if the success criterion is not met, then even assistive technology cannot make the authoring tool user interface accessible)" While probably unintentional, this sounds as if success criteria are only included if there is no workaround using assistive technology. As you know, most users with disabilities do not use assistive technology, nor should they need to as long as mainstream software is designed to meet basic accessibility guidelines. For example, software should not be considered accessible if it fails to provide built-in keyboard UI, even if AT such as MouseKeys can retrofit keyboard access onto such software.	AUWG: The "Essential" wording is in an informative part of the document and is adapted from the "Understanding Conformance" text from Understanding WCAG 2.0, so we prefer not to change it too much.[APPROVED http://www.w3.org/2011/04/04-au-minutes.html#item07]
		GL10. MEDIUM: Criteria need not apply to all types of authoring tools. The section "Understanding Levels of Conformance" says "factors evaluated when setting the level in Part A included:...whether it is possible to satisfy the success criterion for all types of authoring tools that the success criteria would apply to (e.g., text editors, WYSIWYG editors, content management systems, etc.)" I don't believe a potential success criterion should be excluded just because it does not apply to all authoring tools; rather:	AUWG: We agree and believe that we have addressed the issue using conditional phrasing on many of the success criteria. In addition we have added this section explaining applicability: "Applicability of Success Criteria: The ATAG 2.0 definition of authoring tool is inclusive and, as such, it covers software with a wide range of capabilities and contexts of operation. In order to take into account authoring tools with limited feature sets (e.g., a photo editor, a CSS editor, a status update field in a social networking application, etc.), many of the ATAG 2.0 success criteria are conditional, applying only to authoring tools with the given features(s) (e.g., Success Criterion B.1.1.1 applies only to authoring tools that automatically generate web content after the end of authoring sessions)." [APPROVED http://www.w3.org/2011/04/04-au-minutes.html#item07]
		OC1: Oracle Corporation thanks you for the opportunity to respond to the Authoring Tools Accessibility Guidelines working draft dated 08 July 2010. We appreciate that a lot of effort has gone into this draft, but feel that in some areas additional changes are needed. > We appreciate the distinction being made in Part A – making the authoring tool itself accessible, versus Part B – making the output of the tool accessible; however, we feel that the Part A information needs finishing. The information in Part A is very good for when the tool is a web-based tool, since that is the expertise of the group. Our area of concern with this is in the situation where the tool is not web-based. An effort was made to address this, but it has been done in a way that has many potential problems. For example, when compared to current and proposed U.S. Section 508 standards for ‘software', what is currently presented ranges from being a subset of those standards, to possibly presenting standards that might be in conflict. Our recommendation is for Part A to address only web-based authoring tools (and perhaps just refer to Section 508 for non-web based if you speak to that at all). Failing that, make all of the non-web-based provisions aspirational or advisory.	AUWG: Section 508 is U.S. legislation/regulations, so W3C cannot simply refer to it normatively. Instead, include a link to Section 508 §1194.21 Software applications and operating systems in the Related Resources. [APPROVED http://www.w3.org/2011/04/04-au-minutes.html#item07]
		OC15: Often part B has an all-or-nothing approach to producing accessible web content where level A is the only level where something can be met. We would suggest that many of these could benefit from an approach where the level A or AA guideline allows a timely, accurate, complete and efficient mechanism to complete a task. A corresponding level AAA guideline could then be introduced where ALL of the methods to produce content provide the same benefits.	AUWG: The WG requires specific comments on levels per success criteria, not in general, which fortunately are also provided in later comments.[APPROVED http://www.w3.org/2011/04/04-au-minutes.html#item07]
Conformance		WCAGWG2: Required Components of an ATAG 2.0 Conformance Claim #5 (Authoring tool information): Consider adding information about the role and requirements for information about extensions, plugins or modules that may have modified or extended the authoring tool to meet a requirement.	AUWG: We believe that the existing note covers this concern about full identification of the authoring tool "Authoring tool information: The name of the authoring tool and sufficient additional information to specify the version (e.g. vendor name, version number (or version range), required patches or updates, human language of the user interface or documentation). Note: If the authoring tool is a collection of software components (e.g. a markup editor, an image editor, and a validation tool), then information must be provided separately for each component, although the conformance claim will treat them as a whole. As stated above, the Claimant has sole responsibility for the conformance claim, not the developer of any of the software components. ".[APPROVED http://www.w3.org/2011/04/04-au-minutes.html#item07]
		WCAGWG3: Required Components of an ATAG 2.0 Conformance Claim #6 (Web content technologies produced): Consider dropping the requirement for a list of technologies not included as this can be derived from the list of technologies that the tool is capable of producing when compared to the list of technologies included in the claim.	AUWG: The developer knows what they are producing (e.g., via "Save As", "Export"). It would be easier for them to include this information than to expect readers of a conformance claim to determine this.[APPROVED http://www.w3.org/2011/04/04-au-minutes.html#item07]
		WCAGWG4: Required Components of an ATAG 2.0 Conformance Claim #7 (Declarations) and Checklist: This requirement implies that each claim would have to list each SC that is met. It should be possible to declare a range of SC that have been met. (ex. All Level A). Additionally, inviting claimants to declare success criteria that are not applicable may be a slippery slope and often leads to inaccurate claims. Instead, suggest including a statement that says that where an authoring tool does not include a feature that is relevant to a given SC, then that SC is automatically satisfied.	AUWG: We believe that it is more clear to have to address each success criteria individually. It is problematic to categorize not applicable SCs as "automatically satisfied" because it provides less information as to the thinking of the Claimant. A new section "Applicability of Success Criteria" provides more clarity.[APPROVED http://www.w3.org/2011/04/04-au-minutes.html#item07]
		WCAGWG5: Waiving of WCAG 2.0's conformance requirement #4: Only Accessibility-Supported Ways of Using Technologies. Many of ATAG's success criteria rely on conformance with WCAG 2.0 but allow for information or functionality provided in a way that is not accessibility supported. This is potentially quite a loophole and can easily mislead (intentional or not) the intended audience regarding the production of content that conforms to WCAG 2.0.	AUWG: In order not to unintentionally mislead readers about WCAG 2.0's conformance requirements, we have switched our wording from "conforms to WCAG 2.0" to "meets the WCAG 2.0 success criteria"[APPROVED http://www.w3.org/2011/04/04-au-minutes.html#item07]
		GG3: Conformance claims: Is there going to be a Conformance Claim program to validate claims made by developers, and by others representing authoring tools? ATAG differs from WCAG in claims made in that WCAG is easily checked with a variety of tools to confirm conformance claims. Such a tool does not exist to confirm ATAG conformance claims. Experience with the claims process for another standards organization I'm involved with, raises questions about the "honesty" of claimants, or perhaps the "scope" of a particular claim that omits points of failure. Self-claims are easy to make, but they don't hold much clout, and they can easily deceive or mislead potential users. As a purchaser of an ATAG conformant authoring tool, I'd want something more than a self-claim. A dishonest developer could potentially have a competitive advantage over an honest one. Perhaps there should be a distinction between self-reported compliance, and W3C (or another granting body) endorsed compliance. Or, perhaps setup something that legally binds a claimant, such as submitting a claim through a central, perhaps W3C, claims site, where they must agree to a legal statement before making a claim. This would discourage invalid claims, and potentially provide recourse in the event that a fraudulent (or less than complete) claim is made to the detriment of other developers or users of an authoring tool.	AUWG: We agree that this is an issue, but it is out of scope. Claim validation needs to be considered at the level of WAI or W3C. [APPROVED http://www.w3.org/2011/04/04-au-minutes.html#item07]
		MS2: The biggest concern for ATAG 2.0 is that it is never clear if ATAG is for a single tool or a collection of tools. It is trying to be both. This leads to a great deal of structural problems. If it is for a single tool, then the SCs are too far reaching and the conformance requirement does not make room for a simple specialized tool to conform. How does ATAG 2.0 conformance work for something like a web accessibility toolbar, photo editor, FTP client, or a social networking site? You need to allow tool makers to say their tool does not provide certain function and it is not intended to do so, but the tool conforms where it is applicable. On the other hand, how would conformance work for a collection of tools where some criteria are met via a portion of the tools? Would one have to specify which tool(s) is used to conform to any given criterion? If the collection of tools include tool(s) in which the conformance claimer has no Intellectual property ownership, would the claimer then be held responsible for the accuracy of the claim of such tool? What if is there is discrepancy between the tool manufacturer and claimers? What if the collection is still not applicable to ATAG in full—for example, only relevant to part A? Is the collection deemed incomplete? Additionally, where does the value chain of the authoring process end? Without knowing the scope, then ATAG 2.0 may require consideration of software such as scanner application, a database, a web service, or enterprise backend systems. Does a mail client become a “web authoring tool” only when it sends a message to somebody who access their email via the web? How is one supposed to know if the mail recipient uses a web client? These are extremely difficult questions. But if left unanswered, ATAG 2.0 will not be viable in practice. The conformance section requires fundamental revision to be viable. Please revise accordingly.	AUWG: We believe that we have addressed the issue in the following ways: (a) using conditional phrasing on many of the success criteria. (b) In addition we have added this wording in the conformance section: "Applicability of Success Criteria: The ATAG 2.0 definition of authoring tool is inclusive and, as such, it covers software with a wide range of capabilities and contexts of operation. In order to take into account authoring tools with limited feature sets (e.g., a photo editor, a CSS editor, a status update field in a social networking application, etc.), many of the ATAG 2.0 success criteria are conditional, applying only to authoring tools with the given features(s) (e.g., Success Criterion B.1.1.1 applies only to authoring tools that automatically generate web content after the end of authoring sessions). "[APPROVED http://www.w3.org/2011/04/04-au-minutes.html#item07]
		MS3: Conformance Condition 1 WCAG 2.0 does not require conformance claim be made in the web or not. This condition is unnecessary. Please remove condition.	AUWG: ATAG2.0 conformance claims are optional. Being public about the conformance details is consistent with W3C principles.[APPROVED http://www.w3.org/2011/04/04-au-minutes.html#item07]
		MS4: Conformance Condition 6 This is an “encouragement”. Thus, it does not belong to the normative part of the ATAG 2.0. Please move condition 6 to non-normative part of ATAG 2.0	AUWG: This text has been moved to an informative note.[APPROVED http://www.w3.org/2011/04/04-au-minutes.html#item07]
		IBM10: Understanding Levels of Conformance- Note 4 in the definition of authoring tool indicates ATAG 2.0 is not intended to be applicable to simple text editors. Therefore, "text editors" should be removed from the following bullet: "whether it is possible to satisfy the success criterion for all types of authoring tools that the success criteria would apply to (e.g., text editors, WYSIWYG editors, content management systems, etc.)"	AUWG: For clarity, "text editors" has been dropped from the list of examples.[APPROVED http://www.w3.org/2011/04/04-au-minutes.html#item07]
		IBM11: In this sentence defined "proportionally greater" as this is vague: In other words, the user interface issue must cause a proportionately greater problem for authors with disabilities than it causes authors without disabilities and must be specific to authoring tool software, as opposed to software in general.	AUWG: The text has been moved to the informative Implementing ATAG 2.0 document. The text is harmonized with text in WCAG 2.0's Understanding Document (http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html).[APPROVED http://www.w3.org/2011/04/04-au-minutes.html#item07]
		IBM58: Conditions on Conformance Claims- bullet 4: BLOCKING ISSUE: we raised an issue last time about anybody being able to make a claim even for stuff they don't own. What if a government enacts procurement regulations requiring ATAG compliance, we provide a compliance statement on one of our products that differs from what a journalist somewhere publishes about our product? The journalist might falsely claim that our product is compliant. Would the customer then hold us liable? Or conversely, we may be claiming compliance due to some particular situation about how the product is going to be used by this customer but the journalist claims it is not compliant. We might lose the sale.	AUWG: We have dropped the language referring to who can make a claim that explicitly mentionned "anyone".[APPROVED http://www.w3.org/2011/04/04-au-minutes.html#item07]
		IBM59: Comment "It seems weird to me that anyone can make a claim. Of course you can't prevent it but odd that the W3C would endorse it. If it stays in there, then we need to insist that the claim has to include information about who is making the claim. We don't want to be held liable for a claim that someone else might make about our products." The claimant's name has now been added but I still don't like it.	AUWG: Please see response to IBM58[APPROVED http://www.w3.org/2011/04/04-au-minutes.html#item07]
		IBM60: bullet 5 seems especially problematic for us where we have bundled third party components that are not licensed to the customer by IBM: "Claimants are solely responsible for the accuracy of their claims (including claims that include products for which they are not responsible) and keeping claims up to date."	AUWG: This wording was actually put in to protect developers from the claims of others. But since it has only caused more confusion, it will be removed.[APPROVED http://www.w3.org/2011/04/04-au-minutes.html#item07]
Glossary		WCAGWG6: Many of the defined terms in ATAG 2.0 differ from those in WCAG 2.0 and/or make notes and examples from the WCAG 2.0 definitions a part of the definition itself in ATAG 2.0 . We found the resulting definitions confusing. We suggest synchronizing and formatting these definitions so that they are consistent across the WAI guidelines. Examples include "keyboard interface," "label," "non-text content" etc. There were only three terms that were different enough to warrant a review. We are concerned that it may not be clear to readers that these definitions are intended to be the same. We would encourage you to use the WCAG definitions as closely as possible, augmented by additional information needed to address ATAG-specific considerations:	AUWG: We have taken a second look at the terms shared with WCAG 2.0 and made updates where necessary. However, we felt that changing the phrase+notes structure of WCAG's definitions to sentences was more clear for our purposes. [APPROVED http://www.w3.org/2011/04/04-au-minutes.html#item07]
		WCAGWG7: assistive technology: We suggest that you use the WCAG definition with an additional note about authoring tools providing direct accessibility features.	AUWG: The WCAG definition has too many Web and browser specific references to use it directly. ATAG 2.0 applies to both web-based and non-web-based tools. [APPROVED http://www.w3.org/2011/04/04-au-minutes.html#item07]
		WCAGWG8: programmatically determined: We suggest that you use the WCAG definition and include your second sentence as a Note.	AUWG: The WCAG definition has too many Web and browser specific references to use it directly. See also the response to GL1.[APPROVED http://www.w3.org/2011/04/04-au-minutes.html#item07]
		WCAGWG9: non-text content: We believe that it is critical that your definition include the phrase "can be programmatically determined".	AUWG: Agreed. We have changed the wording to: Non-text content: "Any content that is not a sequence of characters that can be programmatically determined or where the sequence is not expressing something in human language. This includes ASCII Art (which is a pattern of characters), emoticons, and images representing text." [APPROVED http://www.w3.org/2011/04/04-au-minutes.html#item07]
		GL1: Programmatically Determinable is not limited to Platform API. The glossary entry for "programmatically determined (programmatically determinable)" says "For non-web-based user interfaces, this means making use of a platform accessibility architecture." In the UAAG 2.0 draft we stress the importance of not only supporting the platform accessibility architecture, but also other programmatic interfaces. For example: "Intent of Success Criterion 2.1.4: Assistive technologies often use a combination of methods to get information about and manipulate an application and its content. These methods include platform accessibility APIs (such as MSAA or JAA), general-purpose platform APIs (such as those used to determine a window's title), application-specific APIs (typically a last resort when an application does not make all information available through the former means), DOMs, and hard-coded heuristics. It is the user agent's responsibility to make the necessary information and facilities available through the appropriate corresponding means. Because DOMs typically provide capabilities that are fine-tuned to a specific content type, and therefore far richer than the other methods, exposing DOMs to assistive technology is an extremely important part of AT compatibility. This complements, but does not replace, the need to support other methods, such as platform accessibility API, because although they are less powerful, they allow assistive technology to work with a wider range of applications."	AUWG: We agree that DOMs should be mentioned as a possible implementation in the definition and Implementing guide. Here is the reworded text: "programmatically determined (programmatically determinable): Information that is encoded in a way that allows different software, including assistive technologies, to extract and present the information in different modalities. ATAG 2.0 uses this term in two contexts: - Processing content: Whether the authoring tool is able to extract information from the web content (e.g., to extract the language of content from the markup). - Communication between the authoring tool and assistive technology: For non-web-based user interfaces, this means making use of platform accessibility services, APIs, and in some cases document object models. For web-based user interfaces, this means ensuring that the user agent can pass on the information (e.g., through the use of ARIA). " [APPROVED http://www.w3.org/2011/04/04-au-minutes.html#item07]
		GL8. MEDIUM: Broaden definition of authoring tool. Re the definition of "authoring tool", I wonder whether you also want to explicitly cover tools that cannot directly output Web formats, but can output rich content that can then be converted into Web formats. For examples, imagine a word processor that cannot save documents as HTML but can copy rich text and graphics to the clipboard, from which they can be pasted into a tool that can save them as HTML. The source editor could take steps, such as prompting the user for Alt text for an image, so that the rich content it creates can be converted to Web formats that conform to WCAG. The only nod to this in the definition is the one example that is not explicitly Web-related, "multimedia authoring tools", and that is ambiguous.	AUWG: As a W3C recommendation, we need to stick to Web content. It would be fairly easy to apply ATAG 2.0 to Word processor applications creating only word processor documents if one wished too.[APPROVED http://www.w3.org/2011/04/04-au-minutes.html#item07]
		IBM1: Authoring tool- the numbered items look like "notes" which further explain the definition. They should be labeled Note 1, Note 2, etc.	AUWG: This change has been made.[APPROVED http://www.w3.org/2011/04/04-au-minutes.html#item07]
		IBM2: Authoring tool- The examples include debugging tools for web content". I don't understand how debugging tools can be considered an authoring tool.	AUWG: This has been removed.[APPROVED http://www.w3.org/2011/04/04-au-minutes.html#item07]
		IBM3: Authoring tool- authoring tools it includes email clients. If an email client supports accessible web content authoring do we know that the mail format preserves the accessibility information that would be prompted for in an email authoring tool? Such as:alt text, ARIA semantics, table structure, keyboard navigation.This applies to other document formats.	AUWG: Plain email is an unstructured format, which is not considered Web content. But HTML email is structured and would be covered. Note in the authoring tool definition that tools are allowed to produce other formats (e.g. edit content that isn't Web content e.g. plain text files, plain text emails, etc.)[APPROVED http://www.w3.org/2011/04/04-au-minutes.html#item07]
		IBM4: Authoring tool- Reference to blogs, Wikis, and content management systems. Most blogs, wikis do not currently support ATAG 2.0 . It is important to state how they can comply with ATAG checkpoints, and this may require s browser plug-in. Therefore, a browser plug-in must be an acceptable authoring tool component.	AUWG: Right. A browser plug-in is an acceptable authoring tool component.[APPROVED http://www.w3.org/2011/04/04-au-minutes.html#item07]
		IBM5: Authoring tool- Web content management systems use Java-based content editors to test content for WCAG compliance. Standard Java HTML editors only support HTML 3.2. So, somewhere there needs to be a statement to ensure that authoring tools accessibility analysis can fully support the host language.	AUWG: It is acceptable to conform with respect to the production of any web content technology, including an older one.[APPROVED http://www.w3.org/2011/04/04-au-minutes.html#item07]
		IBM6: view - The numbered items in this definition look like additional terms. In fact, there are links from the document to the terms in the numbered list yet they don't make sense unless you read the parent definition. For example, Guideline A.2.2 rationale links to the term "editing view" but the bullet "editing views are editable" is not a sufficient definition to understand what the term means in the context in which it is used. Creating separate terms in the glossary with definitions that stand alone and also reference the more general term would be a better approach.	AUWG: We tested breaking up the definitions into single terms, but the result was a longer glossary in which relationships between terms was not as clear. Therefore, we have instead used bullets under the main definition for closely related definitions.[APPROVED http://www.w3.org/2011/04/04-au-minutes.html#item07]
		IBM7: programmatically determined (programmatically determinable) - (Blocking issue) do not agree with the definition of programmatically determined. It is inadequate and should not be limited to "platform accessibility architecture." Platform accessibility architecture is also inconsistent with the U.S. 508 refresh. Do not want to mislead people to thing that only what is available in the platform accessibility architecture can be used. Definition must refer to platform accessibility services and platform accessibility services to be any recognized accessibility services layer supported by assistive technologies that support full interoperability with web content technology capable of supporting WCAG 2.	AUWG: Please see response to GL1.[APPROVED http://www.w3.org/2011/04/04-au-minutes.html#item07]
		IBM8: programmatically determined - 508 refresh refers to platform accessibility services. Platform accessibility services should include MSAA and IAccessible2 together. Both are referred to in the ARIA and HTML 5 API mapping documents. There is no issue exposing access to a DOM as part of being programmatically determined. The DOM does not have to be a W3C DOM. However, the definition of platform accessibility architecture refers to a single document object and not a document object model. In IE ATs access information from a W3C DOM API and another DOM API that provides things like gaining access to the computed style of a document object within that model. So, these definitions do not adequately address what ATs need or are using to gain access to information.	AUWG: Please see response to GL1.[APPROVED http://www.w3.org/2011/04/04-au-minutes.html#item07]
		IBM9: programmatically determined- CSS styling for final format is accessed through non W3C DOMs. IE actually has two DOMs (one w3c and another of their own design). The one of their own design has a getComputedStyle method on DOM elements. When solutions use none standard (publicly recognized accessibility services) that are needed to meet this requirement they should be documented. Reason: an authoring tool needs to be able to prove that they can actually meet ATAG. I don't see that here.	AUWG: Please see response to GL1.[APPROVED http://www.w3.org/2011/04/04-au-minutes.html#item07]
A.1.1 [For the authoring tool user interface] Ensure that web-based functionality is accessible.	A.1.1.1 Web-Based Accessible (WCAG Level A): Web-based authoring tool user interfaces conform to WCAG 2.0 Level A.	GG4: Guideline A.1.1 et al "[For authoring tool user interface]" the square brackets could potentially create confusion, given ATAG is aimed primarily at a developer audience. For developers the square brackets [] generally represent optional values. Parentheses would be less likely to be confused.	AUWG: We have changed from square brackets to standard brackets. [APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		OC2: -A.1.1 – We recommend renaming this to “Ensure web-based functionality supports use by assistive technologies” since the information in the line “Implementing A.1.1” is about accessibility APIs.. Additionally, if one meets a broad guideline requiring that ‘functionality is accessible' then one can reasonably infer that all subsequent guidelines would also be met. As such, it creates a tension similar to the Functional Performance Criteria and Technical Standards present in U.S. Section 508, which should be avoided.	AUWG: There may be some confusion here. The only SC under A.1.1 refers to WCAG 2.0, which covers much more than support for assistive technology. A.1.2.1 includes links to information on accessibility APIs, but also covers accessibility issues such as keyboard navigation, colors, etc. that are included in the standards or platform conventions. [APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		IBM13: A.1.1 and A.1.2 refers to Web-based and non web-based authoring tools. Web-based is not clearly defined. When stating web-based do you mean W3C document standards or do you mean that to include any web delivered standard such as Flash, Flex, Silverlight, etc.?	AUWG: We have added Flex, and Silverlight as example web-based technologies. Flash already was an example. [APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		IBM14: A.1.1 Web-based functionality: For web-based UIs, some of the subsequent requirements modify WCAG 2.0 requirements. Has the work been done to determine if it is even possible to comply with A.1.1 (comply with WCAG) AND comply with all of the subsequent requirements that are tweaks on WCAG 2.0 requirements? If the rationale is that these things are needed for non-web-based functionality, then the provision should be scoped to non-web-based functionality. For example, why is A.3.2.2 needed for web-based content when it also has to comply with WCAG 2.0 via A.1.1?	AUWG: The reason for the duplication is that ATAG2 applies to both web-based and non-web-based authoring tools. As long as we have kept the requirements the same (which is our intention), there won't be any problem for Web-based tools. In the Implementing ATAG 2.0 document, the "Related Resources..." sections reference the relevant WCAG 2.0 success criteria.[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		IBM15: A.1.1 and A.1.2 refer to web content but they don't state that the web content be supported by at least one user agent to be consistent with UAAG 2. If you don't have this stipulation then the user will be unable to use the web content. Somewhere in ATAG this does need to be stipulated.	AUWG: If this refers to WCAG 2.0's "Accessibility Support" concept, we explain in the conformance section, see WCAGWG5.[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
A.1.2 [For the authoring tool user interface] Ensure that non-web-based functionality is accessible.	A.1.2.1 Non-Web-Based Accessible: Non-web-based authoring tool user interfaces follow accessibility standards and/or platform conventions that support accessibility. Note: If a conformance claim is made, the claim cites the accessibility standards and/or platform conventions that were followed.	WCAGWG10: A.1.2.1 While we agree with the approach and the rationale cited in the implementation guide, this SC, specifically "...and/or platform conventions..." may not be testable. How does an authoring tool developer determine whether they have followed enough platform conventions to pass? Suggest revising this SC to make it more testable and adding additional detail to the implementation guide to clarify what would be required.	AUWG: It's not a matter of how many. This note in the success criteria might help clarify: "Note: Developers should see the documents listed in the "Related Resources for Success Criterion A.1.2.1" section, below. Unless extenuating circumstances exist (e.g. a document has been superseded, the platform has undergone major architectural changes), the listed resources should be assumed to be relevant to the platforms listed. " [APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
A.2.1 [For the authoring tool user interface] Make alternative content available to the author.	A.2.1.1 Recognized Alternative Content: If recognized alternative content is available for editing view content renderings, then the alternative content is provided to authors.	UAWG2: (and other SC) this and other success criteria were at time very hard to understand (for us it depended on the line breaks). suggest changing 'editing view' to 'editing-view'. it may help the reader understand the content rendering and alternative content are in the editing-view. We believe the clearest wording for the SC would be "is available when rendering content in editing views", if you can adopt the phrase "rendering content" as equivalent to "content rendering".	AUWG: We have made the suggested change to "editing-view" and reworded the SC as "A.2.1.1 Text Alternatives for Rendered Non-Text Content: If an editing-view renders non-text content with programmatically associated text alternatives, then the text alternatives can be programmatically determined." [APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		MS5: A.2.1.1 The success criterion needs to have simplified languages. We cannot determine its meaning without reading through the implementation guide. Rewrite the success criterion to make it more comprehensible.	AUWG: Please see response to UAWG2[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		OC3: -A.2.1.1 – We find the guideline to be generally confusing. The word ‘provided' in the guideline also complicates it, since it may be interpreted to mean that the tool must supply the text, perhaps as a default value. Was the intent that the tool ‘expose' current content? We recommend this item should be removed or made non-normative.	AUWG: Please see response to UAWG2[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
A.2.2 [For the authoring tool user interface] Editing view presentation can be programmatically determined.	A.2.2.1 Purpose of Added Presentation: If an editing view modifies the presentation of web content to provide additional information to authors, then that additional information can be programmatically determined. A.2.2.2 Access to Text Presentation (Minimum): If an editing view (e.g., WYSIWYG view) renders any of the following presentation properties for text, then those properties can be programmatically determined: (a) Text Font; and (b) Text Style (e.g., italic, bold); and (c) Text Color; and (d) Text Size.	WCAGWG11: A.2.2.2: Consider adding background color to the list of minimum presentation properties for text.	AUWG: We have reworded this requirement to be more general: "A.2.2.2 Access to Rendered Text Properties: If a text property is both rendered and editable and the property can be communicated by the supported platform accessibility service, then the property is programmatically determinable." [APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		MS6: A.2.2.1: “Additional information” is undefined. In order to determine what is considered additional information, one must know what is considered baseline information. We realize that AUWG considers underlining of misspelled words to be a piece of “additional information”, but there is no way to tell what is it that makes such information qualified as being “additional”. This will make it impossible to determine if the criterion is met.. We can at best project the concept into the similar scenarios for grammatical errors and coding errors—purely because it is an educated guess. Define “additional information” to make it objectively testable or revise the success criterion.	AUWG: We have reworded this requirement as follows: " A.2.2.1 Editing-View Status Information: If an editing-view modifies the presentation to convey status information, then that status information can be programmatically determined. Status information conveyed by modifying the presentation of editing-views may include, but is not limited to, spelling, grammar and syntax errors."[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		GL11. MEDIUM: UAAG has more Level A text properties. ATAG's A.2.2.2 and A.2.2.3 correspond to UAAG20's 2.1.6, but the latter includes a wider range of text properties at Level A. ATAG A.2.2.2 says "Access to Text Presentation (Minimum): If an editing view (e.g., WYSIWYG view) renders any of the following presentation properties for text, then those properties can be programmatically determined: (Level A) [Implementing A.2.2.2] (a) Text Font; and (b) Text Style (e.g., italic, bold); and (c) Text Color; and (d) Text Size." UAAG20's 2.1.6 covers "(a) the bounding dimensions and coordinates of rendered graphical objects (b) font family of text (c) font size of text (d) foreground color of text (e) background color of text. (f) change state/value notifications (g) selection (h) highlighting (i) input device focus".	AUWG: Please see response to WCAGWG11[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		OC4: - A.2.2.1 - As currently worded, it is not clear whether it is the visual (or otherwise) representation of the additional information, or the semantic meaning of the additional content, that must be programmatically determinable.	AUWG: Please see response to MS6[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		OC5: -A.2.2.2 – The minimum list is incomplete; for example, it should also include text-background color or text highlighting color. Also, the Implementing information refers to non-web based information and should be removed.	AUWG: Please see response to WCAGWG11[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		IBM16: A.2.2 Rationale: an example of "information about the end user experience of the web content being edited" would be helpful	AUWG: Please see response to MS6[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		IBM17: A.2.2.1. doesn't appear the vehicle for doing this is fully addressed. For example, when authoring a mashup what vehicles are stipulated to determine when alternative content is available to meet a specific user's needs and how are users needs conveyed through the authoring tool. Example: a google map has a linear text-based driving direction alternative. Today, web content mashups do not do this. A standard meant to address this is the IMS Access For All Specifications. Concerned with the definition of Programmatically Determined.	AUWG: We have clarified that we are referring to status information added by the authoring tool: "A.2.2.1 Editing-View Status Information: If an editing-view modifies the presentation to convey status information, then that status information can be programmatically determined. Status information conveyed by modifying the presentation of editing-views may include, but is not limited to, spelling, grammar and syntax errors." [APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		IBM18: A.2.2.2 Access to text presentation: The use of the word "and" in the sub-bullets is unnecessary as the provision wording is clear that if any of these presentation characteristics are supported, they must be programmatically exposed.	AUWG: We have followed the WCAG 2.0 style.[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		IBM19: A.2.2.2 We are concerned about the definition of Programmatically Determined. Programmatically Determined Definition - a blocking issue The document must support platform accessibility services and that needs to be re-defined. This problem is pervasive throughout the spec and implementation guidance.	AUWG: Please see response to GL1[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
A.2.3: Ensure the independence of the authors' display preferences.	A.2.3.1 Independence of Display: Authors can set their own display settings for editing views (including WYSIWYG views) without affecting the web content to be published.	JC1: This statement seems contradictory. A personalized view for the authoring tool that displays content differently from the the view to be published, by definition, CANNOT be considered WYSIWYG. I also believe this requirement puts undue burden on the user interface design of the authoring tool, because it's difficult for a simple, usable UI to accurately convey that this-is-your-own-view-of-the-content-but-its-not-the-same-as-what-will-be-published… WYSINRWYG: What you see is not really what you get. I don't agree that this is necessary, and I'd recommend downgrading this from a Level A requirement to a Level AAA suggestion. Perhaps this could be changed to remove the confusing reference to WYSIWYG: "Authors can set their own display settings for alternate editing views without affecting the web content to be published." If that change were made, I could accept this as a Level A requirement.	AUWG: "(including WYSIWYG views)" might be confusing and has been removed. The term WYSIWYG is not exactly clear because the end-user can quite often modify what they get. We just want to say that the author should be able to modify what they (the author - not the end-user) gets as they edit the content.[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		MS7: A.2.3.1 This criterion should be consolidated to A.3.6. Move A.2.3.1 to A.3.6	AUWG: Agreed, we have consolidated these requirements as suggested into "A.3.6.1 Independence of Display: If the authoring tool includes display settings, then authors can adjust these settings for editing-views without affecting the web content to be published." .[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		IBM20: A.2.3.1: Since A.3.6.2 requires respecting the platform display settings, it seems to override any other way of allowing authors to set their display settings. So A.2.3.1 seems to be reduced to a requirement that the tool respect the platform display settings without affecting the Web content to be published. Seems like this could be simplified by just rolling the "independence" requirement in A.2.3.1 into the "platform settings" requirement in A.3.6.2. At a minimum, A.2.3.1 should reference A.3.6.2 as A.3.6.2 currently references A.2.3.1.	AUWG: The two requirements are now together in the same Guideline, but they have different levels and address different issues.[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
A.3.1 [For the authoring tool user interface] Provide keyboard access to authoring features.	A.3.1.1 Keyboard Access (Minimum): All functionality of the authoring tool is operable through a keyboard interface, except where editing web content properties that encode continuous input. Note 1: This exception relates to the nature of web content, not the usual input technique. For example, setting the path of a freehand curve is exempt, while setting the endpoints of a straight line is not. Note 2: This should not be interpreted as discouraging mouse input or other input methods in addition to the keyboard interface. A.3.1.2 No Content Keyboard Traps: Keyboard traps are prevented as follows: (a) In the Authoring Tool User Interface: If keyboard focus can be moved to a component using the keyboard, then focus can be moved away from that component using standard keyboard navigation commands (e.g., TAB key); and (b) In Editing Views that Render Web Content: If an editing view renders web content (e.g., WYSIWYG view), then a documented keyboard command is provided that will always restore keyboard focus to a known location (e.g., the menus).	JC2: re: A.3.1.1 Please change "Keyboard Access" to "Keyboard Equivalent Access" and change "keyboard interface" to "keyboard equivalent interface."For example, all functionality of iOS and accessible iOS applications is available through a keyboard equivalent and is accessible through multi-sensory output (sight and sound, and touch if using a external braille display), and does not require a standard keyboard interface to be accessible. Example: See Victor Tsaran's demo of iPhone4/iOS4 with an external braille display. http://www.youtube.com/watch? v=6_TFHqIHBqM	AUWG: This is addressed in the definition of "Keyboard Interface" (which is intentionally different than keyboard), which comes from WCAG 2.0. [APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		MS8: A.3.1 There should be exception and consideration for authoring environment/OS where there is no keyboard. Either add a condition for environment/OS with keyboard or add an exception.	AUWG: Please see response to JC2[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		MS9: A.3.1.1 Why does the language differ from WCAG “except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints” Either reconcile the difference or provide rationale for the difference.	AUWG: We have re-harmonized with WCAG 2.0, but have added this line to the first note: "The path exception encompasses other input variables that are continuously sampled from pointing devices, including pressure, speed, and angle."[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		MS10: A.3.1.2 Why does the language differ from WCAG “...if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away." Either reconcile the difference or provide rationale for the difference.	AUWG: We have re-harmonized with WCAG 2.0 for (a), which is under the control of the developer. The rationale for (b) is that the content (created by previous authors) being rendered might include keyboard traps.[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		GL3. HIGH: Keyboard trapping too narrowly defined. Re "A.3.1.2 No Content Keyboard Traps:...(b) In Editing Views that Render Web Content: If an editing view renders web content (e.g., WYSIWYG view), then a documented keyboard command is provided that will always restore keyboard focus to a known location (e.g., the menus)." The problem with this wording is that being able to move the focus from an object to the authoring tool's menu is not sufficient if, when they return to editing mode, the keyboard focus returns to a trapped state. For example, imagine that you are authoring content and use a command insert a Flash object, leaving the focus on that object and no keyboard command such as Tab to move it off; the only thing you can do is press a key combination to move the active keyboard focus to a menu, but upon dismissing the menu the focus is back on the Flash object, and you still cannot get to the rest of the document, and you presumably have to close the document and reopen it again to get back into a usable editing mode. The true intent should be to allow the author to move the keyboard focus to other elements inside the content--specifically, being able to move the focus elsewhere within its current viewport and to any other viewports that can take keyboard focus.	AUWG: Agreed. Here is the new wording: "(b) In Editing-Views that Render Content: If an editing-view renders content (e.g. WYSIWYG view), then a documented keyboard command is provided that moves the editing-view keyboard focus to a known location (e.g. the start of the editing-view)."[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		IBM21: A.3.1.2 No keyboard traps a) requires a keyboard way to exit all content that can be entered using the keyboard. Is this always possible for authoring tools? For example, say you have an authoring tool that allows the addition of third party UI widgets. If you drag insert one of those widgets into the content you are editing and move keyboard focus to it, who now owns the keyboard focus? The widget or the authoring tool? If it's the widget, then how does the authoring tool guarantee that you can exit the widget with the keyboard?	AUWG: The third-party UI widget issue has been addressed by the rewording of Part A Applicability note 1 Please see response to GL34[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		IBM22: A.3.1.2 No keyboard traps b) requires a documented keyboard command that will always restore keyboard focus to a known location which seems like a good requirement, however, the example of "menus" doesn't seem to accomplish the goal. If your keyboard focus is trapped and you move it to the menus then back to the document, it should go back to where it was before you put it on the menus. So it would still be trapped. Suggest that the requirement be to have a keyboard command that moves focus to a known location within the content being edited.	AUWG: Please see response to GL3[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
A.3.2 [For the authoring tool user interface] Provide authors with enough time.	A.3.2.1 Data Saved (Minimum): If the authoring tool includes authoring session time limits, then the authoring tool saves all submitted content edits made by authors. A.3.2.2 Timing Adjustable: If a time limit is set by the authoring tool, then at least one of the following is true: (a) Turn Off: Authors are allowed to turn off the time limit before encountering it; or (b) Adjust: Authors are allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or (c) Extend: Authors are warned before time expires and given at least 20 seconds to extend the time limit with a simple action (e.g., "press the space bar"), and authors are allowed to extend the time limit at least ten times; or (d) Real-time Exception: The time limit is a required part of a real-time event (e.g., a collaborative authoring system), and no alternative to the time limit is possible; or (e) Essential Exception: The time limit is essential and extending it would invalidate the activity; or (f) 20 Hour Exception: The time limit is longer than 20 hours. A.3.2.3 Static Pointer Targets: User interface components that accept pointer input are either stationary or authors can pause the movement.	JC3: re: A.3.2.2(F): Minor: I'm pretty sure the 508 refresh requires 8 hours for the exception, not 20. If you have a good reason to refute 508, please file a comment on that requirement. Otherwise, I'd suggest remaining consistent and using the 8 hour exception.	AUWG: This text is harmonized with WCAG 2.0. The number is fairly arbitrary either way.[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		WCAGWG12: A.3.2.2 Timing Adjustable: What would be an example of an authoring tool time limit where extending the time limit would invalidate the activity (e)?	AUWG: An example might be authoring something as part of a exam.[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		IBM25: A.3.2.1 Data saved: What does "submitted content edits" mean in a non-web-based authoring tool?	AUWG: That wording has been clarified and moved to the informative intent: "For web-based authoring tools, this applies to any web content that has already been submitted to the server by the user agent." [APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		IBM26: A.3.2 What happens if the authoring tool give the author the ability for the author to set the refresh rate of the page? This is something the author has set. Does this require warnings to the author when during a test run the time is about to expire?	AUWG: The issue of author control has been addressed by the rewording of Part A Applicability note #1. Please see response to GL34[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
A.3.3 [For the authoring tool user interface] Help authors avoid flashing that could cause seizures.	A.3.3.1 Static View Option: Rendering of time-based content (e.g., animations) in editing views can be turned off.	MS11: A.3.3.1 It should be recognized that there is a fundamental conflict between the necessity to view the animation during animation editing process and the need to disable animation to prevent seizure. This cannot be at level A in its current form. Is this applicable to non-visual time based content too? If so, what is the rationale? Move the SC to AA or AAA, explain that there is a potential for fundamental alteration, and to exclude all non-visual time-based content.	AUWG: Agreed. Reworded as: "A.3.3.1 Static View Option: Editing-views that render visual time-based content can be paused and can be set to not play automatically. " [APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
A.3.4 [For the authoring tool user interface] Enhance navigation and editing via content structure.	A.3.4.1 Edit by Structure: Editing views for structured web content include editing mechanism(s) that can make use of the structure. A.3.4.2 Navigate By Structure: Editing views for structured web content include navigation mechanism(s) that can make use of the structure.	MS12: A.3.4 Given that the purpose of these success criteria is to “…simplify the task…”, they should not be level A. These are AA or AAA criteria. Move all A.3.4 SCs to AA or AAA.	AUWG: The group has decided to reword "A.3.4.1 Navigate By Structure:" and set it to AA. A new requirement ("A.3.4.2 Navigate by Programmatic Relationships") has been added at AAA. [APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		MS13: A.3.4.1 Most web-based authoring tools (think of social networking sites and blog sites) do not allow users to create or control structures. There should be exemptions for authoring tools that do not allow structural edits. Add exemption for tools that does not allow control of structure or condition for tools that allow so.	AUWG: Please see response to MS12 [APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		MS14: A.3.4 Does this apply to all structures or some structures? There is no indication one way or the other. All structure does not make sense. Clarify that this is not required for all structure.	AUWG: Please see response to MS12 [APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		MS15: A.3.4.1 & A.3.4.2 What does “make use of” means? Please provide definition.	AUWG: Please see response to MS12 [APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		GL22. MEDIUM: Low bar for A.3.4.1 Edit By Structure. "A.3.4.1 Edit By Structure: Editing views for structured web content include editing mechanism(s) that can make use of the structure. (Level A)" and "A.3.4.2 Navigate By Structure: Editing views for structured web content include navigation mechanism(s) that can make use of the structure. (Level A)" both seem particularly broad, as having any a single feature that makes use of structure would be enough to comply. That makes it easy for an authoring tool to comply with the letter of the requirement without addressing its spirit. For example, it appears that displaying a completely static outline of a document in a separate window would be enough to comply, even though it would provide relatively little benefit.	AUWG: The edit requirement has been combined into the "A.3.4.1 Navigate By Structure:" requirement. [APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		OC6: - A.3.4 – It is not clear to us that exposing content structure necessarily ‘enhances' or ‘simplifies' navigation and editing. In fact, many of our authoring tools are specifically designed to shield the author from the underlying structure. We recommend that this guideline be made advisory.	AUWG: Please see response to MS12 [APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		IBM27: A.3.4 Need to improve the definition of structured web content. " Structured web content is content that includes machine-readable internal structure (e.g., markup elements), as opposed to unstructured content, such as raster image formats or plain human language text."	AUWG: Please see response to MS12 [APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		IBM28: Not all markup elements are structural. A button is not a structural element. Structural elements are those that define structure for other content elements: landmarks, tables, headings, listboxes, lists, tree widgets, etc. Structural elements provide context in a defined layout or order. An example would be a containment model.	AUWG: Please see response to MS12 [APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		IBM29: A.3.4.1 seems pretty subjective to be a Level A requirement. Looking at the "implementing" guidance to understand this better, I would not agree with the table "element" example, at least not for a source code view. If you select a table "element" in a WYSIWYG view, the entire table would be selected so "delete" should delete the entire table. But in a source code view, I don't agree that if you delete the table element you should delete all of the children of that element. The tool might highlight the error somehow but I don't think tools should be making decisions to delete more than the author deletes in a source code view. The example should be changed and this requirement should be moved to AAA because of the subjective nature of it.	AUWG: Please see response to MS12 [APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
A.3.7 [For the authoring tool user interface] Ensure that previews are as accessible as existing user agents.	A.3.7.1 Return Mechanism: If a preview is provided, then authors can return from the preview using only keyboard commands. A.3.7.2 Preview: If a preview is provided, then at least one of the following is true: (a) Third-Party User Agent: The preview makes use of an existing third-party user agent; or (b) UAAG (Level A): The preview conforms to the User Agent Accessibility Guidelines Level A [UAAG].	WCAGWG13: A.3.7.2 Preview: As worded, it appears that a UA that utilizes any third-party user agent for preview would automatically meet this SC. Suggest that part (a) be revised to require the use of the author's default user agent, which would avoid a situation where the author is unable to preview content in the UA that best meets their accessibility needs.	AUWG: The intention is to leave this up to developers (e.g. to embed user agents directly into the authoring tool UI).[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		UAWG3: Suggest changing (a) Third-Party User Agent: The preview makes use of an existing third-party user agent; or to be (a) Third-Party User Agent: The preview makes use of an existing third-party accessible user agent; We think a clearer, less subjective wording for may also be "The preview makes use of an existing third-party user agent that conforms to the User Agent Accessibility Guidelines Level A; or". However, we should also acknowledge that the authoring tool may allow the user to configure which third-party user agent should be used, and should be able to pick an accessible one but should not be prohibited from choosing an inaccessible one. I haven't had time to draft wording that entirely works.	AUWG: Actually, the logic is a bit different. It is that previews are meant to show how content will appear to end users in the "real world" - i.e. in an existing user agent where the user agent accessibility is the user agent developer's concern. (a) is the straightforward way to provide this. But if the authoring tool developer wants to depart from existing user agents, then the accessibility of that new user agent becomes their (the authoring tool developer's) concern and so UAAG would apply.[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		MS16: A.3.7.1 This criterion is redundant to A.3.1.2. Please remove the criterion.	AUWG: Agreed. We have removed this SC.[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		MS17: A.3.7.2 Please remove the term “third-party” from option A. It is not appropriate. This is saying that Microsoft cannot use IE; Google cannot use Chrome; and Apple cannot use Safari. Please remove the term “third-party” completely.	AUWG: We have replaced this term with "pre-existing" to distinguish "user agents" in the marketplace from something developed by the authoring tool developer from scratch.[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		OC9: -A.3.7 – We wonder if there should be a Level AAA requirement that the preview be accessible.	AUWG: We have considered that in the past, but decided that the point of a Preview is to experience authored content the way it will be experienced in “real-world” user agents. Instead we are including a AAA SC to allow author choice of user agents: A.3.7.1 Preview (Enhanced): If a preview is provided, authors can specify which user agent performs the preview (Level AAA) [APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		OC10: -The Rationale for A.3.7 – Regarding the last sentence “Authors with disabilities need to be able to follow the same workflow”, we feel that this may not necessarily be the case. They need to follow ‘a' workflow, which is supported, documented, etc. but it may not be the ‘same' as an author without a disability. Or perhaps a ‘workflow of similar effort'.	AUWG: We have reworded as: “Authors with disabilities need the same opportunity to check their work.”[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		OC11: -A.3.7.2 – As written, there is no requirement that the 3rd party user agent conform to UAAG. Was that the intention? It is also unusual that a company would not be allowed to use their own user agent. Lastly, for clarity, the definition of ‘preview' should discuss renderings such as thumbnails.	AUWG: Please see response to MS17[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		IBM34: A.3.7.1 You need a provision for gestures. I.E. devices that support only gestures should provide a discrete gesture that does this. That gesture should be operable by devices that support people with mobility impairments. Also, you are referring to UAAG 1.0. This document is so dependent on UAAG that I think UAAG 2.0 and ATAG 2.0 need to come to last call together. UAAG 1.0 is 8 years old.	AUWG: We do not understand the "gesture" comment. The UAAG requirement is an optional requirement - ATAG 2.0 is not dependent on it. [APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		IBM35: A.3.7.2 Preview" why does sub-clause a require "third party" user agent? Does this mean that Microsoft authoring tools have to use Firefox, Opera, or Safari instead of IE in their preview mode?	AUWG: Please see response to MS17[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
A.4.1 [For the authoring tool user interface] Help users avoid and correct mistakes.	A.4.1.1 Undo Content Changes: Authoring actions are either reversible by an "undo" function or include a warning to the authors that the action is irreversible. Note 1: It is acceptable to collect a series of text entry actions (e.g., typed words, a series of backspaces) into a single reversible authoring action. Note 2: It is acceptable for certain committing actions (e.g., "save", "publish") to make all previous authoring actions irreversible. A.4.1.2 Undo Setting Changes: Actions that modify authoring tool settings are either reversible or include a warning to authors that the action is irreversible.	MS18: A.4.1.1 How many layers of undo are needed to meet the criterion? Since it is unspecified, we assume one is adequate. Please specify if more than one layer of undo is needed to satisfy the SC.	AUWG: One layer of undo is minimally sufficient at level A. We have added an enhanced requirement at AAA.[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		MS19: A.4.1.1 “Undo” is normally not feasible for many scenarios for basic web form authoring tool or it depends on the browser to carry out the undo. In reality, most actions are reversible without having the “undo” function. If action is reversible, then why impose the specific function of “undo”? Change the SC to read: “Authoring actions are reversible or include warning to authors that the action is irreversible.”	AUWG: Reworded as follows: "For authoring actions, one of the following are true: (a) Reversible: The authoring action can be immediately reversed; or (b) Warn and Confirm: The authoring tool includes a warning to authors that the action is irreversible and requires authors to confirm the action before proceeding. - Note 1: Reversing actions (e.g. an "undo" function) are also considered authoring actions, meaning they must also meet this success criterion (e.g., a "redo" function). - Note 2: It is acceptable to collect a series of text entry actions (e.g. typed words, a series of backspaces) into a single reversible authoring action. - Note 3: It is acceptable to clear the authoring action history at the end of authoring sessions. "[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		MS20: A.4.1.1 This SC requires a warning every time the user execute a file save or the like. This runs against user expectations and will become a serious annoyance. Please add exception for the like of file save from having to give warning.	AUWG: We have modified the definition of "Authoring Actions" to exempt save and publish: "Any action that authors can take using the authoring tool user interface that results in creating or editing web content (e.g. typing text, deleting, inserting an element, applying a template). Most authoring tool user interfaces also enable actions that do not edit content (e.g. saving, publishing, setting preferences, viewing documentation)."[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		MS21: Definition of Authoring Action It is hard to see what an author can do with the tool that is not considered authoring action. Please provide examples of non-authoring actions. Please provide examples of what is not considered authoring action and tighten the definition as necessary.	AUWG: The existing definition includes examples of non-authoring actions: "Any action that authors can take using the authoring tool user interface that results in creating or editing web content (e.g., typing text, deleting, inserting an element, applying a template). Most authoring tool user interfaces also enable actions that do not edit content (e.g., saving, publishing, setting preferences, viewing documentation)."[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		MS22: A.4.1.1 What is the definition of “committing action”? Please add definition	AUWG: That wording has been removed. [APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		GL18. MEDIUM: Consider recommending an Undo stack. A.4.1 discusses Undo and Redo, but only applies to a single operation. As one error may invalidate actions taken after it, and a user may not recognize an error immediately (especially when using AT), consider adding a Level AA or AAA success criteria about allowing the user to undo more than just the single most recent operation (i.e. a stack for undo or undo/redo operations).	AUWG: We will add this new SC: "A.4.1.3 Content Changes Reversible (Enhanced): Authors can sequentially reverse a series of reversible authoring actions. (Level AAA) Note: The notes for A.4.1.1 still apply."[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		GL44. MINOR: Methods of undoing settings changes. Something else to think about regarding "Implementing Success Criterion A.4.1.2 Undo Setting Changes: Actions that modify authoring tool settings are either reversible or include a warning to authors that the action is irreversible. (Level A)": the text noticeably does not mention "Undo" as a method for achieving this. I can tell you from first hand experience that when speech recognition enters the wrong command into a program, the user interface can be changed in a way that is very difficult to correct because you don't know what command made the change. That argues for an "undo" method for application settings. On the other hand, when applications like Adobe Photoshop Lightroom place interface changes and content changes into the same undo stack it causes another set of major usability problems.	AUWG: We have added this example in the Implementing document: "Cancel: On each preference settings page are two options, OK and Cancel. Canceling prevents the setting changes from being applied." [APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		GL32. MEDIUM: Clarify minimum for A.4.1.2 Undo Settings Changes. In "Implementing Success Criterion A.4.1.2 Undo Setting Changes: Actions that modify authoring tool settings are either reversible or include a warning to authors that the action is irreversible. (Level A)", what is the minimum acceptable level of functionality? Would it be acceptable for an application to make the user quit and restart the application to get out of a mode? What if the application provides only a single command to reset all settings to factory default? That would seem to not meet the intent, since it may reset settings that the user needs in order to make the application accessible. (See my other comment on this SC.)	AUWG: We have added "can be reversed by the same mechanism that made the change" as in : "A.4.1.2 Setting Changes Reversible: If actions modify authoring tool settings, then one of the following are true: (Level A) [Implementing A.4.1.2] (a) Reversible: The authoring tool setting can be reversed by the same mechanism that made the change; or (b) Warn and Confirm: The authoring tool includes a warning to authors that the action is irreversible and requires authors to confirm the action or save the current settings before proceeding. "[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		OC12: -A.4.1.1 –By ‘Authoring actions', is this referring to any action, or only those that are ‘significant', ‘harmful', etc.? Is a workflow in the authoring tool that a user must explicitly save an example of ‘undo'? (the author could always choose to not save and open the last-saved file.)	AUWG: "Authoring actions" is a defined term. The example would not meet this, because it would undo lots of authoring actions. [APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		IBM36: A.4.1 Do you have a limit to the number of Undos the author needs to support? One undo is not very helpful.	AUWG: Please see response to MS18[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
A.4.2 [For the authoring tool user interface] Document the user interface including all accessibility features.	A.4.2.1 Document Accessibility Features: All features that are specifically required to meet Part A of this document (e.g. keyboard shortcuts, text search, etc.) are documented.	WCAGWG14: A.4.2.1 Document Accessibility Features: Suggest incorporating the accessibility of the documentation in the SC text itself or include the note from the implementation guide, "The accessibility of the documentation is covered by Guideline A.1.1 and Guideline A.1.2." with the SC.	AUWG: This note has been added: "Note: The accessibility of the documentation is covered by Guideline A.1.1 and Guideline A.1.2." [APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		GL6. HIGH: Accessible documentation. Re "A.4.2: [For the authoring tool user interface] Document the user interface including all accessibility features." I am very surprised that you require things to be documented but not for them to be documented in accessible fashion. The Intent says "The accessibility of the documentation is covered by Guideline A.1.1 and Guideline A.1.2." but that is not normative, and I don't see them as applying to, say, documentation provided on the manufacturer's Web site rather than through the product's user interface. By contrast, UAAG has "5.3.1 Accessible documentation: The product documentation is available in a format that conforms to WCAG 2.0 Level 'A' or greater."	AUWG: Please see response to WCAGWG14[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		GL45. MINOR: Ambiguous phrase in A.4.2.1 Document Accessibility Features. Re "A.4.2.1 Document Accessibility Features: All features that are specifically required to meet Part A of this document (e.g. keyboard shortcuts, text search, etc.) are documented. (Level A)", this is probably silly but the phrase "features that are specifically required to meet" is grammatically ambiguous as to whether it means every feature that is specifically covered by Part A (e.g. all display of content, which is required to be implemented in such a way as to comply with A.2.2.2) or every feature that is implemented specifically to comply with Part A (e.g. undo, which A.4.1.1 requires to be implemented).	AUWG: We have reworded as follows: A.4.2.1 Document Accessibility Features: All features that must be present to meet Part A of ATAG 2.0 (e.g. keyboard shortcuts, text search, etc.) are documented. (Level A) Note: The accessibility of the documentation is covered by Guideline A.1.1 and Guideline A.1.2.[APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
		OC13: -A.4.2.1 – Regarding documenting “all features” we feel this is too broad. This is a requirement for all users, not just people with disabilities so we feel it isn't applicable to ATAG. Even with narrowing to “all ‘accessibility-related' features” this could still be very broad. For example, why would features that are programmatically determinable, such as keyboard shortcuts, need to be ‘documented'?	AUWG: This has been clarified: "A.4.2.2 Document All Features: The authoring tool includes documentation for its author-level user interface features." People with some disabilities benefit more from documentation than users in general. [APPROVED http://www.w3.org/2011/04/11-au-minutes#item03]
B.1.1 Support web content technologies that enable the creation of content that is accessible.	B.1.1.1 Accessible Content Production (WCAG Level A): Authors can use the authoring tool to produce web content that conforms to WCAG 2.0 Level A.	GG5: B1.1.1 (2/3) wording may be too general. E.g. one could use a tool to create WCAG conforming content (if they don't use the table editing features, or don't use the insert Flash feature, for instance). Perhaps add language to include "all" editing functions produce conforming content.	AUWG: This requirement has been moved and reworded to: "B.2.1.1 Accessible Content Possible (WCAG): If the authoring tool places restrictions on the web content that authors can specify, then those restrictions do not prevent WCAG 2.0 success criteria from being met:" [APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
B.1.2 Ensure that the authoring tool preserves accessibility information.	B.1.2.1 Preserve Accessibility Information (Minimum): Any accessibility information (WCAG 2.0 Level A) recognized in the input to any web content transformation is preserved as accessibility information in the output, if allowed by the web content technology of the output. B.1.2.2 End Product Cannot Preserve Accessibility Information: If the web content technology of the output of a web content transformation cannot preserve recognized accessibility information (WCAG 2.0 Level A) (e.g., saving a structured graphic to a raster image format), then at least one of the following are true: (a) Option to Save: Authors have the option to save the accessibility information in another way (e.g., as a "comment", as a backup copy of the input); or (b) Warning: Authors are warned that this will result in web content accessibility problems in the output.	WCAGWG15: B.1.2.2(a): "Option to Save: authors have the option to save the accessibility information in another way (e.g., as a "comment", as a backup copy of the input);" It would be great to add "accessible" to "authors have the option to save the accessibility information in another [accessible] way."	AUWG: We have taken a completely different approach to the preservation requirements in Guideline B.1.2. The requirements are now: - B.1.2.1 Restructuring and Recoding Transformations (WCAG): If the authoring tool provides restructuring transformations or re-coding transformations, then at least one of the following is true: Note: This success criteria only applies to transformations in which the output technology is an "included" technology for conformance. (a) Preserve: Accessibility information (WCAG) is preserved in the output; or (b) Warning: Authors have the default option to be warned that accessibility information may be lost (e.g. when saving a vector graphic into a raster image format); or (c) Automatic Checking: After the transformation, accessibility checking is automatically performed; or (d) Checking Suggested: After the transformation, the authoring tool prompts authors to perform accessibility checking. AND - B.1.2.2 Optimizations Preserve Accessibility: If the authoring tool provides optimizing web content transformations then any accessibility information (WCAG) in the input is preserved in the output. (Level A) AND - B.1.2.3 Text Alternatives for Non-Text Content are Preserved: If the authoring tool provides web content transformations that preserve non-text content in the output, then any text alternatives for that non-text content are also preserved, if equivalent mechanisms exist in the web content technology of the output. (Level A). [APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		MS21: B.1.2.2 Condition b is absolutely not possible if the output is a third party format. This SC essentially asks authoring tool makers to judge and make claim to users which format is less accessible. It would require constant update to keep such info up-to-date and the potential liability of claiming one format is less accessible than another is not something that any manufacturer can accept, especially when it comes to 3rd party format. Please remove condition b.	AUWG: Please see response to WCAGWG15[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		GL16. MEDIUM: Save information for round-tripping. "B.1.2.2 End Product Cannot Preserve Accessibility Information", "(a) Option to Save: authors have the option to save the accessibility information in another way (e.g., as a "comment", as a backup copy of the input)" should support round-tripping. That is, if the authoring tool recognizes accessibility information in the source format that cannot be converted to an equivalent in the output format, it should try to encode the information in the output format in such a way that, when the output format is transformed into back into the original format or to another format that does have the same or equivalent information, the accessibility information can be restored to its proper function. For example, the information can be encoded as comments in the first output format, using a consistent, parsable convention that can be recognized by the authoring tool, and ideally should also be documented for use by third-party authoring and conversion tools.	AUWG: Round-tripping is ideal, but it may not be possible in some situations. E.g., when converting vector graphics to bitmap and back there simply is nowhere for the accessibility info to go. Also, please see response to WCAGWG15[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		OC14: In Part B, we have a concern with the use of the term “accessibility information” and wonder if the correct term is really “programmatically determinable.” The term “accessibility information” is too broad and by changing the term it helps to narrow what is being referred to. We are also concerned with the phrase “human judgment” that is used in many places. What are your expectations for this? It seems to be leading to the tool must almost supply artificial intelligence to know what to do.	AUWG: “programmatically determinable” is a property of many things, not just things related to accessibility. E.g. the height and width of images can be programmatically determined. By “human judgment” we always mean decisions by the human author.[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		OC16: -B.1.2.2 – Regarding entry “b”, the loss of recognized accessibility information does not necessarily result in accessibility problems. We suggest rephrasing as “authors are warned that due to the transformation there could be accessibility problems in the output.”	AUWG: Please see response to WCAGWG15[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		IBM39: B.1.2.1 and B.1.2.3: the parenthetical (WCAG 2.0 Level A) and (up to WCAG 2.0 Level AAA) are critical to the provisions and should not be in parentheticals.	AUWG: Please see response to WCAGWG15[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		IBM40: B.1.2.2 This is too blind user focused and is an unrealistic request. A comment will not be seen by a sighted user. If you make it visible (to all users then it impacts the output negatively). I don't think this is a valid requirement to be included. It is too weak and the right solution would be to get the document author that owns the target to try to expand their accessibility support. Most authoring tools today don't try to stuff un-renderable content in the exported file format. This is also fraught with problems. Let's say there is a describedby relationship to non-visible content used for help information and the target system does not have a means to reference it. If you put the comment in the targeted export a screen reader may not know what it is associated with. This would in essence be orphaned content in the exported document format.	AUWG: Please see response to WCAGWG15[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		IBM42: B.1.2.2 and B.1.2.4: the sub-bullets don't need the word "or" at the end as it is clear from the parent provision that only one of these is required.	AUWG: We are following the WCAG 2.0 style.[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
B.1.3 Ensure that automatically generated content is accessible.	B.1.3.1 Accessible Auto-Generated Content (WCAG Level A): If the authoring tool automatically generates content, then that web content conforms to WCAG 2.0 Level A prior to publishing. Note: This success criterion only applies to the automated behavior specified by the authoring tool developer. It does not apply when actions of authors prevent generation of accessible web content (e.g., authors might set less strict preferences, ignore prompts for accessibility information, provide faulty accessibility information, write their own automated scripts, etc.).	WCAGWG16: Guideline B.1.3 "Ensure that automatically generated content is accessible" and note "See Also: If accessibility information is required from authors during the automatic generation process, see Guideline B.2.1." It's not clear how the SC under Guideline B.2.1 help retrieve accessibility information from authors. Guideline B.2.3 seems to be the most relevant for providing assistance, though "repair" may not be fully accurate as it would apply to Guideline B.1.3. However, given that "actions of authors" is exempt and seems to include the provision of accessibility information (faulty or otherwise) then this may be a moot point.	AUWG: That B.2.1 reference is outdated and has been removed. [APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		MS22: B.1.3 “…prior to publishing.” Invalidates the SC. If a tool generates content in real time, there is no content to meet WCAG 2.0 prior to publishing. The concept has no meaning. Please remove “prior to publishing.” In B.1.3.1, B.1.3.2, and B.1.3.3.	AUWG: This wording has been removed and instead a distinction has been drawn between autogeneration during authoring sessions (B.1.1.2) and auto-generation after authoring session (B.1.1.1). - B.1.1.1 Content Auto-Generation After Authoring Sessions (WCAG): Authors have the default option that, when web content is automatically generated for publishing after the end of an authoring session, it is accessible web content (WCAG). Note: This success criterion applies only to automatic processes specified by the authoring tool developer. It does not apply when author actions prevent generation of accessible web content. - B.1.1.2 Content Auto-Generation During Authoring Sessions (WCAG): Authors have the default option that, when web content is automatically generated during an authoring session, then one of the following is true: [Implementing B.1.1.2] Note 1: Automatic generation includes automatically selecting templates for authors. Note 2: This success criterion applies only to automatic processes specified by the authoring tool developer. It does not apply when author actions prevent generation of accessible web content. (a) Accessible: The content is accessible web content (WCAG) without author input; or (b) Prompting: During the automatic generation process, authors are prompted for any required accessibility information (WCAG); or (c) Automatic Checking: After the automatic generation process, accessibility checking is automatically performed; or (d) Checking Suggested: After the automatic generation process, the authoring tool prompts authors to perform accessibility checking. [APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		OC17: -B.1.3 – What is the significance of “prior to publishing” in each guideline?	AUWG: Please see response to MS22[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		IBM44: B.1.3 The Rationale: is not a complete sentence. (must impose, should impose, etc.) This section refers to repair tasks but does not really address what the repair tasks are other than to say that the generated content must be compliant. Seems confusing.	AUWG: Reworded: "Rationale: If authoring tools automatically specify web content that is not accessible, then additional repair tasks are imposed on authors."[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		IBM45: B.1.3.1: needs to be clarified that the tool must provide a mode of operation that complies with this requirement. It should be allowed to be turned off and it should not be required to be the default at Level A. Requiring it by default would be okay at Level AAA.	AUWG: Please see response to MS22[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		IBM46: B.1.3: unclear what "prior to publishing" means. What if I'm using Microsoft Word to create a document, then I save it as HTML. That's not publishing. It's not "published" until I upload it to my website. Does this requirement only apply to tools that include publishing? Or would it mean that if I use one tool that generates automatic content but doesn't publish and then FTP to upload files to my website, my "set" of authoring tools is non-compliant with ATAG? Per the definition, ATAG applies to all of the tools used in the process.	AUWG: Please see response to MS22[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
B.2.1 Guide authors to create accessible content.	B.2.1.1 Decision Support: If the authoring tool provides the option of producing a web content technology for publishing for which the authoring tool does not provide support for the production of accessible content, then both of the following are true: (a) Warning: Authors are warned that the authoring tool does not provide support for the production of accessible content for that technology; and (b) List: From the warning, authors can access a list of technologies for which the authoring tool does provide support for the production of accessible content. B.2.1.2 Set Accessible Properties: Mechanisms that set the properties of web content (e.g., attribute values, etc.) also include the ability to set the accessibility-related properties. B.2.1.3 Other Technologies: If the authoring tool can insert web content that it cannot subsequently edit, then the authors can associate accessibility information with that web content.	WCAGWG17: B 2.1.1 (a) and elsewhere term "accessible content" is used where perhaps "conforming with WCAG 2.0" would be better.	AUWG: "provide support for the production of accessible content" is already a wordy term without adding a reference to WCAG, so we tightened up the wording as follows: "B.2.2.3 Technology Decision Support: If the authoring tool provides the option of producing a web content technology for publishing for which the authoring tool does not provide support for the production of accessible content, then both of the following are true: (Level A) (a) Warning: Authors are warned that the authoring tool does not provide support for the production of accessible content for that technology; and (b) List: From the warning, authors can access a list of technologies for which the authoring tool does provide support for the production of accessible content"[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		MS23: B.2.1.1 No commercial product, or even most non-commercial one, would take on the liability of claiming accessibility on behalf of a 3rd party technology. This is SC is absolutely not implementable. Please remove B.2.1.1	AUWG: This appears to be a misunderstanding. This SC does not require any claims about 3rd party technology. Rather, it just asks if there are accessibility supports (e.g., ability to add alternative content, checking, etc.) in the authoring tool in question for that format. So the functionality of the authoring tool is the focus. Please also see WCAGWG17[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		MS24: B.2.1.2 What happens if there some properties are set via context menu, some are set on the ribbon, and some are set in a separate dialogue? This SC implies the accessibility-related properties need to be in all of them. We believe there is an unstated assumption that all the mechanisms are interchangeable. That is not a valid assumption. Please revise B.2.1.2	AUWG: This has been reworded to not imply that the mechanisms need to be directly associated: "B.2.2.2 Setting Accessibility Properties (WCAG): If the authoring tool provides mechanisms to set web content properties (e.g. attribute values, etc.), then mechanisms are also provided to set web content properties related to accessibility information (WCAG): Note: Success Criterion B.4.1.4 addresses the prominence of the mechanisms. " [APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		MS25: B.2.1.2 “Accessibility-related properties” is undefined. Please define.	AUWG: Please see response to MS24[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		MS26: B.2.1.3 If the authoring tool cannot edit, then should the burden of making the association be placed on that tool? We can only see very specific situation where this makes sense (time text file upload or adding alt text). Also, what if the content is read-only due to protection? The proposed text is too sweeping. Insert condition of “if the content supports association of accessibility info.”	AUWG: We have removed this success criterion because all of our best examples (alt text on images, alternate content for objects) are already covered by WCAG 2.9 and are therefore covered in other ATAG 2.0 checkpoints.[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		GL24. MEDIUM: Low bar for B2.1.1 Decision Support. Re "B.2.1.1 Decision Support", it seems the intent is that the author should be actively warned when the authoring tool does not support accessible content creation for a specific output format, but the wording is broad enough that all the authoring tool needs to do is (a) provide a note on the Web site or buried in their documentation, and (b) provide at least one output format for which it does provide accessible content creation. The authoring tool should be required to identify less accessible formats at the points where the author chooses one. (I feel this issue is handled much better in "B.2.5.4 Template Selection Mechanism", which says "the selection mechanism indicates...")	AUWG: We wanted to steer away from saying there are "accessible" and "inaccessible" formats to instead emphasizing what the tool in question does to support accessible authoring in the formats that it produces. [APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		GL25. MEDIUM: Clarify minimum requirements for prominence. "Implementing Success Criterion B.2.1.2 Set Accessible Properties" might do well to clarify required prominence. For example, in the example given, if Alt and/or Longdesc had been in the sub-dialog accessed through the "More..." button, would it still comply? What if instead of providing fields for specific accessibility attributes, there was merely a text input field where the author could manually enter any additional attributes and their values?	AUWG: We have added a note that points to B.4.1.4 ("Feature Prominence"). Please see response to MS24[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		OC18: -B.2.1.1 – The sentence “If the authoring tool provides the option of producing a web content technology for publishing…” We recommend replacing the word “technology” with “format” since the output of the tool isn't a technology.	AUWG: The definition of Technology encompasses formats. The term was worked out with WCAG-WG and UAWG so we would prefer not to change it.[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		OC19: -B.2.1.2 – We feel this should be reworded to “At least one typical method to…” instead of “Mechanisms that…”.	AUWG: Unfortunately, “typical” is a difficult concept to test.[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		OC20: -B.2.1.3 –The text as written can work in some situations such as if you import a picture and add alt text to it, but this item doesn't work more broadly without becoming confusing. It really depends on the technology in question. An example is OLE-style situations or importing a movie that isn't accessible. No matter what the tool does, it can't make the movie accessible, it can only describe what is broken about it. It comes down to one tool cannot modify the content of another tool. We do not have proposed text for how to correct this item, but wanted to raise the concern.	AUWG: Please see response to MS26[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		IBM47: B.2.1.1 Showing a warning every time seems intrusive to the author. This is like Vista's constantly asking you if you want to do something. Should this just be documented in the product?	AUWG: Please see response to WCAGWG17[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		IBM48: Also, I am a bit surprised by the fact that the definition of Web Content Technology does not include things like Silverlight or Flash given that WCAG 2 applies to anything delivered over the web. W3C needs to be consistent.	AUWG: Flash is already included and now Silverlight has been added.[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		IBM49: B.2.1.2 This is very good but it needs to be synched with the definition of accessibility information otherwise there will be inconsistencies. I would also point out that both ARIA and HTML 5 refer to well formed content such as Grid must have a row and a row must have a gridcell. Shouldn't authoring tools deal with supporting accurate structural information?	AUWG: Please see response to MS24[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
B.2.2 Assist authors in checking for accessibility problems.	B.2.2.1 Check Accessibility (WCAG Level A): If the authoring tool provides authors with the ability to add or modify web content so that any WCAG 2.0 Level A Success Criterion can be violated, then accessibility checking for those success criteria is provided (e.g., an HTML authoring tool that inserts images should check for alternative text; a video authoring tool with the ability to edit text tracks should check for captions). Note: Automated and semi-automated checking is possible (and encouraged) for many types of web content accessibility problems. However, manual checking is the minimum requirement to meet this success criterion. In manual checking, the authoring tool provides authors with instructions for detecting problems, which authors must carry out by themselves. For more information on checking, see Implementing ATAG 2.0 - Appendix B: Levels of Checking Automation. B.2.2.2 Availability: Checking is available prior to publishing in a manner appropriate to the workflow of the authoring tool. B.2.2.3 Help Authors Decide: For any checks that require author judgment to determine whether a potential web content accessibility problem is correctly identified (i.e., manual checking and semi-automated checking), instructions are provided to help the authors decide whether it is correctly identified. B.2.2.4 Help Authors Locate: For any checks that require author judgment to determine whether a potential web content accessibility problem is correctly identified (i.e., manual checking and semi-automated checking), the relevant content is identified (e.g., highlighting the affected content, displaying line numbers, etc.)	MS27: B.2.2.2 “Appropriate” is not testable. Revise SC B.2.2.2	AUWG: We have removed this success criterion since availability is also addressed in B.4.1. [APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		MS28: B.2.2.2 What happens when there is no defined workflow? Revise SC B.2.2.2	AUWG: Please see response to MS27[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		MS29: B.2.2.2 The concept of “prior to publishing” is not applicable to real time info. How is checking done on an online banking scenario? Revise SC B.2.2.2	AUWG: The phrase "prior to publishing" has been removed. Also we have added a section into the confromance section on "Live publishing authoring tools". Re: Online banking: Web applications in this area do not tend to invole authoring web content for other people to consume (an imagined exception might be if a client and their advisor jointly worked on a wiki), so these tools are generally not considered "authoring tools" by ATAG's definition.[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		MS30: B.2.2.3 This is an AA level SC because B.2.2.1 already provides adequate guidance at A level. Move to AA.	AUWG: This is necessary at Level A since many authors will be unfamiliar with web accessibility considerations.[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		MS31: B.2.2.3 AUWG needs to specify which WCAG 2.0 SCs require author judgment. Add a normative note of which SCs in WCAG 2.0 require author judgment.	AUWG: It can depend on the implementation of the check. E.g. one tool might detect single-colour images as spacers, another might require user input. The SC doesn't refer to WCAG2, it refers to whether a particular authoring tool's UI implementation is asking the human author to make a decision.[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		MS32: B.2.2.4 This SC is AA or AAA. How is a tool supposed to help locate relevant content to meet WCAG 2.0 3.3.2 or 1.3.3, for example? This SC demands far too much intelligence from the tool to be level A. Move SC to AA or AAA.	AUWG: We have clarified that for certain types of problems, the best help in locating an issue that a tool can provide is instructions: B.3.1.3 Help Authors Locate: For checks that require authors to decide whether a potential web content accessibility problem is correctly identified (i.e. manual checking and semi-automated checking), the relevant content is identified to the authors. (Level A) Note: Depending on the nature of the editing-view and the scope of the potential web content accessibility problem, identification might involve highlighting elements or renderings of elements, displaying line numbers, or providing instructions.[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		GL26. MEDIUM: Clarify minimum requirements for B.2.2.1 Check Accessibility. "Implementing Success Criterion B.2.2.1 Check Accessibility (WCAG Level A)" again might do well to clarify whether active prompting of the user is required, or whether it is sufficient for the authoring tool's documentation to merely recommend manual checking. The Note seems to say that automatic testing is never required, even in cases where it is well understood and foolproof; is that actually the intention? (This also applies to B.2.3.1, etc.)	AUWG: Correct. Automated checking is not required. The reason is that it is difficcult to clearly define the "foolproof" cases. That said, authoring tool developers are in the business of automating authoring tasks so the degree of automation should tend to increase, which AUWG believes is what has been observed. "Note: Automated and semi-automated checking is possible (and encouraged) for many types of web content accessibility problems. However, manual checking is the minimum requirement to meet this success criterion. In manual checking, the authoring tool provides authors with instructions for detecting problems, which authors must carry out by themselves. For more information on checking, see Implementing ATAG 2.0 - Appendix B: Levels of Checking Automation."[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		GL27. MEDIUM: Clarify minimum requirements for Help Authors Decide. "Implementing Success Criterion B.2.2.3 Help Authors Decide" again may want to clarify whether simply providing instructions in the manual or online help is sufficient, without any active prompting or guiding the user during their task. If not, how can you phrase it so this is clear?	AUWG: We have reworded to clarify that instructions are sufficient: "B.3.1.2 Help Authors Decide: For checks that require authors to decide whether a potential web content accessibility problem is correctly identified (i.e. manual checking and semi-automated checking), instructions are provided from the check that describe how to make the decision. "[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		OC21: -B.2.2.1 – We are a bit confused by the meaning of this entry - it seems to read overly broad. Can the criteria of “provide checks” be met by just documenting how each standard could be manually checked?	AUWG: Yes, that would meet the requiremetns of a manual check.[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		OC22: -B2.2.3 – The guideline is very broad. While the two examples are clear (manual & semi-manual checks), it is unclear to us in what other circumstances instructions are to be provided to authors around “deciding whether [a check] is correctly identified”. We recommend restricting this Level A guideline to only those two situations, or at least to clearly enumerate the other situations. > Please also clarify if linking to the relevant WCAG2 guidelines would be adequate to meet this guideline for technologies that are covered by WCAG2?	AUWG: The examples of semi-automated and manual are listed as "i.e." implying that those are the two situations.[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		IBM50: B.2.2.1: I think "manual checking" is the wrong term here. The authoring tool is not doing the manual check but rather providing guidance to the author in performing the manual check. The "checking" should only be required where automated checks can be performed.	AUWG: This term might not be perfect, but we believe it is workable and it is also used by WAI-ERT in EARL.[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		IBM51: B.2.2 this should be a configurable item achieved through the use of a plug-in. Also, has the working group considered assisting authors who are creating DHTML content where accessibility changes dynamically during application authoring? This seems to be a gap in that authors may not be aware of.	AUWG: This can be provided by a plug-in. In DHTML, the main difference is that checking may require the content to be rendered in real-time.[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		IBM52: B.2.2.4 Determining where accessibility issues are can be problematic with dynamically generated content.	AUWG: This is definitely a challenge, but of course one that needs to be met, if the resulting content is to be accessible. There are a variety of automated, semi-automated and manual techniques for doing this.[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
B.2.3 Assist authors in repairing accessibility problems.	B.2.3.1 Repair Accessibility (WCAG Level A): For each WCAG 2.0 Level A web content accessibility problem that is identifiable during checking (as required by Guideline B.2.2), repair assistance is provided. Note: Automated and semi-automated repair is possible (and encouraged) for many types of web content accessibility problems. However, manual repair is the minimum requirement to meet this success criterion. In manual repair, the authoring tool provides authors with instructions for repairing problems, which authors must carry out by themselves. For more information on repair, see Implementing ATAG 2.0 - Appendix C: Levels of Repair Automation.	WCAGWG18: B.2.3.1: Typo refers to Guideline B.2.2 should be, "as required by SC B.2.2.1."	AUWG: Agreed.[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
B.2.3 Assist authors in repairing accessibility problems.		OC24: -B.2.3 – Assisting in repair implies prescribing a solution that may not be the only way to do it. There is a concern here that this ultimately could lead to liability, and/or stifling creativity.	AUWG: A checker without any further information is not going to help most people, so we intend to keep the requirement. However, we will re-phrase as "assistance" as "suggestions are provided": "B.3.2.1 Repair Assistance (WCAG): If checking (see Success Criterion B.3.1.1) can detect that a WCAG 2.0 success criterion is not met, then repair suggestion(s) are provided"[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
B.2.4 Assist authors with managing alternative content for non-text content.	B.2.4.1 Editable: Authors are able to modify alternative content for non-text content. This includes types of alternative content that may not typically be displayed on screen by user agents. B.2.4.2 Automated suggestions: During the authoring session, the authoring tool can automatically suggest alternative content for non-text content only under the following conditions: (a) Author Control: Authors have the opportunity to accept, modify, or reject the suggested alternative content prior to insertion; and (b) Relevant Sources: The suggested alternative content is only derived from sources designed to fulfill the same purpose (e.g., suggesting the value of an image's "description" metadata field as a long description). B.2.4.3 Let User Agents Repair: 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 are equally available to user agents (e.g., the filename is not used).	WCAGWG19: B.2.4.1 Editable: "Authors are able to modify...," may be difficult to test and it can be argued that it has been met in situations where it's possible, but more difficult for an author with a disability to make the change. Consider incorporating into the requirement or the implementation guide something about the ease with which an author can make the modification. The "at least as prominent" concept from B.2.5.6 may be a way to address this concern.	AUWG: This is Part B of the document, so the main point is that all authors need to be able to edit alternative content. Part A addresses the accessibility of the authoring tool interface itself.[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		WCAGWG20: B.2.4.2 Automated Suggestions: The use of the word "can" makes this SC sound like it's optional. "During the authoring session, the authoring tool can automatically suggest alternative content..." Suggest "can [be configured to] automatically suggest...."	AUWG: Actually, it is meant to be optional. The wording has been clarified as follows: "B.2.3.2 Conditions on Automated Suggestions: During the authoring session, the authoring tool may only automatically suggest programmatically associated text alternatives for non-text content under the following conditions: (Level A) [Implementing B.2.3.2] (a) Author Control: Authors have the opportunity to accept, modify, or reject the suggested text alternatives prior to insertion; and (b) Relevant Sources: The suggested text alternatives are only derived from sources designed to fulfill the same purpose (e.g. suggesting the value of an image's "description" metadata field as a long description)."[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		GG6: B2.4.2 Automated Suggestions may be too complex to implement in an authoring tool to be a Level A requirement. I see this more as an advanced feature. In terms of Level A "must does" automated suggestion is nice to have, but not a necessary requirement for creating accessible content. If I were an authoring tool developer, I might see this requirement as too strict. This might be a Level AA requirement. B2.4.2 and B2.4.4 would be implemented together. B2.4.4 would be implemented first, to provide the reusable suggestions that would then provide data for automated suggestions.	AUWG: ATAG2 is not requiring automated suggestions. In fact, we are intending to address the opposite problem - of over-enthusiastic automated suggestions. See WCAGWG20 for clarified wording.[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		MS33: B.2.4.1 Is this meant for audio description as well? If not, then the proposed language is too sweeping. Please clarify and tighten the language as necessary..	AUWG: Only if audio description is editable using the tool.[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		MS34: B.2.4.2 This is not a Level A SC. Providing instruction is A. Providing automate suggestion should be AA. Please move SC to AA	Please see response to GG6.[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		MS35: B.2.4.2 “Relevant sources” need testable definition. Please add definition.	AUWG: "Relevant sources" is just the handle. The group considers the text that follows to be testable: "The suggested text alternatives are only derived from sources designed to fulfill the same purpose (e.g. suggesting the value of an image's "description" metadata field as a long description)."[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		GL7. HIGH: Include alternative content for text. Re "B.2.4.1 Editable: Authors are able to modify alternative content for non-text content. This includes types of alternative content that may not typically be displayed on screen by user agents. (Level A)", alternative content for text content (e.g. acronyms, abbreviation) should be handled the same was alternative content for non-text content.	AUWG: ATAG 2 does address other accessibility techniques via our references to WCAG2.[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		GL13. MEDIUM: Standardize on "both of the following are true". I think the phrasing used in B.2.1.1 "both of the following are true: ... ; and ...", is clearer than that used in SC such as B.2.4.2, which only provide the subtle, trailing "; and" to tell the reader that it's an AND rather than OR clause.	AUWG: Agreed, we have made those changes.[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		GL14. MEDIUM: Clarify what authoring tool may repair. "Implementing Success Criterion B.2.4.3 Let User Agents Repair" is great but "c. Repairs are also allowed that go beyond simple text processing to directly processing images, audio or video. The intent here is to encourage progress in these rapidly advancing fields" carves out a category of exception that's not actually reflected in the normative text. In theory, the user agent has just as much access to an audio clip as the authoring tool does, and therefore could perform speech recognition itself or outsource the task to a network resource. Therefore you might want to modify the SC to explicitly make an exception for specialized or processor-intensive tasks (e.g. speech recognition to generate a text transcript or captions from an audio file).	AUWG: This is intended to be addressed by the phrasing "text value" (as opposed to graphics, audio, etc.). This is explained further in the Implementing document. [APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		GL39. MINOR: Clarify it can use metadata that will be stripped. "Implementing Success Criterion B.2.4.3 Let User Agents Repair", although you certainly don't need to, you might want to elaborate on the existing example, that in this same scenario the authoring tool would be justified in generating repair alternative content based on the image metadata if it knows that metadata will be stripped from the image before it is presented to the user agent (e.g. Facebook).	AUWG: Since the authoring tool developer is the one stripping this content, they know that the metadata will not be available to user agents and so they can use it in a repair.[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		GL38. MINOR: Examples for automated omit confirmation. In "Implementing Success Criterion B.2.4.2 Automated Suggestions", the second example explicitly says that the user is given an opportunity to confirm or cancel the suggestion, as is required by the SC, but the other two examples omit this step. That encourages readers to think that confirmation is not an absolute requirement (especially given that the SC's current wording makes it easy to miss the fact that the list of requirements are AND rather than OR).	AUWG: This has been done. [APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		GL37. MINOR: Image metadata Description is not equivalent to longdesc. Re "B.2.4.2 Automated Suggestions", "(b) Relevant Sources: The suggested alternative content is only derived from sources designed to fulfill the same purpose (e.g., suggesting the value of an image's 'description' metadata field as a long description).", if your position is that the "long description" (e.g. longdesc or aria-describedby) should be a visual description, rather than a functional description or additional instructions, then it would not do to automatically use an image's Description metadata field defined by IPTC Core/XMP metadata, as those are equivalent to IPTC-NAA IIM 4.1 "Caption/Abstract" and thus not generally used for visual descriptions. (Whether the HTML5 equivalent of aria-describedby should be limited to visual descriptions is apparently an ongoing discussion.)	AUWG: We understand that automatically adding whatever is found in the metadata description would not be wise. That is why we put in (a) condition: Author Control: Authors have the opportunity to accept, modify, or reject the suggested alternative content prior to insertion.[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		OC25: -B.2.4.3 – The wording of this item is really difficult to understand. It takes many times through to get an idea of what is being asked for. Recommend rewriting.	AUWG: We have tried to reword this text a bit for clarity: "The authoring tool avoids repairing programmatically associated text alternatives for non-text content using any text value that would also be available to user agents (e.g. do not use the image filename). (Level A)".[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		IBM55: B.2.4 Techniques should cover:alt text for graphics, labels for widgets (aria-label, title attribute) and standard input controls, descriptive text as optional (longdesc, aria-describedy, etc.)	AUWG: Several of these are included in this guideline which has been moved to B.2.3.[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
B.2.5 Assist authors with accessible templates and other pre-authored content.	B.2.5.1 Templates Accessible (WCAG Level A): If the authoring tool automatically selects templates or pre-authored content, then the selections conform to WCAG 2.0 Level A when used. Note: Templates may not pass accessibility checks due to their inherent incompleteness. The accessibility status of a template should instead be measured by the accessibility of completed web content (in the final web content technology) created when the template is used properly. B.2.5.2 Provide Accessible Templates: If the authoring tool provides templates, then there are accessible template options for a range of template uses.	WCAGWG21: B.2.5.2 Provide Accessible Templates: Suggest incorporating a requirement to clearly identify accessible template options. (ex. "If the authoring tool provides templates, then there are accessible template options for a range of template uses [and accessible templates are clearly identified as such]." Another approach would be to require that they be "at least as prominent as other templates.	AUWG: The template related requirements have been completely reworked as follows: B.2.4.1 Accessible Template Options (WCAG): If the authoring tool provides templates, then there are accessible template (WCAG) options for a range of template uses. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria) - Note: It is recommended that the accessible options be identified, but this is not required. B.2.4.2 Identify Template Accessibility (Minimum): If the authoring tool includes a template selection mechanism and provides any non-accessible template (WCAG) options, then the templates are provided such that the template selection mechanism can display distinctions between the accessible and non-accessible options. (Level AA) - Note: The distinction can involve providing information for the accessible templates, the non-accessible templates or both. B.2.4.3 Author-Create Templates: If the authoring tool includes a template selection mechanism and allows authors to create new non-accessible templates (WCAG), then authors can enable the template selection mechanism to display distinctions between accessible and non-accessible templates that they create. (Level AA) - Note: The distinction can involve providing information for the accessible templates, the non-accessible templates or both. B.2.4.4 Identify Template Accessibility (Enhanced): If the authoring tool provides any non-accessible templates (WCAG) options and does not include a template selection mechanism, then the non-accessible templates include accessibility warnings within the templates. (Level AAA) [APPROVED http://lists.w3.org/Archives/Public/w3c-wai-au/2011AprJun/0098.html]
		UAWG4: B.2.5.2: How does this differ from just making any templates accessible? One would assume all templates offered should have equal accessibility. What happens if the end user selects a template with less accessibility? It sounds like you're proposing a requirement that if the user selects an inaccessible template, the authoring tool at least provides an accessible mechanism to exit the mode where they're using that template. Also minor, but it might clarify that we're talking about templates that are accessible to the author while creating or editing content, not templates that are designed to produce content accessible to the end-user. Is the latter also addressed somewhere?	AUWG: It is correct that templates may differ in there level of accessibility. Please see WCAGWG21. [APPROVED http://lists.w3.org/Archives/Public/w3c-wai-au/2011AprJun/0098.html]
		MS36: B.2.5.1, B2.5.3, B.2.5.9 How can “…used properly” ever be testable? The note is a necessary component of the SC since most templates cannot meet WCAG 2.0 in their initial state. But adding the note makes the SC not testable.	AUWG: This issue has been moved to a new defined term: Accessible template, which is defined as: Templates that can be filled in to create web content that meets the WCAG 2.0 success criteria (Level A, AA or AAA), when both of the following are true: - The author correctly follows any instructions provided (e.g., correctly responding to prompts, correctly replacing highlighted placeholders); and - No further authoring occurs - Note: Under these conditions, some templates will result in completely empty documents, which are considered accessible by default.. [APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		GL40. MINOR: Clarify definition of template. Re "B.2.5.1 Templates Accessible (WCAG Level A)", would a task like inserting a radio button in a WYSIWIG form editor count as using a template? If so, you might want to include it as another example as people might not think of that type of operation as being a template. You might want to clarify this in the glossary entry for template.	AUWG: The group has decided that automatic use of a template is a subset of automatic content generation and has combined the requirements under Guideline B.1.1: Ensure automatically specified content is accessible.[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		GL31. MEDIUM: Clarify minimum for Provide Accessible Templates. "Criterion B.2.5.2 Provide Accessible Templates" strictly speaking says that the authoring tool needs to provide a minimum of two accessible templates in order to comply. If it includes ten different types of templates (e.g. themed home pages, forms, etc.) is the minimum still two total for the entire authoring tool?	AUWG: It is not perfect, but yes the minimum is two. We have defined "range" with an informative note about its intended sense: "More than one item within a multi-item set. Informative Note: ATAG 2.0 uses the term "range" in several success criteria in which absolute measurements may not be practical (e.g. the set of all help documentation examples, the set of all templates, etc.). While the strict testable requirement is the definition "More than one item within a multi-item set", implementers are strongly encouraged to implement the success criteria more broadly."
		OC27: - B.2.5 Several standards mention a ‘recorded accessibility status', but no advice is provided on how this is to be measured.	AUWG: This has been clarified: B.2.4.2 Identify Template Accessibility (Minimum): If the authoring tool includes a template selection mechanism and provides any non-accessible template (WCAG) options, then the templates are provided such that the template selection mechanism can display distinctions between the accessible and non-accessible options. (Level AA) Note: The distinction can involve providing information for the accessible templates, the non-accessible templates or both.
		OC28: -B.2.5 – We recommend adding a Level AAA where all templates are accessible.	AUWG: It was decided not to add this. The reason is that the ATAG2 levels track the WCAG 2.0 levels so by ATAG2 Level AAA, the accessibility standard is WCAG Level AAA and is was felt that to require every template be Level AAA was not realistic.[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		IBM56: B.2.5.1 There should be an accessible template alternative for components. Some templates may be from third parties and may be inaccessible.	AUWG: Agree that third party templates are exempt if not provided by developer. See Part B: Conformance Applicability Notes: 2. Developer control: The Part B success criteria only apply to the authoring tool as it is provided by the developer. This does not include subsequent modifications by parties other than the authoring tool developer (e.g. by plug-ins, user-defined templates, user modifications of default settings, etc.).[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
B.3.1 Ensure that accessible authoring actions are given prominence.	B.3.1.1 Accessible Options Prominent (WCAG Level A): If authors are provided with a choice of authoring actions for achieving the same authoring outcome (e.g., styling text), then options that will result in web content conforming to WCAG 2.0 Level A are at least as prominent as options that will not.	GL42. MINOR: Another example of Accessible Options Prominent. In "Implementing Success Criterion B.3.1.1 Accessible Options Prominent (WCAG Level A)" you might include as another example that if a WYSIWIG editor includes a toolbar button to bold text, it should be implemented using <strong> rather than <span> (although it is welcome to use a specific style or class on the strong element if it wants to ensure that the user agent renders it as bold rather than using an alternative rendering).	AUWG: This has been moved to B.2.2.1 Accessible Option Prominence (WCAG). and included as examples. [APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		OC29: -B.3.1.1 – We suggest that things like lists and tables should be added to the examples since these are challenging situations.	AUWG: This has been moved to B.2.2.1 Accessible Option Prominence (WCAG). A table example has been added.[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
B.3.2 Ensure that features of the authoring tool supporting the production of accessible content are available.	B.3.2.1 Active by Default: All accessible content support features are turned on by default. B.3.2.2 Reactivate Option: If authors turn off an accessible content support feature, then they can always turn the feature back on.	WCAGWG22: B.3.2.1 Active by Default: Consider softening this requirement to include a subset of support features (ex. those that relate to WCAG Level A). Alternatively, consider changing the level of this SC. The concern here is that automatic tests, especially at Levels AA and AAA, often lead to repetitive and erroneous error and warning messages, which could result in authors being motivated to turn off accessible content support features altogether.	AUWG: It is hard to control bad UI design. But if the features start "off" they may never get turned on. [APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		MS37: B.3.2.1, B.3.2.2, B.3.2.3 The SC assumes that there is some feature to be “turned on” which is an invalid assumption. Please add condition of “If there is a changeable on/off status for such features.”	AUWG: Reworded as: "If authors can turn off an accessible content support feature, then they can turn the feature back on." [APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		MS38: B.3.2.2 Does the term “always” add anything to the criteria? It can be a loaded word to imply that one must be able to turn the feature from any dialogue. Obviously, that's not possible. Please remove the term “always” form the SC.	AUWG: "always" has been removed. [APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		GL12. MEDIUM: Deactivation warning should prompt for confirmation. "B.3.2.3 Deactivation Warning" would be more effective if it required the authoring tool to prompt for confirmation; that is, not only inform the author of the implications of their decision to turn off an accessible content support feature, but also gives them the opportunity to cancel that operation (as is shown in the example).	AUWG: This is better from a usability perspective, but not necessary in the success criterion text. [APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		GL43. MINOR: Example contradicts Active by Default. In "Implementing Success Criterion B.3.2.1 Active by Default", the example is supposed to show "ALL accessible content support features turned on by default" (emphasis added), yet the dialog box shows one of those features ("U.S. Section 508") turned off. Even if you have a reason for this, the first reaction of this reader was to be puzzled, then to decide it's probably an error...	AUWG: This has been fixed. [APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		OC30: -B.3.2.1 – We recommend dividing this into three entries similar to B.3.1.1-B3.1.3 having one entry for each of the Level A, AA and AAA. For example, for Level A all WCAG 2.0 A accessibility features turned on by default.	AUWG: The features themselves generally cut across the WCAG levels already (e.g., checking). [APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
B.3.3 Ensure that features of the authoring tool supporting the production of accessible content are documented.	B.3.3.1 Instructions: Instructions for using the accessible content support features appear in the documentation.
B.3.4 Ensure that any authoring practices demonstrated in documentation are accessible.	B.3.4.1 Model Accessible Practice (WCAG Level A): A range of examples in the documentation (e.g., markup, screen shots of WYSIWYG editing views) demonstrate WCAG 2.0 Level A accessible authoring practices.	WCAGWG23: B.3.4.1, B.3.4.2, B.3.4.3: Consider adding a requirement to these SC that the accessible examples be clearly identified and at least as prominent as other examples in the documentation.	AUWG: The idea is that they don't need to be clearly identified - they are simply worked into the routine documentation. [APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		GL21. MEDIUM: Identify inaccessible practices demonstrated in documentation. In addition to B.2.4.1 requiring that a "range of examples in the documentation...demonstrate WCAG 2.0 Level A accessible authoring practices", consider adding an SC to the effect that any examples in documentation that demonstrate inaccessible authoring practices should include a warning to that effect.	AUWG: While we can see the utility of this suggestion, it might be too prescriptive.[APPROVED http://www.w3.org/2011/04/18-au-minutes.html]
		GL33. MEDIUM: Clarify minimum for B.3.4.1 Model Accessible Practices. Re "B.3.4.1 Model Accessible Practice (WCAG Level A): A range of examples in the documentation (e.g., markup, screen shots of WYSIWYG editing views) demonstrate WCAG 2.0 Level A accessible authoring practices. (Level A)", because "a range" is undefined, the minimum is left unclear. One solution would be to formally require the practice you list in the example, which is that "most" examples demonstrate accessible rather than inaccessible practices.	AUWG: While we realize that range only formally requires 2 instances, the group feels that this wording clearly conveys the spirit, which is for many of the examples to implement this. To say "most" implies 50%+1 which require knowing exactly how many examples were included in the documentation and this might change constantly if the documentation is live. We have defined range with an informative note about its intended sense: "More than one item within a multi-item set. Informative Note: ATAG 2.0 uses the term "range" in several success criteria in which absolute measurements may not be practical (e.g. the set of all help documentation examples, the set of all templates, etc.). While the strict testable requirement is the definition "More than one item within a multi-item set", implementers are strongly encouraged to implement the success criteria more broadly."

Guideline	Success Criteria	Comments	AUWG Responses
A.1.1 [For the authoring tool user interface] Ensure that web-based functionality is accessible.	A.1.1.2 Web-Based Accessible (WCAG Level AA): Web-based authoring tool user interfaces conform to WCAG 2.0 Level AA.
A.3.1 [For the authoring tool user interface] Provide keyboard access to authoring features.	A.3.1.3 Keyboard Shortcuts: Keyboard shortcuts are provided.	MS39: A.3.1.3 Does a web-based authoring tool need to add short cut keys? That seems rather unnecessary and arbitrary. The value of short cut key is contextual. This proposal is too sweeping. Remove this success criterion.	AUWG: No, web-based tools do not need shortcut keys. They can just have skip nav links etc. This requirement has been clarified as follows: A.3.1.3 Efficient Keyboard Access: The authoring tool user interface includes mechanisms to make keyboard access more efficient than sequential keyboard access. (Level AA) [Approved: http://www.w3.org/2002/09/wbs/35520/20110616/results#xq8]
		MS40: Does it meet the success criterion if only two shortcuts are provided since there is no specification? In that case, it would be hard to find any product that would fail this success criterion (file save and quit application are almost always supported)—making this criterion meaningless. Remove this success criterion.	AUWG: Please see the response for MS39.[Approved: http://www.w3.org/2002/09/wbs/35520/20110616/results#xq8]
		GL23. MEDIUM: Keyboard shortcuts requirement is subjective. Re "A.3.1.3 Keyboard Shortcuts: Keyboard shortcuts are provided. (Level AA)" How many keyboard shortcuts? For which functions? I understand the need to be general, but because it is so general it does not seem objectively measurable, despite intention stated in "Understanding Levels of Conformance".	AUWG: Please see the response for MS39.[Approved: http://www.w3.org/2002/09/wbs/35520/20110616/results#xq8]
		IBM23: A.3.1.3 Keyboard shortcuts: This is an advisory, not a requirement, in WCAG 2.0 because it's just not testable in a useful way. As worded, you would technically pass this SC if you have at least two keyboard shortcuts but whether you have actually provided enough keyboard shortcuts to make something usable is highly subjective or requires extensive user testing. This will be a source of controversy with regards to compliance so it should mirror WCAG 2.0 and have this be an advisory technique for meeting A.3.1.1.	AUWG: Please see the response for MS39.[Approved: http://www.w3.org/2002/09/wbs/35520/20110616/results#xq8]
		IBM24: A.3.1.3., A.3.1.5 The techniques refer to all mobile devices having keyboard shortcuts. Is that accurate? Appears to be desktop centric, and not supportive current mobile devices.	AUWG: This requirement has been changed to clarify that mechanisms such as skip-over links qualify: "A.3.1.3 Efficient Keyboard Access: The authoring tool user interface includes mechanisms to make keyboard access more efficient than sequential keyboard access" [APPROVED http://www.w3.org/2002/09/wbs/35520/20110616/results#xq8]
A.3.5 [For the authoring tool user interface] Provide text search of the content.	A.3.5.1 Text Search: Authors can perform text searches of web content as follows: (a) Search All Editable: Any information that is text and that the authoring tool can modify is searchable, including: text content, text alternatives for non-text content, metadata, markup elements and attributes; and Note: If the current editing view is not able to display the results of a search, then the authoring tool may provide a mechanism to switch to a different editing view to display the results. (b) Bi-Directional: The search can be made forwards or backwards; and (c) Case Sensitive: The search can be in both case sensitive and case insensitive modes.	WCAGWG24: A.3.5.1 (b): To avoid confusion with bi-directional text, consider changing the short name of this item to "Two-way."	AUWG: This change has been made.[APPROVED http://www.w3.org/2011/05/09-au-minutes#item06]
		MS41: A.3.5.1 In many cases, this is carried out by the browser or the OS instead of the authoring tool. Does that mean the browsers and OS would be required as part of the conformance? Please explain how reliance on browser and OS are to be handled.	AUWG: Yes, the browser or OS would be involved. For example, in a wiki an authoring view might occur within a text area. I can use my browser's Edit>Find feature to search for terms inside that text area. If I choose to make conformance claim, the browser I tested with is a Required Component of the claim.
		GL4. HIGH: UAAG requirements for text search. "A.3.5.1 Text Search" lacks two search features required by UAAG: (1) "4.6.3 Match Found: When there is a match, the user is alerted and the viewport moves so that the matched text content is at least partially within it. The user can search for the next instance of the text from the location of the match." (2) "4.6.4 Alert on No Match: The user is notified when there is no match or after the last match in content (i.e., prior to starting the search over from the beginning of content). (Level A)"	AUWG: Alert on no match has been added to A.3.5.1 as "(d) No Match: Authors are informed when no results are found." [APPROVED]
		OC7: -A.3.5 – It is not clear that this is specifically an accessibility requirement. Furthermore, it is not clear how one could implement this in practice, for example if the target of the search may be rendered in multiple user interfaces including modal dialogs. Lastly, ‘text that the authoring tool can modify' is too broad, because some of that text may only be available at ‘runtime', in which case it would be the responsibility of the user agent to account for this feature. We recommend that this guideline be made advisory.	AUWG: While all users benefit, people who have difficulty using the keyboard benefit more.
		IBM30: A.3.5.1: the sub-bullets don't need "and" at the end of each one. And is implied by the wording of the parent provision because it doesn't say "one of the following"	AUWG: This is the WCAG 2.0 style. See IBM18. [APPROVED http://www.w3.org/2011/05/09-au-minutes#item08]
		IBM31: A.3.5.1 Most browsers support text search and type ahead capability. Would this satisfy the checkpoint? If so, why is it not in the implementation section? Why do you confine searches to the editing view in this situation? Have you spoken to UAAG about requiring the feature of text searching. This would remove the burden from the author for web content.	AUWG: Browser features can be used (see MS41). Even if it were added to UAAG, it might not be implemented, so it should stay in for now. [APPROVED http://www.w3.org/2011/05/09-au-minutes.html#item09]
A.3.6 [For the authoring tool user interface] Manage preference settings.	A.3.6.1 Save Settings: The authoring tool display settings and control settings are saved between sessions. A.3.6.2 Respect Platform Settings: The authoring tool respects platform display settings and control settings. Note: As per Success Criterion A.2.3.1, the author's display settings must still be independent of the web content being edited.	UAWG5: A.3.6.2: Broaden this to any settings that impact accessibility? If these definitions of "display settings" and "control settings" seem broad enough to possibly include all input or output preference settings;, it would be nice if one didn't have to take the links to the glossary to figure that out, and it's still somewhat ambiguous: would it include the option to hide or show alternative text? Also, an example of preference settings beyond display and control settings that still affect accessibility would be the option to turn on and off AT compatibility modes such as support for platform accessibility API.	AUWG: Broadened to: A.3.6.3 Apply Platform Settings: The authoring tool respects changes in platform display and control settings made by authors. (Level AA)
		MS42: A.3.6.1 There is some inconsistency here from A.3.1.4 where customization is set at AAA, but saving such setting is AA. Please consider moving this SC to AAA to maintain consistency.	AUWG: A.3.6.1 applies to more than just keystrokes. e.g., that a person has set their default editing zoom to 150%.
		MS43: A.3.6.1 Change “…are saved…” to “…can be saved…”. The current wording implies that the tool will do so without user control. Please change wording as suggested.	AUWG: Agree to change.[EDITORIAL]
		MS44: A.3.6.2 Please define “respects” or use more precise language. Please define “respects” or use more precise language	AUWG: "Respect" has been changed to "apply". See UAWG5.
		GL5. HIGH: Need exceptions for A.3.6.2 Respect Platform Settings. "A.3.6.2 Respect Platform Settings: The authoring tool respects platform display settings and control settings. (Level AA)" seems problematic because--while this was certainly not the intention--the wording (a) prevents the authoring tool from allowing the user the override those settings, and (b) prevents it from displaying content as a preview or in WYSIWIG mode when content colors, fonts, and so forth conflict with system preference settings.	AUWG: Previews already have an exception in the Part A Applicability notes #5. "Features for meeting Part A must be accessible: The Part A success criteria apply to the entire authoring tool user interface, including any features added to meet the success criteria in Part A (e.g. documentation, search functions, etc.). The only exemption is for preview features, as long as they meet the relevant success criteria in Guideline A.3.7. Previews are treated differently than editing-views because all authors, including those with disabilities, benefit when preview features accurately reflect the functionality of user agents that are actually in use by end users."
		IBM32: A.3.6.1 Saving authoring tool display and keyboard settings. This seems onerous if you are doing rich web applications. It means you need to have some sort of RESTful service to stash this information. Local Data Storage does not show up until HTML 5 for the web. I am not aware of a web email clients (rich text editing capability) that supports this today.	AUWG: Most web applications with long-term users save any settings that they allow to be changed. e.g. if a theme is set, it is still in use when the user logs back in.[APPROVED http://www.w3.org/2011/05/09-au-minutes.html#item13]
		IBM23: A.3.6.2 Web pages do not have access to keyboard control settings so what happens when you have a web page that acts like an authoring tool? At best you could implement best practices for a given platform but if customization goes on you are out of luck. Browsers have security walls put up to prevent you from asking OS specific information. Is there a plan to address this issue?	AUWG: A web application could allow the author to specify accesskeys. The success criterion simply requires that if the authoring tool allows the user to set a setting then that setting value should be saved for the next session.[APPROVED http://www.w3.org/2002/09/wbs/35520/20110503/results#xq17]
A.4.1 [For the authoring tool user interface] Help users avoid and correct mistakes.	A.4.1.3 Undo is Reversible: Authors can immediately reverse the most recent "undo" action(s).	GL17. MEDIUM: Level conflict between Undo and Undo Reversible. "A.4.1.3 Undo is Reversible: Authors can immediately reverse the most recent 'undo' action(s). (Level AA)" seems to conflict slightly with A.4.1.1 because the latter requires at Level A that all operations that change content be subject to an "undo" operation, while the former says that providing "undo" for an "undo" operation that changed content is only Level AA. You could fix this by explicitly exempting undo from the undo requirement, or by changing the level of the redo requirement, etc.	AUWG: This requirement has been combined with the main undo requirement with the addition of this note ("Note 1: Reversing actions (e.g. an "undo" function) are also considered authoring actions, meaning they must also meet this success criterion (e.g., a "redo" function). ").[APPROVED http://www.w3.org/2002/09/wbs/35520/20110503/results#xq18]
		GL36. MINOR: AT also introduces errors. In "Implementing Guideline A.4.1: [For the authoring tool user interface] Help authors avoid and correct mistakes", the rationale could include not only people who have difficulty with fine motor control, but also those who rely on assistive technologies such as speech recognition, which introduce errors through misrecognition.	AUWG: The rationale now reads: "Rationale: Some authors with disabilities may be more susceptible to input errors due to factors such as difficulty making fine movements and speech recognition system errors."[APPROVED http://www.w3.org/2011/05/09-au-minutes.html#item14]
A.4.2 [For the authoring tool user interface] Document the user interface including all accessibility features.	A.4.2.2 Document All Features: All features of the authoring tool are documented.	MS45: A.4.2.2 “All features” is too encompassing. Hidden features are common place. Besides, how is non-documented features affecting people with disabilities any more than those without disabilities. This SC is not at all related to accessibility. Please remove A.4.2.2	AUWG: Reworded as: "A.4.2.2 Document All Features: The authoring tool includes documentation for its author-level user interface features. (Level AA)"
		IBM37: A.4.2.2 Does this require statements of UAAG conformance?	AUWG: We assume you mean WCAG conformance of the help documents as per the note. Neither WCAG2 nor ATAG2 require conformance claims to be made.
B.1.1 Support web content technologies that enable the creation of content that is accessible.	B.1.1.2 Accessible Content Production (WCAG Level AA): Authors can use the authoring tool to produce web content that conforms to WCAG 2.0 Level AA.
B.1.2 Ensure that the authoring tool preserves accessibility information.	B.1.2.3 Preserve Accessibility Information (Enhanced): Any accessibility information (up to WCAG 2.0 Level AAA) recognized in the input to any web content transformation is preserved as accessibility information in the output. B.1.2.4 Notification Prior to Deletion: If the authoring tool automatically deletes any author-generated content for any reason, then at least one of the following is true: (a) Preserve Accessibility Information: The authoring tool only automatically deletes web content that it can detect is not accessibility information; or (b) Notification Option: Authors have the option to receive notification before deletion; or (c) No Deletion Option: Authors have the option to prevent automatic deletion by the authoring tool.	JR: does not properly mirror B.1.2.1. Should be B.1.2.3 Preserve Accessibility Information (Enhanced): Any accessibility information (up to WCAG 2.0 Level AAA) recognized in the input to any web content transformation is preserved as accessibility information in the output, if allowed by the web content technology of the output.	AUWG: The preservation requirements have been reorganized. See WCAGWG15. [EDITORIAL]
		WCAGWG25: B.1.2.4(a) "Preserve Accessibility Information: The authoring tool only automatically deletes web content that it can detect is not accessibility information;" This is confusing. The non-accessible part of web content that is associated with the accessibility information should not be deleted.	AUWG: The preservation requirements have been reorganized. See WCAGWG15. [APPROVED http://www.w3.org/2011/05/16-au-minutes.html#item12]
		WCAGWG26: B.1.2.4(b) "Notification Option: Authors have the option to receive notification before deletion;" Add "and are warned that this may result in web content accessibility problems in the output"	AUWG: The preservation requirements have been reorganized. See WCAGWG15. [APPROVED http://www.w3.org/2011/05/16-au-minutes.html#item12]
		MS46: B.1.2.3 We suspect there is an error here where the accessibility information should be up to WCAG 2.0 Level AA, not AAA. There should also be a similar SC for AAA. Please change the SC language from “…WCAG 2.0 Level AAA…” to “…WCAG 2.0 Level AA…” Add a new SC to cover AAA	AUWG: The preservation requirements have been reorganized (with this multi-level comment worked in). See WCAGWG15.[APPROVED http://www.w3.org/2011/05/16-au-minutes.html#item14]
		MS47: B.1.2 How does this apply to something like a copy and paste operation from a rich text editor to a plain text editor where structural info will be lost? Who is supposed to tell the author that the structure is gone? Please explain how the SC applies to copy-and-paste or cut-and-paste operations?	AUWG: The preservation requirements have been reorganized. See WCAGWG15.[APPROVED http://www.w3.org/2011/05/16-au-minutes.html#item15]
		MS48: B.1.2.4 Please identify a real life product with option c. This seems like a theoretical option. Please provide real life example for option c.	AUWG: The preservation requirements have been reorganized. See WCAGWG15.[APPROVED http://www.w3.org/2011/05/16-au-minutes.html#item16]
		IBM41: B.1.2.3 - Why is the AA requirement to preserve accessibility information up to WCAG 2.0 Level AAA? It should only be up to Level AA. If Level AAA is required, there should be another provision.	AUWG: The preservation requirements have been reorganized. See WCAGWG15.[APPROVED http://www.w3.org/2011/05/16-au-minutes.html#item17]
		IBM43: B.1.2.4 Most if not all information is accessibility information. If I export a file to PDF are you going to interrupt the user ever time it runs into an unsupported feature in the target document format? This seems unrealistic. For example, text is important to accessibility as is alt text. I think accessibility information needs expansion for that reason. Also what about labels and live region support - any accessibility property.	AUWG: The preservation requirements have been reorganized. See WCAGWG15.[APPROVED http://www.w3.org/2011/05/16-au-minutes.html#item18]
B.1.3 Ensure that automatically generated content is accessible.	B.1.3.2 Accessible Auto-Generated Content (Level AA): If the authoring tool automatically generates content, then that web content conforms to WCAG 2.0 Level AA prior to publishing. Note: This success criterion only applies to the automated behavior specified by the authoring tool developer. It does not apply when actions of authors prevent generation of accessible web content (e.g., authors might set less strict preferences, ignore prompts for accessibility information, provide faulty accessibility information, write their own automated scripts, etc.).	JR: Should be B.1.3.2 Accessible Auto-Generated Content (WCAG Level AA):	AUWG: This has been re-organized instead.[APPROVED http://www.w3.org/2011/05/16-au-minutes.html#item19]
B.2.2 Assist authors in checking for accessibility problems.	B.2.2.5 Check Accessibility (WCAG Level AA): If the authoring tool provides authors with the ability to add or modify web content so that any WCAG 2.0 Level AA Success Criterion can be violated, then accessibility checking for those success criteria is provided. Note: Automated and semi-automated checking is possible (and encouraged) for many types of web content accessibility problems. However, manual checking is the minimum requirement to meet this success criterion. In manual checking, the authoring tool provides authors with instructions for detecting problems, which authors must carry out by themselves. For more information on checking, see Implementing ATAG 2.0 - Appendix B: Levels of Checking Automation. B.2.2.6 Status Report: Authors can receive an accessibility status report based on the results of the accessibility checks. Note: The format of the accessibility status is not specified. For example, the status might be a listing of problems detected or a WCAG 2.0 conformance level, etc. B.2.2.7 Metadata Production: Authors have the option of associating accessibility checking results with the web content as metadata. (Level AA) Note: The metadata format that is implemented will dictate the nature of the associated results (e.g., low-level check results, high-level conformance claims, etc.)	MS49: B.2.2.7 This SC belongs to AAA. Move SC to AAA.	AUWG: This has been reworded as "B.3.1.5 Programmatic Association of Results: Authoring tools can programmatically associate accessibility checking results with the web content that was checked. (Level AA)". We believe this is flexible enough to be classified AA. The data might be as simple as a single WCAG conformance level value.
		GL28. MEDIUM: Clarify minimum requirements for Status Report. "Implementing Success Criterion B.2.2.6 Status Report" again could better clarify the minimum requirements for conforming. For example, if the user chooses a menu command to check the document and it provides a dialog box listing the errors and potential errors, but provides no way to save or print that information, does that still count as a "report"? What if the dialog box only shows one error or potential error, and the user has to press a "Next" button to display each successive point?	AUWG: Your point is taken, but at some point we can't control bad UI design. See IBM53. [APPROVED http://www.w3.org/2011/06/06-au-minutes.html#item04]
		GL29. MEDIUM: Clarify minimum requirements for Metadata Production. "Implementing Success Criterion B.2.2.7 Metadata Production" could clarify whether saying the results must be stored "with the web content as metadata" means it must be stored in the file (e.g. as markup in the HTML document) or whether it can be separate (e.g. in the tool's database or in separate report files). If the latter, then it's hard to see how it differs from the requirement to make a report of test results available, other than that this might require it to be machine-readable and parsable using a documented format, instead of only human-readable text.	AUWG: As you say, metadata is machine readable and parsable, whether or not it is human readable.[APPROVED http://www.w3.org/2011/06/06-au-minutes.html#item05]
		OC23: -B.2.2.7 – We recommend making this Level AAA.	AUWG: See MS49.
		IBM53: B.2.2.6 Difficult to have a web email client or a wiki provide a status report on accessibility of dynamic content. There is value, but this is a significant requirement, should be AAA and configurable.	AUWG: The status requirement ("B.3.1.4 Status Report: Authors can receive an accessibility status report based on the results of the accessibility checks. (Level AA) Note: The format of the accessibility status is not specified. For example, the status might be a listing of problems detected or a WCAG 2.0 conformance level, etc. ") is simply that the author receive information about the state of things from the accessibility checker. The note clarifies that the format of the report is not specified. If the checker hasn't run, there will be nothing to report. Your comment raises email, wikis and dynamic content as issues, which we will address separately: - in the case of email, an accessibility checker, like a spell checker is something a sender may or may not choose to run. For example, sending a quick personal note to a known recipient requires less vigilance than posting to a publicly-archived forum. - wikis have the challenge that the wiki system doesn't usually have access to the content until the user submits it (though DHTML implementations change this). However, this need not be a problem since the user can re-edit content if/when content issues are identified by the system (whether they are issues of wiki syntax, spelling or accessibility) - by "dynamic content" you may be referring to DHTML-type content. This certainly presents challenges to automated checkers, however some progress has been made on checker design in this area and in these cases communication of results back to the author seems to be a reasonable use case.
		IBM54: B.2.2.7 Need more concrete examples of using metadata here. Metadata is very abstract.	AUWG: See MS49.
B.2.3 Assist authors in repairing accessibility problems.	B.2.3.2 Repair Accessibility (WCAG Level AA): For each WCAG 2.0 Level AA web content accessibility problem that is identifiable during checking (as required by Success Criterion B.2.2.5), repair assistance is provided. Note: Automated and semi-automated repair is possible (and encouraged) for many types of web content accessibility problems. However, manual repair is the minimum requirement to meet this success criterion. In manual repair, the authoring tool provides authors with instructions for repairing problems, which authors must carry out by themselves. For more information on repair, see Implementing ATAG 2.0 - Appendix C: Levels of Repair Automation.
B.2.4 Assist authors with managing alternative content for non-text content.	B.2.4.4 Save for Reuse: Authors have the option of having any recognized plain text alternative content that they enter (e.g., short text labels, long descriptions) stored for future reuse.	MS50: B.2.4.4 This SC seems extraneous. If text alternative can be accessed, then obviously it can be reused. If nothing, at least delete “for future reuse.” since it represents future event which is unverifiable at the time of conformance claim. Consider deleting the SC or at least delete “for future use.”	AUWG: Reworded for clarity: B.2.3.4 Save for Reuse: When authors enter programmatically associated text alternatives for non-text content, both of the following are true: (Level AAA) (a) Save and Suggest: the text alternatives are automatically saved and suggested by the authoring tool, if the same non-text content is reused; and (b) Edit Option: the author has the option to edit or delete the saved text alternatives.
		GL30. MEDIUM: Clarify minimum requirements for Save for Reuse. "B.2.4.4 Save for Reuse: Authors have the option of having any recognized plain text alternative content that they enter (e.g., short text labels, long descriptions) stored for future reuse. (Level AA)" does not make it clear whether the content strings need to be associated with the original content (e.g. with the image), or that the user should be able to delete obsolete or erroneous entries to keep the list from becoming unwieldy. I worry that a simple way of complying is just to have a single, ever-growing list of previously used strings that can quickly change from useful to detrimental (like Thunderbird's list of recipients), so even if the minimum is left vague, I recommend at least providing some guidance or best practices.	AUWG: See response for MS50.
		OC26: -B.2.4.4 – We recommend making this Level AAA as this is applies equally to non- accessibility related content and moves into a product usability feature.	AUWG: it has been moved to AAA. See response for MS50.
B.2.5 Assist authors with accessible templates and other pre-authored content.	B.2.5.3 Templates Accessible (WCAG Level AA): If the authoring tool automatically selects templates or pre-authored content, then the selections conform to WCAG 2.0 Level AA when used. Note: Templates may not pass accessibility checks due to their inherent incompleteness. The accessibility status of a template should instead be measured by the accessibility of completed web content (in the final web content technology) created when the template is used properly. B.2.5.4 Template Selection Mechanism: If authors are provided with a template selection mechanism, then both of the following are true: (a) Indicate: The selection mechanism indicates the accessibility status of templates (if known); and (b) Prominence: Any accessible template options are at least as prominent as other template options. B.2.5.5 New Templates: If authors can use the authoring tool to create new templates for use by a template selection mechanism, they have the option to record the accessibility status of the new templates. B.2.5.6 Pre-Authored Content Selection Mechanism: If authors are provided with a selection mechanism for pre-authored content other than templates (e.g., clip art gallery, widget repository, design themes), then both of the following are true: (a) Indicate: The selection mechanism indicates the accessibility status of the pre-authored content (if known); and (b) Prominence: Any accessible options are at least as prominent as other pre-authored content options.	GG7: B2.5.6 Pre-Authored Content: Also see B2.5.8 below - Who decides on the accessibility status of pre-authored content, which may be user provided. In note (a) the words "Indicate" and "if known" provides a loophole that would allow tools to ignore this guideline. If none of the pre-authored content is reviewed for accessibility, developers can pass this requirement by omitting the accessibility status.	AUWG: This is now B.2.5.1. The accessibility might be determined by a checking mechanism and recorded with metadata. [APPROVED http://www.w3.org/2011/06/06-au-minutes.html#item12]
		UAWG6: B.2.5.4: The definition for prominence says in part: For purposes of conformance to ATAG 2.0, item A is considered to be at least as prominent as item B if: both items occur in the same item container (e.g., a menu for menu items, a list for list items, a dialog box for text boxes); if item B is emphasized, then so is item A; so if the accessible option is at the bottom of a menu separated from the less accessible option by 10 entires, this is acceptable? If the list has 25 items and the user must scroll to see the accessible option, is this then acceptable? Off the topic somewhat, but the question of whether accessible options should be displayed as prominently as, and/or in proximity to, their inaccessible counterparts applies to more things than just templates (for example, a list of schemes).	AUWG: The defintion has been reformulated: "at least as prominent: For ATAG 2.0, a user interface component A is considered to be "at least as prominent" as another component B when, from a default state, component A becomes displayed (and enabled) with the same number or less "opening" actions than are required for component B to become displayed (and enabled). - Note 1: When a container is open, all of the enabled components in the container (e.g. items in a list, items in a menu, buttons in a toolbar, all components on a dialog box, etc.) are considered to be displayed (and therefore are at least as prominent as each other), even if the container must be scrolled for them to become visible. This takes into account that different screen sizes and author settings will affect which components are visible at a given time. - Note 2: "Opening actions" are actions made by authors on components within the user interface that result in new components becoming displayed or enabled. For example: (a) keyboard shortcut to a top-level menu item to display a sub-menu, (b) keyboard selection on a button to display a dialog box, (c) mouse click on a checkbox to enable previously disabled sub-items, etc. Actions that do not cause new components to become actionable (e.g., moving focus, scrolling a list), are not counted as "opening actions". - Note 3: Keyboard shortcuts to components in closed containers are not counted as "opening actions" because the components have no prominence when they are not displayed. The same is true when authors must use "search" to reveal components in closed containers. - Note 4: The "default state" is the state of the authoring tool at the beginning of an authoring session as set by the developer. The default state of many document authoring tools is an editing-view. "
		MS51: B.2.5.4 If all templates are equally accessible, why would this be necessary or beneficial? There seems to be an assumption here that the templates are not all of similar accessibility status. Revise the SC	AUWG: The template requirements have been reworked. Please see response to MS22
		MS52: B.2.5.4 Please provide examples of how one goes about indicating the accessibility status of a template. How much detail is needed? Please provide instruction of the level of detail required to indicate template accessibility status.	AUWG: The template requirements have been reworked. Please see response to MS22
		MS53: B.2.5.4 What happens when there is a large variety of template of all different sorts? The language suggests that the “accessible” option must take precedence regardless of other logical grouping. Please change the SC to account for other logical grouping of templates.	AUWG: The template requirements have been reworked. Please see response to MS22
		MS54: B.2.5.4 The term “…accessible template options” implies that there is a distinction of “accessible template” and “non-accessible” template. How does one go about making such distinction? Without an exact definition, this SC is not testable. Please provide a structured way to indicate accessibility status of templates and how to go about showing prominence of template of various (or equal) status.	AUWG: The template requirements have been reworked. Please see response to MS22
		MS55: B.2.5.5 This SC assumes that author is given freedom to create templates with different degree of accessibility. The assumption is not always valid. Please address the scenario in which author has no freedom to change accessibility of a template.	AUWG: Agreed, but in cases where the result is always accessible, this would seem to simplify the task of lablling it as such. AUWG: The template requirements have been reworked. Please see response to MS22
		MS56: B.2.5.6 All comments from 2.5.4 apply equally. Please reference comments from B.2.5.4	AUWG: The template requirements have been reworked. Please see response to MS22
		GL41. MINOR: Indicators during template selection. Re "B.2.5.4 Template Selection Mechanism", would you really recommend listing entries like "slide show template - wcagA"? If you want to recommend something, wouldn't "slide show template (WCAG A)" be more acceptable to users and software designers? The examples might also be more acceptable to designers and developers if you show their mainstream uses, such as also showing which templates are available in multiple languages, whether they're suitable for small screens, etc.	AUWG: The template requirements have been reworked. Please see response to MS22
B.3.1 Ensure that accessible authoring actions are given prominence.	B.3.1.2 Accessible Options Prominent (WCAG Level AA): If authors are provided with a choice of authoring actions for achieving the same authoring outcome (e.g., styling text), then options that will result in web content conforming to WCAG 2.0 Level AA are at least as prominent as options that will not.
B.3.2 Ensure that features of the authoring tool supporting the production of accessible content are available.	B.3.2.3 Deactivation Warning: If authors turn off an accessible content support feature, then the authoring tool informs them that this may increase the risk of content accessibility problems. B.3.2.4 At Least as Prominent: Accessible content support features are at least as prominent as comparable features related to other types of web content problems (e.g., invalid markup, syntax errors, spelling and grammar errors).	WCAGWG27: B.3.2.3 Deactivation Warning: Consider promoting this SC to Level A.	AUWG: The Working Group decided to keep this at AA since it was not judged "essential".[APPROVED http://www.w3.org/2011/06/13-au-minutes.html#item03]
		MS57: B.3.2.4 “Comparable” is not testable. Please revise SC.	AUWG: Reworded as follows: "B.4.1.4 Feature Prominence: Accessible content support features are at least as prominent as features related to either invalid markup, syntax errors, spelling errors or grammar errors. (Level AA)" [APPROVED http://www.w3.org/2011/06/13-au-minutes.html#item04]
		MS58: B.3.2.4 “Other types of web content problems” has no definition and, thus, there is no way to determine if the SC is met. Please replace “other types of web content problems” with something more precise.	AUWG: Please see response to MS57.[APPROVED http://www.w3.org/2011/06/13-au-minutes.html#item05]
		GL19. MEDIUM: User should be allowed to override B.3.2.4 At Least As Prominent. Re "B.3.2.4 At Least as Prominent: Accessible content support features are at least as prominent as comparable features related to other types of web content problems (e.g., invalid markup, syntax errors, spelling and grammar errors). (Level AA)" is an example of a success criterion that should acknowledge that this refers to the default user interface, but that the user can be allowed to override these defaults.	AUWG: This is covered by: Part B Applicability Note 2: Developer control: The Part B success criteria only apply to the authoring tool as it is provided by the developer. This does not include subsequent modifications by parties other than the authoring tool developer (e.g. by plug-ins, user-defined templates, user modifications of default settings, etc.).[APPROVED http://www.w3.org/2011/06/13-au-minutes.html#item06]
		OC31: -B3.2.4 – Because there are a variety of prominence levels for the examples given it will be very subjective which to choose. How we would highlight markup is very different from a spelling issue. This makes the item very subjective and hard to test.	AUWG: Please see response to MS57.[APPROVED http://www.w3.org/2011/06/13-au-minutes.html#item07]
B.3.4 Ensure that any authoring practices demonstrated in documentation are accessible.	B.3.4.2 Model Accessible Practice (WCAG Level AA): A range of examples in the documentation (e.g., markup, screen shots of WYSIWYG editing views) demonstrate WCAG 2.0 Level AA accessible authoring practices.	MS59: B.3.4.1 What counts as a range? Two or more? Please remove “A range of” from the SC	AUWG: Yes two or more is the minimum. We have defined "range" with an informative note about its intended sense: "More than one item within a multi-item set. Informative Note: ATAG 2.0 uses the term "range" in several success criteria in which absolute measurements may not be practical (e.g. the set of all help documentation examples, the set of all templates, etc.). While the strict testable requirement is the definition "More than one item within a multi-item set", implementers are strongly encouraged to implement the success criteria more broadly."

Guideline	Success Criteria	Comments	AUWG Responses
A.1.1 [For the authoring tool user interface] Ensure that web-based functionality is accessible.	A.1.1.3 Web-Based Accessible (WCAG Level AAA): Web-based authoring tool user interfaces conform to WCAG 2.0 Level AAA.
A.2.2 [For the authoring tool user interface] Editing view presentation can be programmatically determined.	A.2.2.3 Access to Text Presentation (Enhanced): If an editing view (e.g., WYSIWYG view) renders any presentation properties for text, then those properties can be programmatically determined.	GL2: HIGH: Note misleading about scope of A.2.2.3: ATAG's "Implementing Success Criterion A.2.2.3" has a note that is misleading as it seems to limit the scope of the SC to only properties that can be edited by the authoring tool, whereas the SC clearly applies to all properties that are rendered whether they can be edited or not. The SC says "If an editing view (e.g., WYSIWYG view) RENDERS any presentation properties for text, then those properties can be programmatically determined." Whereas the note says "See Implementing Success Criterion A.2.2.2, substituting all text presentation properties that are BOTH RENDERED AND EDITABLE by the authoring tool for the four presentation properties listed in A.2.2.2." (emphasis added)	AUWG: Combined into: "A.2.2.2 Access to Rendered Text Properties: If a text property is both rendered and editable and the property can be communicated by the supported platform accessibility service, then the property is programmatically determinable. (Level A)"[APPROVED http://www.w3.org/2002/09/wbs/35520/20110504/results#xq1]
A.3.1 [For the authoring tool user interface] Provide keyboard access to authoring features.	A.3.1.4 Keyboard Access (Enhanced): All functionality of the authoring tool is operable through a keyboard interface. A.3.1.5 Customize Keyboard Access: Keyboard access to the authoring tool can be customized. A.3.1.6 Present Keyboard Commands: Authoring tool user interface controls can be presented with their associated keyboard commands.
A.3.2 [For the authoring tool user interface] Provide authors with enough time.	A.3.2.4 Content Edits Saved (Extended): The authoring tool can be set to save all content edits made by authors.	WCAGWG28: A.3.2.4 Content Edits Saved (Extended): Suggest revising this SC to include "automatically" (The authoring tool can be set to [automatically] save all content edits made by authors.)	AUWG: Change made.
		GL35: MINOR: Additional benefit to autosave. A minor suggestion re "Implementing Success Criterion A.3.2.4 Content Edits Saved (Extended): The authoring tool can be set to save all content edits made by authors. (Level AAA)" is that an additional benefit of both document recovery and Undo capability is that while unfortunate, it is true that users with some disabilities experience a larger number of crashes and incorrect commands than the typical user, such as those caused when a speech recognition utility misunderstands the user, or when typing difficulties result in incorrect key-presses.	AUWG: This text was added: "Increasing the frequency with which content edits are saved also helps authors recover more easily from inadvertent actions. " [APPROVED]
A.3.6 [For the authoring tool user interface] Manage preference settings.	A.3.6.3 Multiple Sets: Authors can save and reload multiple sets of any authoring tool display settings and control settings. A.3.6.4 Options Assistance: The authoring tool includes a mechanism to help authors configure any options related to Part A of this document.	OC8: -A.3.6.3 – Regarding loading multiple sets, we question why this is an accessibility issue. We recommend removing it.	AUWG: Some users are aided by the ability to have multiple sets of preferences (e.g., because their vision or motor control fatigues easily).
B.1.1 Support web content technologies that enable the creation of content that is accessible.	B.1.1.3 Accessible Content Production (WCAG Level AAA): Authors can use the authoring tool to produce web content that conforms to WCAG 2.0 Level AAA.
B.1.3 Ensure that automatically generated content is accessible.	B.1.3.3 Accessible Auto-Generated Content (Level AAA): If the authoring tool automatically generates content, then that web content conforms to WCAG 2.0 Level AAA prior to publishing. Note: This success criterion only applies to the automated behavior specified by the authoring tool developer. It does not apply when actions of authors prevent generation of accessible web content (e.g., authors might set less strict preferences, ignore prompts for accessibility information, provide faulty accessibility information, write their own automated scripts, etc.).	WCAGWG29: Should be: B.1.3.3 Accessible Auto-Generated Content (WCAG Level AAA)	AUWG: Agreed.[APPROVED http://lists.w3.org/Archives/Public/w3c-wai-au/2011AprJun/0045.html]
B.2.2 Assist authors in checking for accessibility problems.	B.2.2.8 Check Accessibility (WCAG Level AAA): If the authoring tool provides authors with the ability to add or modify web content so that any WCAG 2.0 Level AAA Success Criterion can be violated, then accessibility checking for those success criteria is provided.. Note: Automated and semi-automated checking is possible (and encouraged) for many types of web content accessibility problems. However, manual checking is the minimum requirement to meet this success criterion. In manual checking, the authoring tool provides authors with instructions for detecting problems, which authors must carry out by themselves. For more information on checking, see Implementing ATAG 2.0 - Appendix B: Levels of Checking Automation.
B.2.3 Assist authors in repairing accessibility problems.	B.2.3.3 Repair Accessibility (WCAG Level AAA): For each WCAG 2.0 Level AAA web content accessibility problem that is identifiable during checking (as required by Success Criterion B.2.2.10), repair assistance is provided. Note: Automated and semi-automated repair is possible (and encouraged) for many types of web content accessibility problems. However, manual repair is the minimum requirement to meet this success criterion. In manual repair, the authoring tool provides authors with instructions for repairing problems, which authors must carry out by themselves. For more information on repair, see Implementing ATAG 2.0 - Appendix C: Levels of Repair Automation.
B.2.5 Assist authors with accessible templates and other pre-authored content.	B.2.5.7 Templates in Repository: If the authoring tool provides a repository of templates, then each of the templates has a recorded accessibility status. B.2.5.8 Pre-Authored Content in Repository: If the authoring tool provides a repository of pre-authored content, then each of the content objects has a recorded accessibility status. B.2.5.9 Templates Accessible (WCAG Level AAA): If the authoring tool automatically selects templates or pre-authored content, then the selections conform to WCAG 2.0 Level AAA when used. Note: Templates may not pass accessibility checks due to their inherent incompleteness. The accessibility status of a template should instead be measured by the accessibility of completed web content (in the final web content technology) created when the template is used properly.	GG8: B2.5.8 Pre-Authored content in a repository is generally user provided, as opposed to developer provided. Should there be a distinction here between what the system provides, and what is provided by others? Perhaps distinguished in a way similar to the incompleteness of templates in the note for B.2.5.9. A definition of "pre-authored-content", might also be provided here, distinguishing it from templates.	AUWG: This has been addressed by the addition of this Applicability Note: "Developer control: The Part B success criteria only apply to the authoring tool as it is provided by the developer. This does not include subsequent modifications by parties other than the authoring tool developer (e.g. by plug-ins, user-defined templates, user modifications of default settings, etc.)."[APPROVED http://lists.w3.org/Archives/Public/w3c-wai-au/2011AprJun/0045.html]
		MS60: B.2.5.7 Most comments from 2.5.4 apply here. Please reference comments from B.2.5.4	AUWG: Please see responses to: MS51, MS52, MS53, and MS54. [APPROVED http://lists.w3.org/Archives/Public/w3c-wai-au/2011AprJun/0045.html]
		IBM57: B.2.5.9 For content such clip art it may be inaccessible. The author should be able to provide the alt text to make it accessible. So, the source template may not comply but it could be fixed. I don't know that you would have to always require that the template be WCAG 2.0 compliant to start.	AUWG: At AAA a template should include Alt in clip art it uses.[APPROVED http://lists.w3.org/Archives/Public/w3c-wai-au/2011AprJun/0045.html]
B.3.1 Ensure that accessible authoring actions are given prominence.	B.3.1.3 Accessible Options Prominent (WCAG Level AAA): If authors are provided with a choice of authoring actions for achieving the same authoring outcome (e.g., styling text), then options that will result in web content conforming to WCAG 2.0 Level AAA are at least as prominent as options that will not.
B.3.3 Ensure that features of the authoring tool supporting the production of accessible content are documented.	B.3.3.2 Accessible Authoring Tutorial: A tutorial on an accessible authoring process that is specific to the authoring tool is provided.	GL20. MEDIUM: Identify accessibility features in documentation. B.3.3 requires that features that support the production of accessible content be documented, but I would suggest adding (either as a best practice or as a new SC) that the user should be able to find a list or index of such features. This would be equivalent to UAAG 2.0's "5.3.4 Centralized View: There is a centralized view of all features of the user agent that benefit accessibility, in a dedicated section of the documentation. (Level AA)" However, in ATAG this should apply to both accessible content support features and to features that make the tool's user interface accessible.	AUWG: We have added a requirement for an index of documentation at AAA. Proposal: "B.3.2.3 Instruction Index: The documentation contains an index to the instructions for using the accessible content support features. (AAA)"[APPROVED http://lists.w3.org/Archives/Public/w3c-wai-au/2011AprJun/0045.html]
B.3.4 Ensure that any authoring practices demonstrated in documentation are accessible.	B.3.4.3 Model Accessible Practice (WCAG Level AAA): A range of examples in the documentation (e.g., markup, screen shots of WYSIWYG editing views) demonstrate WCAG 2.0 Level AAA accessible authoring practices.

DRAFT Comment Responses for ATAG 2.0 Last Call WD (8 July 2010)

Commenters:

James Craig (JC):

WAI WCAG-Working Group (WCAGWG):

Jamal Mazrui (JM):

Greg Gay (GG):

Alan Chuter (AC):

WAI User Agent WG (UAWG):

Microsoft (MS):

Greg Lowney (GL):

Oracle Corporation (OC):

IBM (IBM):

Legend:

Comments:

Guidelines and Success Criteria

Level A Success Criteria

Level AA Success Criteria

Level AAA Success Criteria