ATAG 2.0 Last Call Draft (8 July 2010)

@@@: Substantive
@@: May be substantive.
@: Probably not substantive
[addressed]: Addressed by WG.

Comments:

Guidelines and Success Criteria

Level A Success Criteria

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?	@JR: ATAG 2.0 certainly applies to Drupal and other CMS systems. I think this is clear from: " software for generating/managing entire web sites (e.g., content management systems, courseware tools, content aggregators)"
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).	JR: Perhaps we could briefly address user configurable authoring interfaces.
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".	@JR: Agreed.
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."	@JR: I like the suggested clarification.
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.	@JR: In the first example, the author chose to put in the feed, not the authoring tool. In the second the authoring tool makes the change when the author is unavailable so the authoring tool needs to not break accessibility. Maybe we could clarify the wording somewhow. (Suggestion is not a substantive change)
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.	@JR: I think there are still possibilities for gathering info from users in an automated way. An idea I discussed with Greg would be to change the handle on the SCs to "Assist Accessibility Repair" so that readers are less likely to immediately think of "Repair tools".
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 tool 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.	@JR: We are trying to be sensitive to the workflows of enterprise systems. Perhaps we could add a last sentence: "Accessible Content Support Features should be made available to any author role where it would be useful." Not substantive - in Implementing doc.

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.	@JR: We should consider this.
		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.	@JR: A possibility would be to add more text to the Implementing doc explaining how it is important to see auto-generated content and suggestions to users in the context of later accessibility checking. Users will be very annoyed if things done by the tool or suggested by the tool later throw errors. That's a good point that we've tried to work in. Some things that are necessary in a tool like Dreamweaver wouldn't be in a tool that let's you choose a rating-level and write a short text review. We hope we've achieved a good balance (e.g., the wording of B.2.2.1 Check Accessibility (WCAG Level A):)
		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.	@JR: I think we can address why the two parts are in the same document by modifying this part of the Introduction: 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.
		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.	@JR: Agreed. Not substantive.
		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:	@JR: Agreed. It's not actually the case since we have lots of conditionals. Not substantive.
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.	@JR: I think the note covers it, but we could try to be more clear. (change request is not substantive)
		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.	@@JR: Sometimes tools "Save As" some formats and "Export" to others etc. It would be easier for the reader of a conformance claim to know what the Claimant thought they were. (change request may not be substantive)
		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.	@@JR: Personally, I think it is more clear to have to address each SC individually. In addition, I think "automatically satisfied" is more "slippery" because it leads provides less information as to the thinking of the Claimant. (change request is substantive)
		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.	@@@JR: I understand the concern, but the cross-cutting nature of authoring tools makes it very difficult. Not sure how we can handle this. Maybe a separate link from all instances of "conform" to a clarifying note? Maybe expanding the explanatory text in the relevant section "Note on 'accessibility-supported ways of using technologies'"? (change request is likely substantive)
		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.	@JR: I agree it's an issue, but out of scope.
		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.	@@@JR: Needs lots of discussion. (Suggestion is a substantive change)
		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.	@@ JR: Conformance claims are optional.
		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	@@JR: Could be moved to a note.
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:	@@JR: Need to discuss. The WG felt that changing the phrase+notes structure of WCAG's definitions to sentences was more clear. Maybe we should put in a general note that we didn't intend to change the sense of definitions unless noted (and then note the exceptions).
		WCAGWG7: assistive technology...	@JR: I think I'm ok with this. Needs discussion.
		WCAGWG8: programmatically determined...	@JR: I think I'm ok with this. Needs discussion.
		WCAGWG9: non-text content ...	@JR: I think I'm ok with this. Needs discussion.
		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."	@@JR: I agree that DOMs should be mentioned as a possible implementation in the definition and Implementing guide. Not Substantive.
		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.	@@JR: As a W3C recommendation I think we should stick to Web content. It would be fairly easy to apply ATAG 2.0 to Word processor docs if one wished too. Maybe Substantive.
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. AC agreed	@JR: Maybe "()" instead? Although it contributes to wordiness, I support keeping the " the authoring tool user interface" clause in the guidelines (perhaps using "()") to keep it as clear as possible what part of the document the reader is in.
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.	@@JR: Obviously it's not a "number" issue. If we say "At least one" it would be testable and we could back it with more explanation. (change request is substantive, my suggestion would not be)
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".	@JR: Ah yes...it's a view for editing, not someone editing the view. I'm ok with "editing-view". I'm also ok with the suggested re-wording. (not substantive change)
		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.	@JR: Following UAWG comments, perhaps: "Recognized alternative content is available when rendering content in editing-views." (Suggestion is not a substantive change)
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.	@@@JR: (change request is substantive)
		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.	@JR: Perhaps: If an editing-view modifies the presentation of web content to provide additional information to authors, then that additional information can be programmatically determined. (Suggestion is not a substantive change)
		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".	@@@JR: Needs WG discussion. Substantive.
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.	@@JR: I agree that "(including WYSIWYG views)" might be confusing (and could be removed). Perhaps instead we discuss the situation in the Implementing 2.0 doc. Essentially, WYSIWYG is a bit of a misnomer because the end-user can quite often modify what they get. We just want to say that the author should similarly be able to modify what THEY get as they author the content.
		MS7: A.2.3.1 This criterion should be consolidated to A.3.6. Move A.2.3.1 to A.3.6	@JR: Agreed. (Suggestion is not a substantive change)
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	@@JR: I agree and this probably deserves an example in the Implementing ATAG 2.0 doc.
		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.	@@JR: Even platforms with no physical keyboard have keyboard interfaces. (Suggestion is a substantive change)
		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.	@@JR: Rationale: The ATAG version takes into account that it is not simply the path that might be continuously sampled. A stylus might also continuously sample the force, angle and speed of the input device. (Suggestion may be a substantive change)
		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.	@@JR: We could use the WCAG 2.0 language for (a). The rationale for (b) is that the content being rendered might include keyboard traps. (Suggestion may be a substantive change)
		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.	@@@JR: Agreed. We need to be careful here to think about other authoring UIs, such as forms. Substantive.
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.	@@JR: We're not refuting but rather remaining consistent with WCAG 2.0. Frankly, the number is pretty arbitrary either way. This requires discussion.
		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)?	@JR: Authoring something as part of a exam perhaps.
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.	@@JR: Agree that it needs to visual-only. The requirement is not meant to rule out animated interfaces. A stop button is sufficient. Perhaps it would be more clear to say that animations shouldn't start to render auomatically (e.g., on loading them and then once the user starts the animation, they should be able to stop it). (Suggestion is a substantive change)
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.	@@JR: Something to discuss, but for some users an ordinate number of keystrokes is a very serious barrier. (Suggestion is a substantive change)
		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.	@JR: It already says editing views for Structured web content. If the web content isn't structured it doesn't apply. We could add further clarification. (Suggestion is not a substantive change)
		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.	@@JR: See above.
		MS15: A.3.4.1 & A.3.4.2 What does “make use of” means? Please provide definition.	@ JR: This is clarified in the implementing document. (Suggestion is not a substantive change)
		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.	@@JR: Point taken, but the ways structure can be used is simply too broad to be more specific. I think we wanted to plant the idea with developers and hope that the curb-cut effect encourages more.
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.	@@JR: We had wanted to leave this up to developers - e.g. to embed user agents directly into the authoring tool UI (change request is substantive).
		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.	@@JR: Actually the logic is a bit different...it's 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 concern and so UAAG would apply.
		MS16: A.3.7.1 This criterion is redundant to A.3.1.2. Please remove the criterion.	@ JR: Agreed. Perhaps with a note in A.3.1.2 mentionning preview. (Suggestion is not a substantive change - since the normative requirement stays the same)
		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.	@@JR: We need a term that distinguishes "user agents" in the marketplace from something developed from scratch. (Suggestion is not a substantive change)
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.	@JR: One is sufficient, we can work it in. (Suggestion is not a substantive change)
		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.”	@JR: Ok to keeping reversible but dropping "undo" by name. (Suggestion may be a substantive change)
		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.	@JR: Needs discussion. (Suggestion is a substantive change)
		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.	@JR: The existing defintion seems ok and 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., setting preferences, viewing documentation)." (Suggestion is not a substantive change)
		MS22: A.4.1.1 What is the definition of “committing action”? Please add definition	@ JR: We mention save and publish. Of course certain systems like Wikis keep previous content past "committing actions". Perhaps we just say "Save". (Suggestion is not a substantive change)
		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).	@@@JR: It's a good practice, but then how tall of a stack? 2, 10, more? Would be substantive.
		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.	@JR: Maybe we can address this in the Implementing doc.
		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.)	@@JR: Maybe we add "immediately reversible without affecting any other settings"?
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.	@JR: Agree with adding note. (change request is not substantive).
		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."	@JR: This is covered in Part A Applicability Note#4, but other commenters have also noted this, so a Note makes sense. Not Substantive.
		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).	@JR: Agreed. I suggest: A.4.2.1 Document Accessibility Features: All features that must be present to meet Part A of this document (e.g. keyboard shortcuts, text search, etc.) are documented. (Level A)
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.	@JR: Wording is meant to be general...the more specific details are dealt with later.
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."	@@JR: Need to discuss: Accessible to whom? The author or the user? (change request may be substantive).
		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.	@@@JR: It already says "web content transformation cannot preserve recognized accessibility information". If that info is lost, an accessiblity problem is already present. Maybe we make it even more clear and say where "accessibility information is not included" in the output. (Suggestion is a substantive change)
		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.	@@@JR: That would be nice, but may be unrealistic. E.g., when converting vector info to bitmap and back there simply is nowhere for the accessibility info to go. Maybe an OPTION to create a backup copy in the original format should be the only requirement. Would be substantive.
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.	@JR: That B.2.1 reference is outdated and should be removed (change request not substantive).
		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.	@@JR: Maybe we should move the "prior to publishing to a note" explaining when it does make sense. (Suggestion is not a substantive change)
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.	@JR: We should do a better job of tying in WCAG 2.0 there (change request not substantive since that's in our definition of "web content, accessible")
		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	@@ JR: This SC says nothing about accessibility of 3rd party technology. It just asks if there are accessibility supports (e.g., ability to add alt, checking, etc.) in the authoring tool in question for that format. (Suggestion is a substantive change)
		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	@@JR: This needs discussion. The intent is not to have the accessibility properties off by themselves (or with some obscure properties) where the author won't find them. (Suggestion is a substantive change)
		MS25: B.2.1.2 “Accessibility-related properties” is undefined. Please define.	@@JR: Needs discussion. (Suggestion is not a substantive change)
		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.”	@@JR: Agreed. The intent here is for the content that can be edited by the authoring tool to be used as a wrapper for that which can't. (Suggestion may be a substantive change)
		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...")	@@JR: We wanted to steer away from saying there are "accessible" and "inaccessible" formats to emphasizing what THE TOOL IN QUESTION does to support accessible authoring in the format.
		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?	@JR: I think this is sufficiently covered by: 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).
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	@@JR: I can see dropping "in a manner appropriate to the workflow of the authoring tool". (Suggestion may be a substantive change)
		MS28: B.2.2.2 What happens when there is no defined workflow? Revise SC B.2.2.2	@@JR: See above.
		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	@@@ JR: We should directly address live authoring (where the first submit to the authoring tool also make it live). BTW: Online banking doesn't tend to author content for other people to consume so it's not an authoring tool by ATAG's definition. (Suggestion is a substantive change)
		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.	@@@ JR: In my opinion this is necessary at Level A. (Suggestion is a substantive change)
		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.	@@@JR: 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. (Suggestion is a substantive change)
		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.	@@@JR: Need to clarify, that for certain types of problems, the best help in locating that a tool can provide is instructions. (Suggestion is a substantive change)
		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.)	@JR: The intention is to require some kind of checking, even if it is manual, in hope that usability concerns will kick in and encourage developers to automate the tasks they can for their users.
		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?	@JR: Maybe we should state that the decision support is part of the check (whether semi-automated or manual).
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."	@JR: Agreed - typo (change request not substantive).
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 value that is 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.	@@JR: The point is that all authors need to be able to edit alternative content. (change request may be substantive).
		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...."	@JR: It is meant to be optional. Maybe needs more explanation as to why in the "Implementing" doc.
		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.	@JR: ATAG2 is not requiring it. In fact, it's meant to address the opposite problem - over-enthusiastic automated suggestions.
		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..	@@JR: Only if that type of accessibility information is editable using the tool. (Suggestion may be a substantive change)
		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	@@@ JR: . (Suggestion is a substantive change)
		MS35: B.2.4.2 “Relevant sources” need testable definition. Please add definition.	@@ JR: "Relevant sources" is just the handle. The text is : "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)." (Suggestion may be a substantive change)
		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.	@@@JR: Agreed. Substantive.
		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.	@JR: Agreed. Not substantive.
		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).	@JR: This is intended to be addressed by the phrasing "text value". We should make it more clear in the Implementing doc. @ Typo alert: "text value that is"=text values that are.
		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).	@@JR: Agreed.
		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).	@JR: Agreed.
		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.)	@JR: That's why we put this in: (a) Author Control: Authors have the opportunity to accept, modify, or reject the suggested alternative content prior to insertion; and
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.	@JR: That's in B.2.5.4.
		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?	@@JR: We're not saying that every template needs to be accessible. But rather, that at least some of the templates need to be accessible (a common sense definition of range is probably >1). Re: Accessible to whom...since this is Part B, B.2.5.2 relates to the production of accessible content for end-users BUT at the top of Part B is this normative note: "Features for meeting Part B must be accessible:..." so it is covered. I think we do need to clarify that we are talking about developer-provided templates, not user-submitted ones over which developers don't have control.
		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.	@@@JR: Discussion needed. (Suggestion is a substantive change)
		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.	@JR: Agreed.
		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?	@@JR: Not perfect, but yes. Maybe at AAA we should require all templates to be accessible.
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).	@JR: Agreed.
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.	@JR: Hard to control bad UI design. But if they start off they may NEVER get turned on. I suggest adding more Implementing guidance on this point instead. (change request may be substantive)
		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.”	@@JR: ok (Suggestion may be a substantive change)
		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.	@JR: ok (Suggestion is not a substantive change)
		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).	@@@JR: Agreed. Substantive.
		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...	@JR: Agreed.
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.	@JR: The idea is that they don't need to be clearly identified - they are simply worked into the routine documentation. (change request is substantive)
		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.	@@@JR: While I can see the point, I think it might be too prescriptive.
		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.	@@JR: I suppose "most" would be 50%+1?

Level AA Success Criteria

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.	@@@ JR: Rationale: The Implementing ATAG 2.0 document gives this example for a web-based tool: "In a web-based environment: A web-based CMS uses links to allow authors to skip between the toolbars and directly to the content editing area." (Suggestion is a substantive change)
		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.	@@@ JR: It is not practical to dictate the exact number or nature of keyboard shortcuts so yes, 2 shortcuts would pass. But as keyboard shortcuts are an important accessibility feature the WG deemed it important to keep the concept in the document. (Suggestion is a substantive change)
		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".	@@JR: Point taken, but the combinations of functions and keys available is too large to be more specific. I think we wanted to plant the idea with developers and hope that the curb-cut effect encourages more.
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."	@JR: Agreed. (change request is not substantive)
		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.	@JR: 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 claim conformance, I would identify the browser I tested with in (8) Platform. (Suggestion is not a substantive change)
		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)"	@@@JR: I like alert on no match, but for the other, it seems to assume the UI renders the content. Showing the results in a list for example would be fine. Substantive.
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.	@@JR: I suppose we could roll together the display and control settings into "setting that affect accessibility". But I'm wary of such broad language since almost anything can affect accessibility in some way. Also we use "Display Settings" by itself for " A.2.3.1 Independence of Display:". I think we sufficiently cover the API support in: 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. (Level A) [Implementing A.1.2.1]
		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.	@@JR: A.3.6.1 applies to more than just keystrokes. e.g., that I had set my default editing zoom to 150%. (Suggestion is a substantive change)
		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.	@JR: Agreed. (Suggestion is not a substantive change)
		MS44: A.3.6.2 Please define “respects” or use more precise language. Please define “respects” or use more precise language	@@JR: Wording needs discussion. (Suggestion is not a substantive change)
		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.	@@@JR: Previews already have an exception in the Part A Applicability notes #4, but perhaps this can be made more clear. Maybe we could say "respect the system settings as a default"? Substantive.
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.	@@@JR: I prefer exempting Undo. Substantive.
		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.	@JR: Agreed.
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	@@JR: We mean features the user can use. The second point needs discussion. (Suggestion is a substantive change)
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.	?
		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.	@@JR: Need to discuss. (change request may be substantive).
		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"	@@JR: Need to discuss. (change request may be substantive).
		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	@@@JR: Agreed. (Suggestion is a substantive change)
		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?	@@JR: It's not about structure it's about when accessibility information is lost. Good point about copy-paste. The tool that drops the accessibility information should inform the user. (Suggestion may be a substantive change)
		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.	@JR: Examples? (Suggestion is not a substantive change)
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):	?
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.	@@@ JR: WG decided AA. (Suggestion is a substantive change)
		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?	@@JR: Point taken, but at some point we can't control bad UI.
		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.	@@@JR: Maybe "programmatically" associated, which could be either internal or external.
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.”	@@JR: ok to removing "for future reuse" (Suggestion is a substantive change)
		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.	@@@JR: Maybe we should reword to look at it from the other side. That we want an automated suggestion system where the suggestions are the authors previous entries for THAT object. Substantive.
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.	@JR: Maybe we can tweak this to be more clear that we need the mechanism (e.g. metadata of some kind) in place, whether or not the user has used it for any particular piece of pre-authored content.
		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).	@@JR: It's not perfect, but in my opinion trying to dictate the order within a container is a non-starter because the order is dependent on so many factors. E.g., if I'm not mistaken, "accessible" is something like "zugänglich" in German, so in an alphabetical list templates labelled as accessible would be sorted to the bottom.
		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	@@ JR: Could preface with, if there are (or could be in the case of user-submitted templates) accessibility differences... (Suggestion is a substantive change)
		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.	@@JR: In my opinion it would be ok to just in the mechanism that the template had been checked for accessibility. I don't want to attempt to specify an implementation, but perhaps the template could have a "passed automated accessibility checker" field in its metadata. (Suggestion may be a substantive change)
		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.	@@@JR: Discussion needed. (Suggestion is a substantive change)
		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.	@@@JR: See above.
		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.	@@JR: The SC is conditional on that point.
		MS56: B.2.5.6 All comments from 2.5.4 apply equally. Please reference comments from B.2.5.4	JR: See above.
		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.	@JR: Agreed
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.	@@@JR: Need to discuss. (change request is substantive)
		MS57: B.3.2.4 “Comparable” is not testable. Please revise SC.	@@JR: Maybe just "other features" instead of "comparable features" (Suggestion may be a substantive change)
		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.	@@ content problems” with something more precise. JR: Perhaps reword as: "Accessible content support features are at least as prominent as other features for addressing other issues in web content (e.g., invalid markup, syntax errors, spelling and grammar errors). (Suggestion may be a substantive change)
		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.	@JR: Right, but only IF the UI is modifiable. Not substantive.
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	@@ JR: Yes 2 or more. (Suggestion is a substantive change)

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)	JR: I agree that the scopes are different. The "editable" part was intentional to help bound the requirement. It should be added back in to the SC. Substantive.
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.)	@JR: Agreed. (change request is not substantive)
		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.	@JR: Agreed.
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.
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)	@JR: Agreed
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.	@JR: It definitely makes sense to clarify the distinction between what the developer provides and what is submitted by other users.
		MS60: B.2.5.7 Most comments from 2.5.4 apply here. Please reference comments from B.2.5.4	JR: See above.
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.	@@@JR: I feel like this may be too prescriptive. e.g. it would rule out a very well implemented context sensitive system. Substantive.
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.

ATAG 2.0 Last Call Draft (8 July 2010) - Comments

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):

Legend:

Comments:

Guidelines and Success Criteria

Level A Success Criteria

Level AA Success Criteria

Level AAA Success Criteria