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

Oracle Corporation (OC):

IBM (IBM):

Legend:

@@@: Substantive change
@@: May be a substantive change.
@: Probably not a substantive change.
@@propose:no-change@@
[ADDRESSED]: Addressed by WG.

Comments:

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)". See "Applicability after the end of an authoring session""@@propose:no-change@@

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: We will create a new applicability note to address user configurable authoring interfaces. AGREE
IBM12: Applicability Notes: Scope: appears that this applies to all views of the content being edited. But authoring tools support multiple content formats, some of which might not support accessibility. Is this a problem? @JR: We can clarify that this only covers editing-views for the technologies listed in the conformance claim. AGREE
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.[ADDRESSED]
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. [ADDRESSED]
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) [ADDRESSED]

IBM38: Part B: Support the production of accessible content-Applicability Notes, bullet 2: I don't understand this example: "In contrast, for automatically-generated content, Part B continues to apply after the end of the authoring session. For example, if the site-wide templates of a content management system are updated, these would be required to meet the accessibility requirements for automatically-generated content."

 @JR: This has been reworded for clarity. [ADDRESSED]
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: We have removed "repair tools" from this example for clarity. There are still possibilities for gathering info from users in an automated way (i.e., repair tools). [ADDRESSED]
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 tools include multiple author roles, each with different views and content editing permissions (e.g., a content management system may separate the roles of designers, content authors, and quality assurers). In these cases, the Part B success criteria apply to the authoring tool as a whole, not to the view provided to any particular author role. GL15. MEDIUM: Features should be available to all applicable roles. In "Implementing PART B: Support the production of accessible content", "Applicability Notes" it says "5. Multiple author roles: Some authoring tools include multiple author roles, each with different views and content editing permissions (e.g., a content management system may separate the roles of designers, content authors, and quality assurers). In these cases, the Part B success criteria apply to the authoring tool as a whole, not to the view provided to any particular author role." This seems a bit overly broad, as individual features required by ATAG part B should be visible in any mode where they would be useful. As an extreme example, syntax checking should be visible and available to authors and QA, so it should be insufficient to have them available only to system administrators. @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. AGREE

Guidelines and Success Criteria

Level A Success Criteria

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. The complete list would be: AGREE

  • A.1.1.1,2,3
  • B.1.1.1,2,3
  • B.1.2.1,B.1.2.3
  • B.1.3.1,2,3
  • B.2.2.1,5,8
  • B.2.3.1,2,3
  • B.2.5.1,3,9
  • B.3.1.1,2,3
  • B.3.4.1,2,3
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. [ADDRESSED]
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.

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. ACTION JEANNE: We need to follow-up to see what they believe the conflicts are?
OC15: Often part B has an all-or-nothing approach to producing accessible web content where level A is the only level where something can be met. We would suggest that many of these could benefit from an approach where the level A or AA guideline allows a timely, accurate, complete and efficient mechanism to complete a task. A  corresponding level AAA guideline could then be introduced where ALL of the methods to produce content provide the same benefits. @@The WG requires specific comments on levels per success criteria, not in general.
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. @The existing note covers this concern, but we will try to be more clear.
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. @The vendor knows what they are producing (e.g., via "Save As", "Export"). It would be easier for them to include this information than to expect every reader of a conformance claim to deterimine this. @@propose:no-change@@
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. @@We think it is more clear to have to address each SC individually. It is problematic to categorize not applicable SCs as "automatically satisfied" because it provides less information as to the thinking of the Claimant.ACTION revisit
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. @@@Proposal is to switch "conforms to WCAG 2.0 Level A" with "meets the WCAG 2.0 Level A success criteria"
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. @@propose:no-change@@
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. [Addressed]
IBM10: Understanding Levels of Conformance- Note 4 in the definition of authoring tool indicates ATAG 2.0 is not intended to be applicable to simple text editors. Therefore, "text editors" should be removed from the following bullet: "whether it is possible to satisfy the success criterion for all types of authoring tools that the success criteria would apply to (e.g., text editors, WYSIWYG editors, content management systems, etc.)" @JR: We should be more clear about the difference between a text editor UI and being a simple text editor.
IBM11: In this sentence defined "proportionally greater" as this is vague: In other words, the user interface issue must cause a proportionately greater problem for authors with disabilities than it causes authors without disabilities and must be specific to authoring tool software, as opposed to software in general. @@JR: Needs discussion
IBM58: Conditions on Conformance Claims- bullet 4: BLOCKING ISSUE: we raised an issue last time about anybody being able to make a claim even for stuff they don't own. What if a government enacts procurement regulations requiring ATAG compliance, we provide a compliance statement on one of our products that differs from what a journalist somewhere publishes about our product? The journalist might falsely claim that our product is compliant. Would the customer then hold us liable? Or conversely, we may be claiming compliance due to some particular situation about how the product is going to be used by this customer but the journalist claims it is not compliant. We might lose the sale. @@@JR: I'd be ok recommending that only developers make claims, because they have more complete information. But I think this should be informative because of (a) open source development communities, (b) the ability to bundle software means one developer might make a claim that includes a bundled third party software.
IBM59: Comment "It seems weird to me that anyone can make a claim. Of course you can't prevent it but odd that the W3C would endorse it. If it stays in there, then we need to insist that the claim has to include information about who is making the claim. We don't want to be held liable for a claim that someone else might make about our products." The claimant's name has now been added but I still don't like it. JR: See comment on IBM58
IBM60: bullet 5 seems especially problematic for us where we have bundled third party components that are not licensed to the customer by IBM: "Claimants are solely responsible for the accuracy of their claims (including claims that include products for which they are not responsible) and keeping claims up to date." @@@JR: This was put in to protect developers from other developers bundling their products.
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: We suggest that you use the WCAG definition with an additional note about authoring tools providing direct accessibility features. @JR: I think I'm ok with this. Needs discussion.
WCAGWG8: programmatically determined: We suggest that you use the WCAG definition and include your second sentence as a Note. @See GL1
WCAGWG9: non-text content: We believe that it is critical that your definition include the phrase "can be programmatically determined". @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. @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 applications creating only word processor documents if one wished too.
IBM1: Authoring tool- the numbered items look like "notes" which further explain the definition. They should be labeled Note 1, Note 2, etc.
 @OK
IBM2: Authoring tool- The examples include debugging tools for web content". I don't understand how debugging tools can be considered an authoring tool. @OK to remove that example.
IBM3: Authoring tool- authoring tools it includes email clients. If an email client supports accessible web content authoring do we know that the mail format preserves the accessibility information that would be prompted for in an email authoring tool? Such as:alt text, ARIA semantics, table structure, keyboard navigation.This applies to other document formats.
 @JR: Plain email is an unstructured format, which ATAG accounts for. But HTML email certainly is structured. Note in the authoring defn that tools might also do other things (e.g. edit content that iusn't Web content e.g. plain text files, plain text emails, etc.)
IBM4: Authoring tool- Reference to blogs, Wikis, and content management systems. Most blogs, wikis do not currently support ATAG 2.0 . It is important to state how they can comply with ATAG checkpoints, and this may require s browser plug-in. Therefore, a browser plug-in must be an acceptable authoring tool component.
 @Right. A browser plug-in must be an acceptable authoring tool component.AGREED
IBM5: Authoring tool- Web content management systems use Java-based content editors to test content for WCAG compliance. Standard Java HTML editors only support HTML 3.2. So, somewhere there needs to be a statement to ensure that authoring tools accessibility analysis can fully support the host language.
 @We don't undertand the concern.
IBM6: view
- The numbered items in this definition look like additional terms. In fact, there are links from the document to the terms in the numbered list yet they don't make sense unless you read the parent definition. For example, Guideline A.2.2 rationale links to the term "editing view" but the bullet "editing views are editable" is not a sufficient definition to understand what the term means in the context in which it is used. Creating separate terms in the glossary with definitions that stand alone and also reference the more general term would be a better approach.		 @We will break up the definitions into single terms.
IBM7: programmatically determined (programmatically determinable) - (Blocking issue) do not agree with the definition of programmatically determined. It is inadequate and should not be limited to "platform accessibility architecture." Platform accessibility architecture is also inconsistent with the U.S. 508 refresh. Do not want to mislead people to thing that only what is available in the platform accessibility architecture can be used. Definition must refer to platform accessibility services and platform accessibility services to be any recognized accessibility services layer supported by assistive technologies that support full interoperability with web content technology capable of supporting WCAG 2. @See GL1
IBM8: programmatically determined - 508 refresh refers to platform accessibility services. Platform accessibility services should include MSAA and IAccessible2 together. Both are referred to in the ARIA and HTML 5 API mapping documents. There is no issue exposing access to a DOM as part of being programmatically determined. The DOM does not have to be a W3C DOM. However, the definition of platform accessibility architecture refers to a single document object and not a document object model. In IE ATs access information from a W3C DOM API and another DOM API that provides things like gaining access to the computed style of a document object within that model. So, these definitions do not adequately address what ATs need or are using to gain access to information. @See GL1
IBM9: programmatically determined- CSS styling for final format is accessed through non W3C DOMs. IE
actually has two DOMs (one w3c and another of their own design). The one of their own design has a getComputedStyle method on DOM elements. When solutions use none standard (publicly recognized accessibility services) that are needed to meet this requirement they should be documented. Reason: an authoring tool needs to be able to prove that they can actually meet ATAG. I don't see that here.		 @See GL1
A.1.1 [For the authoring tool user interface] Ensure that web-based functionality is accessible. 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. @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. [Addressed]
OC2: -A.1.1 – We recommend renaming this to “Ensure web-based functionality supports use by assistive technologies” since the information in the line “Implementing A.1.1” is about accessibility APIs..  Additionally, if one meets a broad guideline requiring that ‘functionality is accessible’ then one can reasonably infer that all subsequent guidelines would also be met.  As such, it creates a tension similar to the Functional Performance Criteria and Technical Standards present in U.S. Section 508, which should be avoided. 

@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.AGREED.
IBM13: A.1.1 and A.1.2 refers to Web-based and non web-based authoring tools. Web-based is not clearly defined. When stating web-based do you mean W3C document standards or do you mean that to include any web delivered standard such as Flash, Flex, Silverlight, etc.? @Yes - Flash, Flex, Silverlight are Web-based technologies. AGREED. ACTION JEANNE: Add Flex and Silverlight to the examples in Web Content Technologies.
IBM14: A.1.1 Web-based functionality: For web-based UIs, some of the subsequent requirements modify WCAG 2.0 requirements. Has the work been done to determine if it is even possible to comply with A.1.1 (comply with WCAG) AND comply with all of the subsequent requirements that are tweaks on WCAG 2.0 requirements? If the rationale is that these things are needed for non-web-based functionality, then the provision should be scoped to non-web-based functionality. For example, why is A.3.2.2 needed for web-based content when it also has to comply with WCAG 2.0 via A.1.1? @@@JR: The only one I can think of is the drawing requirement, which is actually a bit less stringent than WCAG 2.0. Ask which are tweaks?
IBM15: A.1.1 and A.1.2 refer to web content but they don't state that the web content be supported by at least one user agent to be consistent with UAAG 2. If you don't have this stipulation then the user will be unable to use the web content. Somewhere in ATAG this does need to be stipulated. @If this refers to WCAG 2.0' "Accessibility Suppport" concept, this is explained in the conformance section. Also, ATAG 2.0 does not attempt to grade web content formats.AGREED
A.1.2 [For the authoring tool user interface] Ensure that non-web-based functionality is accessible. 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. 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) [ADDRESSED]
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) [ADDRESSED]
OC3: -A.2.1.1 – We find the guideline to be generally confusing. The word ‘provided’ in the guideline also complicates it, since it may be interpreted to mean that the tool must supply the text, perhaps as a default value. Was the intent that the tool ‘expose’ current content? We recommend this item should be removed or made non-normative.

@JR: The WG suggests this rewording: “If content is rendered in editing-views, recognized alternative content can be programmatically determined.” [ADDRESSED]
A.2.2 [For the authoring tool user interface] Editing view presentation can be programmatically determined. WCAGWG11: A.2.2.2: Consider adding background color to the list of minimum presentation properties for text.

@@@JR: (change request is substantive)

  • background color
  • highlighting color
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. @@Needs formal defintion for "Additional Information". AGREED.
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.
OC4: - A.2.2.1 - As currently worded, it is not clear whether it is the visual (or otherwise) representation of the additional information, or the semantic meaning of the additional content, that must be programmatically determinable.

@See MS6

OC5: -A.2.2.2 – The minimum list is incomplete; for example, it should also include text-background color or text highlighting color. Also, the Implementing information refers to non-web based information and should be removed.

@@@JR: Agreed.
IBM16: A.2.2 Rationale: an example of "information about the end user experience of the web content being edited" would be helpful @See MS6
IBM17: A.2.2.1. doesn’t appear the vehicle for doing this is fully addressed. For example, when authoring a mashup what vehicles are stipulated to determine when alternative content is available to meet a specific user’s needs and how are users needs conveyed through the authoring tool. Example: a google map has a linear text-based driving direction alternative. Today, web content mashups do not do this. A standard meant to address this is the IMS Access For All Specifications. Concerned with the definition of Programmatically Determined. @JR: Not sure I understand the example.
IBM18: A.2.2.2 Access to text presentation: The use of the word "and" in the sub-bullets is unnecessary as the provision wording is clear that if any of these presentation characteristics are supported, they must be programmatically exposed. @This is the WCAG2.0 style AGREED
IBM19: A.2.2.2 We are concerned about the definition of Programmatically Determined. Programmatically Determined Definition - a blocking issue The document must support platform accessibility services and that needs to be re-defined. This problem is pervasive throughout the spec and implementation guidance.
 @@@See Glossary section.
A.2.3: Ensure the independence of the authors' display preferences. 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.[Addressed]
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)[Addressed]
IBM20: A.2.3.1: Since A.3.6.2 requires respecting the platform display settings, it seems to override any other way of allowing authors to set their display settings. So A.2.3.1 seems to be reduced to a requirement that the tool respect the platform display settings without affecting the Web content to be published. Seems like this could be simplified by just rolling the "independence" requirement in A.2.3.1 into the "platform settings" requirement in A.3.6.2. At a minimum, A.2.3.1 should reference A.3.6.2 as A.3.6.2 currently references A.2.3.1. @The two requirements are now together in the same Guideline, but ehy have different levels and address different issues.AGREED
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

@This is addressed in the defintion of "Keyboard Interface" (which is intentionally different than keyboard) which comes from WCAG 2.0. AGREED

 
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. @See JC2
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. @@@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.
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.
IBM21: A.3.1.2 No keyboard traps a) requires a keyboard way to exit all content that can be entered
using the keyboard. Is this always possible for authoring tools? For example, say you have an authoring tool that allows the addition of third party UI widgets. If you drag insert one of those widgets into the content you are editing and move keyboard focus to it, who now owns the keyboard focus? The widget or the authoring tool? If it's the widget, then how does the authoring tool guarantee that you can exit the widget with the keyboard?		 @We will have an applicability note that exempts UIs when the user has modified that UI. AGREED
IBM22: A.3.1.2 No keyboard traps b) requires a documented keyboard command that will always restore keyboard focus to a known location which seems like a good requirement, however, the example of "menus" doesn't seem to accomplish the goal. If your keyboard focus is trapped and you move it to the menus then back to the document, it should go back to where it was before you put it on the menus. So it would still be trapped. Suggest that the requirement be to have a keyboard command that moves focus to a known location within the content being edited. @See GL3 AGREED
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. @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)? @Authoring something as part of a exam perhaps. @@propose:no-change@@AGREED
IBM25: A.3.2.1 Data saved: What does "submitted content edits" mean in a non-web-based authoring tool? @That language should be moved to clarifying guidance.AGREED
IBM26: A.3.2 What happens if the authoring tool give the author the ability for the author to set the refresh rate of the page? This is something the author has set. Does this require warnings to the author when during a test run the time is about to expire?
 @We will have an applicability note that exempts UIs when the user has modified that UI. AGREED
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. @@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) AGREE
A.3.4 [For the authoring tool user interface] Enhance navigation and editing via content 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 inordinate 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.

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. 

@@JR: There will always be a tension in some UIs between shielding authors from unnecessary technical details and allowing them to make use of those details if they wish. WG needs to discuss.
IBM27: A.3.4 Need to improve the definition of structured web content. " Structured web content is content that includes machine-readable internal structure (e.g., markup elements), as opposed to unstructured content, such as raster image formats or plain human language text."  
IBM28: Not all markup elements are structural. A button is not a structural element. Structural elements are those that define structure for other content elements: landmarks, tables, headings, listboxes, lists, tree widgets, etc. Structural elements provide context in a defined layout or order. An example would be a containment model.  
IBM29: A.3.4.1 seems pretty subjective to be a Level A requirement. Looking at the "implementing" guidance to understand this better, I would not agree with the table "element" example, at least not for a source code view. If you select a table "element" in a WYSIWYG view, the entire table would be selected so "delete" should delete the entire table. But in a source code view, I don't agree that if you delete the table element you should delete all of the children of that element. The tool might highlight the error somehow but I don't think tools should be making decisions to delete more than the author deletes in a source code view. The example should be changed and this requirement should be moved to AAA because of the subjective nature of it.  
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. @We had wanted to leave this up to developers - e.g. to embed user agents directly into the authoring tool UI AGREED.
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. @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. AGREED.
MS16: A.3.7.1 This criterion is redundant to A.3.1.2. Please remove the criterion. @ Agreed. Perhaps with a note in A.3.1.2 mentionning preview. ACTION: Remove and note.
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)
OC9: -A.3.7 – We wonder if there should be a Level AAA requirement that the preview be accessible.

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

ACTION: "Publically available" +DEFINE

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.”
OC11: -A.3.7.2 – As written, there is no requirement that the 3rd party user agent conform to UAAG. Was that the intention? It is also unusual that a company would not be allowed to use their own user agent. Lastly, for clarity, the definition of ‘preview’ should discuss renderings such as thumbnails.

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

IBM34: A.3.7.1 You need a provision for gestures. I.E. devices that support only gestures should provide a discrete gesture that does this. That gesture should be operable by devices that support people with mobility impairments. Also, you are referring to UAAG 1.0. This document is so dependent on UAAG that I think UAAG 2.0 and ATAG 2.0 need to come to last call together. UAAG 1.0 is 8 years old.  
IBM35: A.3.7.2 Preview" why does sub-clause a require "third party" user agent? Does this mean that Microsoft authoring tools have to use Firefox, Opera, or Safari instead of IE in their preview mode?  
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. @One is sufficient. AGREED. Could add a higher level req. for more.
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.” @Ok to keeping reversible but dropping "undo" by name. AGREED
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:We will clarify that Save and Publish are not considered "Authoring Actions" exception. AGREED
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. @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)." ACTION: Add Saving. AGREED.
MS22: A.4.1.1 What is the definition of “committing action”? Please add definition @ See MS21
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). @ ACTION JEANNE: See what UAAG says.
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. @We can address this in the Implementing doc. AGREED.

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

 @@@Maybe we add "immediately reversible without affecting any other settings"?

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

@Authoring actions is defined. The example would not meet this, because it would undo lots of authoring actions.

IBM36: A.4.1 Do you have a limit to the number of Undos the author needs to support? One undo is not very helpful. @See MS18
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). [Addressed]
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. [Addressed]
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) AGREED
OC13: -A.4.2.1 – Regarding documenting “all features” we feel this is too broad. This is a requirement for all users, not just people with disabilities so we feel it isn’t applicable to ATAG. Even with narrowing to “all ‘accessibility-related’ features” this could still be very broad. For example, why would features that are programmatically determinable, such as keyboard shortcuts, need to be ‘documented’? @JR: We believe this should remain unchanged.
B.1.1 Support web content technologies that enable the creation of content that is accessible. 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. @@propose:no-change@@
B.1.2 Ensure that the authoring tool preserves accessibility information. 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.

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.
OC16: -B.1.2.2 – Regarding entry “b”, the loss of recognized accessibility information does not necessarily result in accessibility problems. We suggest rephrasing as “authors are warned that due to the transformation there could be accessibility problems in the output.” @@ JR: OK
IBM39: B.1.2.1 and B.1.2.3: the parenthetical (WCAG 2.0 Level A) and (up to WCAG 2.0 Level AAA) are critical to the provisions and should not be in parentheticals.  
IBM40: B.1.2.2 This is too blind user focused and is an unrealistic request. A comment will not be seen by a sighted user. If you make it visible (to all users then it impacts the output negatively). I don't think this is a valid requirement to be included. It is too weak and the right solution would be to get the document author that owns the target to try to expand their accessibility support. Most authoring tools today don't try to stuff un-renderable content in the exported file format. This is also fraught with problems. Let's say there is a describedby relationship to non-visible content used for help information and the target system does not have a means to reference it. If you put the comment in the targeted export a screen reader may not know what it is associated with. This would in essence be orphaned content in the exported document format.  
IBM42: B.1.2.2 and B.1.2.4: the sub-bullets don't need the word "or" at the end as it is clear from the parent provision that only one of these is required.  
B.1.3 Ensure that automatically generated content is accessible. 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). [Addressed]
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)
OC17: -B.1.3 – What is the significance of “prior to publishing” in each guideline?

@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.
IBM44: B.1.3 The Rationale: is not a complete sentence. (must impose, should impose, etc.) This section refers to repair tasks but does not really address what the repair tasks are other than to say that the generated content must be compliant. Seems confusing.  
IBM45: B.1.3.1: needs to be clarified that the tool must provide a mode of operation that complies with this requirement. It should be allowed to be turned off and it should not be required to be the default at Level A. Requiring it by default would be okay at Level AAA.  
IBM46: B.1.3: unclear what "prior to publishing" means. What if I'm using Microsoft Word to create a document, then I save it as HTML. That's not publishing. It's not "published" until I upload it to my website. Does this requirement only apply to tools that include publishing? Or would it mean that if I use one tool that generates automatic content but doesn't publish and then FTP to upload files to my website, my "set" of authoring tools is non-compliant with ATAG? Per the definition, ATAG applies to all of the tools used in the process.
  
B.2.1 Guide authors to create accessible 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) @@propose:no-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).

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.

 @JR: The definition of Technology encompasses format. The term was worked out with WCAG-WG and UAWG so I’d prefer not to change it.

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.
OC20: -B.2.1.3 –The text as written can work in some situations such as if you import a picture and add alt text to it, but this item doesn’t work more broadly without becoming confusing. It really depends on the technology in question. An example is OLE-style situations or importing a movie that isn’t accessible. No matter what the tool does, it can’t make the movie accessible, it can only describe what is broken about it.  It comes down to one tool cannot modify the content of another tool. We do not have proposed text for how to correct this item, but wanted to raise the concern.

@@JR: Maybe we should be more clear that we mean a text description or link to alternate accessible version.
IBM47: B.2.1.1 Showing a warning every time seems intrusive to the author. This is like Vista's constantly asking you if you want to do something. Should this just be documented in the product? Also, I am a bit surprised by the fact that the definition of Web Content Technology does not include things like Silverlight or Flash given that WCAG 2 applies to anything delivered over the web. It seems like the W3C is not being consistent here.  
IBM48: Also, I am a bit surprised by the fact that the definition of Web Content Technology does not include things like Silverlight or Flash given that WCAG 2 applies to anything delivered over the web. W3C needs to be consistent.  
IBM49: B.2.1.2 This is very good but it needs to be synched with the definition of accessibility information otherwise there will be inconsistencies. I would also point out that both ARIA and HTML 5 refer to well formed content such as Grid must have a row and a row must have a gridcell. Shouldn't authoring tools deal with supporting accurate structural information?  
B.2.2 Assist authors in checking for accessibility problems. 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).
OC21: -B.2.2.1 – We are a bit confused by the meaning of this entry - it seems to read overly broad. Can the criteria of “provide checks” be met by just documenting how each standard could be manually checked?

@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.”
IBM50: B.2.2.1: I think "manual checking" is the wrong term here. The authoring tool is not doing the manual check but rather providing guidance to the author in performing the manual check. The "checking" should only be required where automated checks can be performed.  
IBM51: B.2.2 this should be a configurable item achieved through the use of a plug-in. Also, has the working group considered assisting authors who are creating DHTML content where accessibility changes dynamically during application authoring? This seems to be a gap in that authors may not be aware of.  
IBM52: B.2.2.4 Determining where accessibility issues are can be problematic with dynamically generated content.  
B.2.3 Assist authors in repairing accessibility problems. 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).[Addressed]
OC24: -B.2.3 – Assisting in repair implies prescribing a solution that may not be the only way to do it. There is a concern here that this ultimately could lead to liability, and/or stifling creativity.

@@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 Assist authors with managing alternative content for non-text content. 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). @@propose:no-change@@
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. @@propose:no-change@@
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. [Addressed]
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: ATAG2 is not requiring it. In fact, it's meant to address the opposite problem - over-enthusiastic automated suggestions.[Addressed]
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

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).”
IBM55: B.2.4 Techniques should cover:alt text for graphics, labels for widgets (aria-label, title attribute) and standard input controls, descriptive text as optional (longdesc, aria-describedy, etc.)
  
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. @@propose:no-change@@
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.

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.
OC28: -B.2.5 – We recommend adding a Level AAA where all templates are accessible.

@@@JR: Agreed – for developer provided templates.
IBM56: B.2.5.1 There should be an accessible template alternative for components. Some templates may be from third parties and may be inaccessible.  
B.3.1 Ensure that accessible authoring actions are given prominence.

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.

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 Ensure that features of the authoring tool supporting the production of accessible content are available. 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) [Addressed]
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.
OC30: -B.3.2.1 – We recommend dividing this into three entries similar to B.3.1.1-B3.1.3 having one entry for each of the Level A, AA and AAA. For example, for Level A all WCAG 2.0 A accessibility features turned on by default.

@JR: Agreed.
B.3.3 Ensure that features of the authoring tool supporting the production of accessible content are documented.    
B.3.4 Ensure that any authoring practices demonstrated in documentation are accessible. 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) @@propose:no-change@@
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.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.
IBM23: A.3.1.3 Keyboard shortcuts: This is an advisory, not a requirement, in WCAG 2.0 because it's just not testable in a useful way. As worded, you would technically pass this SC if you have at least two keyboard shortcuts but whether you have actually provided enough keyboard shortcuts to make something usable is highly subjective or requires extensive user testing. This will be a source of controversy with regards to compliance so it should mirror WCAG 2.0 and have this be an advisory technique for meeting A.3.1.1.  
IBM24: A.3.1.3., A.3.1.5 The techniques refer to all mobile devices having keyboard shortcuts. Is that accurate? Appears to be desktop centric, and not supportive current mobile devices.  
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) [Addressed]
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.

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”.
IBM30: A.3.5.1: the sub-bullets don't need "and" at the end of each one. And is implied by the wording of the parent provision because it doesn't say "one of the following"  
IBM31: A.3.5.1 Most browsers support text search and type ahead capability. Would this satisfy the checkpoint? If so, why is it not in the implementation section? Why do you confine searches to the editing view in this situation? Have you spoken to UAAG about requiring the feature of text searching. This would remove the burden from the author for web content.  
A.3.6 [For the authoring tool user interface] Manage preference settings. 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) [Addressed]
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.
IBM32: A.3.6.1 Saving authoring tool display and keyboard settings. This seems onerous if you are doing rich web applications. It means you need to have some sort of RESTful service to stash this information. Local Data Storage does not show up until HTML 5 for the web. I am not aware of a web email clients (rich text editing capability) that supports this today.  
IBM23: A.3.6.2 Web pages do not have access to keyboard control settings so what happens when you have a web page that acts like an authoring tool? At best you could implement best practices for a given platform but if customization goes on you are out of luck. Browsers have security walls put up to prevent you from asking OS specific information. Is there a plan to address this issue?  
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. 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)
IBM37: A.4.2.2 Does this require statements of UAAG conformance? JR: I don't understand this.
B.1.1 Support web content technologies that enable the creation of content that is accessible.    
B.1.2 Ensure that the authoring tool preserves accessibility information. 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)
IBM41: B.1.2.3 - Why is the AA requirement to preserve accessibility information up to WCAG 2.0 Level AAA? It should only be up to Level AA. If Level AAA is required, there should be another provision.  
IBM43: B.1.2.4 Most if not all information is accessibility information. If I export a file to PDF are you going to interrupt the user ever time it runs into an unsupported feature in the target document format? This seems unrealistic. For example, text is important to accessibility as is alt text. I think accessibility information needs expansion for that reason. Also what about labels and live region support - any accessibility property.  
B.1.3 Ensure that automatically generated content is accessible. JR: Should be B.1.3.2 Accessible Auto-Generated Content (WCAG Level AA): ?
B.2.2 Assist authors in checking for accessibility problems. 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.
OC23: -B.2.2.7 – We recommend making this Level AAA.

JR: The group decided it was Level AA.
IBM53: B.2.2.6 Difficult to have a web email client or a wiki provide a status report on accessibility of dynamic content. There is value, but this is a significant requirement, should be AAA and configurable.  
IBM54: B.2.2.7 Need more concrete examples of using metadata here. Metadata is very abstract.  
B.2.3 Assist authors in repairing accessibility problems.    
B.2.4 Assist authors with managing alternative content for non-text content. 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.
OC26: -B.2.4.4 – We recommend making this Level AAA as this is applies equally to non- accessibility related content and moves into a product usability feature.

@@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 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.2 Ensure that features of the authoring tool supporting the production of accessible content are available. 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.
OC31: -B3.2.4 – Because there are a variety of prominence levels for the examples given it will be very subjective which to choose. How we would highlight markup is very different from a spelling issue. This makes the item very subjective and hard to test.

@@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 Ensure that any authoring practices demonstrated in documentation are accessible. 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)

Level AAA 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.2.2 [For the authoring tool user interface] Editing view presentation 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.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) [Addressed]

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.

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

 @@@ JR: Some are aided by the ability to have multiple sets of preferences (e.g., because their vision fatigues easily).
B.1.1 Support web content technologies that enable the creation of content that is accessible.    
B.1.3 Ensure that automatically generated content is accessible. 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.3 Assist authors in repairing accessibility problems.    
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.
IBM57: B.2.5.9 For content such clip art it may be inaccessible. The author should be able to provide the alt text to make it accessible. So, the source template may not comply but it could be fixed. I don't know that you would have to always require that the template be WCAG 2.0 compliant to start.  
B.3.1 Ensure that accessible authoring actions are given prominence.    
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.