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

OC1: Oracle Corporation thanks you for the opportunity to respond to the Authoring Tools Accessibility Guidelines working draft dated 08 July 2010. We appreciate that a lot of effort has gone into this draft, but feel that in some areas additional changes are needed.
> We appreciate the distinction being made in Part A – making the authoring tool itself accessible, versus Part B – making the output of the tool accessible; however, we feel that the Part A information needs finishing. The information in Part A is very good for when the tool is a web-based tool, since that is the expertise of the group. Our area of concern with this is in the situation where the tool is not web-based. An effort was made to address this, but it has been done in a way that has many potential problems. For example, when compared to current and proposed U.S. Section 508 standards for ‘software’, what is currently presented ranges from being a subset of those standards, to possibly presenting standards that might be in conflict.  Our recommendation is for Part A to address only web-based authoring tools (and perhaps just refer to Section 508 for non-web based if you speak to that at all).  Failing that, make all of the non-web-based provisions aspirational or advisory.

@@@JR: Section 508 is U.S. legislation/regulations, so W3C can’t simply refer to it. That said, it makes sense to examine any points of conflict between ATAG 2.0 and Section 508.

• A.1.1.1 Web-Based Accessible (WCAG Level A): Web-based authoring tool user interfaces conform to WCAG 2.0 Level A.

@@@JR: There may be some confusion here. A.1.1 refers to WCAG 2.0, which covers much more than support for assistive technology. A.1.2.1 includes links to information on accessibility APIs but also covers accessibility issues such as keyboard navigation, colors, etc. that are included in the standards or platform conventions.

• 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.

• 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.

@JR: The WG suggests this rewording: “If content is rendered in editing-views, recognized alternative content can be programmatically determined.” [ADDRESSED]

• 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.

@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.” (same proposals as for MS6)

@@@JR: Agreed.

• 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.

• 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).

• 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.

• A.3.3.1 Static View Option: Rendering of time-based content (e.g., animations) in editing views can be turned off.

• 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.

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.

OC6: - A.3.4 – It is not clear to us that exposing content structure necessarily ‘enhances’ or ‘simplifies’ navigation and editing. In fact, many of our authoring tools are specifically designed to shield the author from the underlying structure. We recommend that this guideline be made advisory. 

• 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].

@@@JR: We have considered that in the past, but decided that the point of a Preview is to experience authored content the way it will be experienced in “real-world” user agents. But perhaps a AAA requirement would be to let the author use any user agent they wanted.

OC10: -The Rationale for A.3.7 – Regarding the last sentence “Authors with disabilities need to be able to follow the same workflow”, we feel that this may not necessarily be the case. They need to follow ‘a’ workflow, which is supported, documented, etc. but it may not be the ‘same’ as an author without a disability. Or perhaps a ‘workflow of similar effort’.

@JR: Maybe we take out the word workflow and say: “Authors with disabilities need the same opportunity to check their work.”

@JR: re: 3rd party tools, I agree this should be changed – it was never the intention to disallow a company’s own tools. I think Preview should rule out thumbnails.

• 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.

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

OC12: -A.4.1.1 –By ‘Authoring actions’, is this referring to any action, or only those that are ‘significant’, ‘harmful’, etc.? Is a workflow in the authoring tool that a user must explicitly save an example of ‘undo’? (the author could always choose to not save and open the last-saved file.)

@JR: Any actions. I don’t follow the example.

• 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.

• 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.

• 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.

OC14: In Part B, we have a concern with the use of the term “accessibility information” and wonder if the correct term is really “programmatically determinable.” The term “accessibility information” is too broad and by changing the term it helps to narrow what is being referred to. We are also concerned with the phrase “human judgment” that is used in many places. What are your expectations for this? It seems to be leading to the tool must almost supply artificial intelligence to know what to do. 

@@JR: “programmatically determinable.” Is a property of many things, not just things related to accessibility. E.g. the height and width of images can be programmatically determined. By “human judgement” we always mean decisions by the human author.

• 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.).

@JR: It’s because we wanted to be flexible around the timing of when the tool addresses the issues. For example, it should be ok for tools to let users drag and drop images into a document without immediate accessibility prompting, as long as the issues are queued for author attention before publishing. That said, if it’s a wiki, the act of submitting content to the tool is also the act of publishing, so it’s something we need to look at.

• 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.

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...")

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?

OC18: -B.2.1.1 – The sentence “If the authoring tool provides the option of producing a web content technology for publishing…” We recommend replacing the word “technology” with “format” since the output of the tool isn’t a technology.

OC19: -B.2.1.2 – We feel this should be reworded to “At least one typical method to…” instead of “Mechanisms that…”.

@@@JR: I disagree, “typical” is hard to test.

@@JR: Maybe we should be more clear that we mean a text description or link to alternate accessible version.

• 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.)

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

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: Yes, that’s the minimum requirement. Of course, it wouldn’t be a very usable implementation and hopefully market pressure would move things in the direction of automation.

OC22: -B2.2.3 – The guideline is very broad.  While the two examples are clear (manual & semi-manual checks), it is unclear to us in what other circumstances instructions are to be provided to authors around “deciding whether [a check] is correctly identified”.  We recommend restricting this Level A guideline to only those two situations, or at least to clearly enumerate the other situations.
> Please also clarify if linking to the relevant WCAG2 guidelines would be adequate to meet this guideline for technologies that are covered by WCAG2?

@JR: Perhaps: “Help Authors Decide: When manual or semi-automated checks require authors to make a decision, instructions are provided that describe how to make the decision.”

• 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.

@@JR: A checker without any further information isn’t going to help most people. Perhaps they could be framed as suggestions, like with a spell checker:  “repair assistance is provided” could be: “ repair suggestions are provided.”

• 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).

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

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

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

OC25: -B.2.4.3 – The wording of this item is really difficult to understand. It takes many times through to get an idea of what is being asked for. Recommend rewriting.

@JR: Perhaps: "The authoring tool does not attempt to repair alternative content for non-text content using only text values that are equally available to user agents (e.g., do not use the image filename).”

• 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.

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.

OC27: - B.2.5 Several standards mention a ‘recorded accessibility status’, but no advice is provided on how this is to be measured.

@JR: We should add some advice on this to the Implementing doc.

@@@JR: Agreed – for developer provided templates.

• 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).

OC29: -B.3.1.1 – We suggest that things like lists and tables should be added to the examples since these are challenging situations.

@JR: Agreed.

• 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.

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.1 Instructions: Instructions for using the accessible content support features appear in the documentation.

• 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.

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.

• 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.3 Keyboard Shortcuts: Keyboard shortcuts are provided.

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".

• 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.

OC7: -A.3.5 – It is not clear that this is specifically an accessibility requirement. Furthermore, it is not clear how one could implement this in practice, for example if the target of the search may be rendered in multiple user interfaces including modal dialogs.  Lastly, ‘text that the authoring tool can modify’ is too broad, because some of that text may only be available at ‘runtime’, in which case it would be the responsibility of the user agent to account for this feature. We recommend that this guideline be made advisory. 

@@@JR: While all users benefit, people who have difficulty using the keyboard benefit more. I could see dropping “search all editable” for “include alternative text in search”.

• 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.

• A.4.1.3 Undo is Reversible: Authors can immediately reverse the most recent "undo" action(s).

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.

• A.4.2.2 Document All Features: All features of the authoring tool are documented.

• 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.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.

• 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.).

• 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.)

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: The group decided it was Level AA.

• 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.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.

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: Except that authors may sometimes view accessibility as “extra work” so it’s more important to simplify time-intensive accessibility tasks.

• 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.

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.

• 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.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).

@@JR: Perhaps “comparable prominence”.  It is absolutely difficult to test but I think everyone would agree that a spell checker that underlines words in text has a much higher prominence than a utility that is activated from a third-level menu item.

• 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.

• 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.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.

• 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.4 Content Edits Saved (Extended): The authoring tool can be set to save all content edits made by authors.

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.

• A.3.6.3 Multiple Sets: Authors can save and reload multiple sets of any authoring tool display settings and control settings.
• A.3.6.4 Options Assistance: The authoring tool includes a mechanism to help authors configure any options related to Part A of this document.

OC8: -A.3.6.3 – Regarding loading multiple sets, we question why this is an accessibility issue. We recommend removing it.

• 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.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.).

• 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.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.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.

• 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.2 Accessible Authoring Tutorial: A tutorial on an accessible authoring process that is specific to the authoring tool is provided.

• 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.