Updated 1 Nov. 2010
@@@: Major outstanding issue/change
@@: Moderate outstanding issue/change
@: Minor outstanding issue/change .
[Addressed]: Addressed by WG.
Unapproved proposals are marked "Proposal" and are in bold.
Where issues repeat, we point to the first instance with "@SEE".
| Applicability Notes: For PART A: Make the authoring tool user interface accessible: | Comments | AUWG Responses |
|---|---|---|
| Scope of authoring tool user interface: The Part A success criteria apply to all aspects of the authoring tool user interface that are under the control of the authoring tool developer. This includes views of the web content being edited, and features that are independent of the content being edited, such as menus, button bars, status bars, user preferences, documentation, etc. | UAWG1: What about authoring systems that offer end-to-end publishing and web server publication/configuration. It should be clear where any line for AU responsibility ends. If you do expand this, you might want to give examples to more clearly define what you mean by "authoring systems that offer end-to-end publishing and web server publication/configuration". Would that include Web-based authoring tools such as when Drupal provides forms where the user can author or edit content that it hosts, using either text markup or WYSIWIG mode, and their choice of Web browsers? | AUWG: ATAG 2.0 certainly applies to Drupal and other CMS systems. This is clear from: " software for generating/managing entire web sites (e.g., content management systems, courseware tools, content aggregators)"[ADDRESSED] |
GL34. MINOR: UI is not always under the control of the tool. In "PART A: Make the authoring tool user interface accessible", "Applicability Notes", "1. Scope of authoring tool user interface: The Part A success criteria apply to all aspects of the authoring tool user interface that are under the control of the authoring tool developer. This includes views of the web content being edited and features that are independent of the content being edited, such as menus, button bars, status bars, user preferences, documentation, etc." it is worth noting that things like menus can be completely under the control of the authoring tool (as in its own menus), or completely under the control of the author (as in "fake" menus created by scripts in the Web content), or a hybrid of the two (as in menus created specified by the authored content but implemented by the authoring tool (such as XUL menus). |
AUWG: We have reworded applicability note#1 as follows: "The Part A success criteria apply to all aspects of the authoring tool user interface that are concerned with producing the *included web content technologies*. 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. The success criteria do not apply to any aspects of the authoring tool user interface that have been modified by parties other than the developer (e.g., by plug-ins, user modifications, etc.)."[ADDRESSED] |
|
| IBM12: Applicability Notes: Scope: appears that this applies to all views of the content being edited. But authoring tools support multiple content formats, some of which might not support accessibility. Is this a problem? | AUWG: We have clarified this by saying: "The Part A success criteria apply to all aspects of the authoring tool user interface that are concerned with producing the *included web content technologies*." [ADDRESSED] | |
| Reflected web content accessibility problems: The authoring tool is responsible for ensuring that editing views display the web content being edited in a way that is accessible to authors with disabilities (e.g., ensuring that a text alternative in the content can be programmatically determined). However, where an authoring tool user interface accessibility problem is caused directly by a web content accessibility problem in the content being edited (e.g., if an image in the content lacks a label), then this would not be considered a deficiency in the accessibility of the authoring tool user interface. | GG1: "(e.g. if an image in the content lacks a label)" may be confused since labels in HTML, refer to a component of a form. Perhaps use "e.g. image in the content lacks a text alternative". | AUWG: The suggestion ("e.g. image in the content lacks a text alternative". ) is accepted.[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." | AUWG: We have clarified the wording as follows: "The authoring tool is responsible for ensuring that editing-views display the web content being edited in a way that is accessible to authors with disabilities (e.g., ensuring that text alternatives in the content can be programmatically determined). However, where an accessibility problem is caused directly by the content being edited (e.g., if an image in the content lacks a text alternative), then this would not be considered a deficiency in the accessibility of the authoring tool user interface." [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. | AUWG: We have clarified the wording as follows: "Authoring tools are responsible for the accessibility of web content that they automatically generate after the end of an author's authoring session. For example, if the developer changes the site-wide templates of a content management system, these would be required to meet the accessibility requirements for automatically-generated content. Authoring tools are not responsible for changes to the accessibility of content that the author has specified, whether it is author-generated or automatically-generated by another system that the author has specified (e.g., a third-party feed)." [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." |
@SEE MS1 [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. | AUWG: We have removed "repair tools" from this example for clarity. However, there are still possibilities for gathering info from users in an automated way (i.e., repair tools). [ADDRESSED] |
| Features for meeting Part B must be accessible: The Part A success criteria apply to the entire authoring tool user interface, including any features added to meet the success criteria in Part B (e.g., checking tools, repair tools, tutorials, documentation, etc.). | ||
| Multiple author roles: Some authoring tools include multiple author roles, each with different views and content editing permissions (e.g., a content management system may separate the roles of designers, content authors, and quality assurers). In these cases, the Part B success criteria apply to the authoring tool as a whole, not to the view provided to any particular author role. | GL15. MEDIUM: Features should be available to all applicable roles. In "Implementing PART B: Support the production of accessible content", "Applicability Notes" it says "5. Multiple author roles: Some authoring tools include multiple author roles, each with different views and content editing permissions (e.g., a content management system may separate the roles of designers, content authors, and quality assurers). In these cases, the Part B success criteria apply to the authoring tool as a whole, not to the view provided to any particular author role." This seems a bit overly broad, as individual features required by ATAG part B should be visible in any mode where they would be useful. As an extreme example, syntax checking should be visible and available to authors and QA, so it should be insufficient to have them available only to system administrators. | AUWG: We are trying to be sensitive to the workflows of enterprise systems. We will add this final sentence: "Accessible Content Support Features should be made available to any author role where it would be useful."[ADDRESSED] |
| Guideline | Success Criteria | Comments | AUWG Responses |
|---|---|---|---|
| General | WCAGWG1: Consolidate WCAG 2.0 related SC: A number of the guidelines include SC that reference conformance to WCAG 2.0 at various conformance levels. Consider combining these to reduce the overall number of success criteria and to minimize repetition and cross-references in the implementation guide. For example, combining the three SC listed in A.1.1 might look like: A.1.1.1 Web-Based Accessible (WCAG Conformance): Web-based authoring tool user interfaces conform to WCAG 2.0 at one of the following conformance levels. * Level A: For Level A conformance, web-based authoring tool user interfaces conform to WCAG 2.0 Level A. (Level A) * Level AA: For Level A conformance, web-based authoring tool user interfaces conform to WCAG 2.0 Level AA. (Level AA) * Level AAA: For Level A conformance, web-based authoring tool user interfaces conform to WCAG 2.0 Level AAA. (Level AAA) A similar approach should be considered for the B.1.1.x, B.1.3.x, B.2.2.x, B.2.3.x, B.2.5.x, etc. |
AUWG: We agree to make this change throughout the document:
[ADDRESSED] |
|
| JM1: I do suggest that it make clear that an authoring tool should produce accessible content with its default settings. Currently, I interpret the guidelines as recommending that such settings be as prominent as other configuration choices. I think it is important, however, that an author has to make a conscious decision to depart from a mode in which accessible content is the result. In this way, accessible content is the norm for developers who do not think about accessibility and use the authoring tool as is, without customizing its settings. I also suggest that the guidelines incorporate more explicit references to web 2.0-type web pages that create value from user-generated content. On such a page, the reader is often an author as well. The user agent, e.g., web browser, is an authoring tool, too. The user may enter text, upload audiovisual media, or simply express preferences -- e.g., rating an article. This combining of reading and writing capabilities blurs distinctions between audiences of the Authoring Tool Accessibility Guidelines and the User Agent Accessibility Guidelines. Spontaneous, user-generated content makes it more important than ever that accessible content is produced via default settings of both live user agents and offline authoring tools. | @AUWG: We believe that the "accessible by default" issue is sufficiently covered by B.1.3.1 (Accessible Auto-Generated Content) and B.3.2.1 (Active by Default).
|
||
| AC2: I think it is relevant to explain to readers why the two seemingly independent requirements, of (1) access to authoring tools and (2) production of accessible content, are covered in the same document. I remember once someone from WAI (Judy or Shawn?) explain something along the line that only when people with disabilities can create Web content in equal conditions will web accessibility become a reality. ATAG 1.0 contains a partial explanation, "Since the Web is both a means of receiving information and communicating information, it is important that both the Web content produced and the authoring tool itself be accessible." With the current trend toward user-produced content this is now even more true than when ATAG 1.0 was published (see Jamal's comment [1] about Web 2.0 content). This idea of a two-way process is the clearly (to me) the reasoning for including both requirements in the same recommendation, but an explanation seems to be needed. | AUWG: We have modified the Introduction as follows: "Accessibility, from an authoring tool perspective, includes addressing the needs of two overlapping user groups with disabilities: * authors of web content, whose needs are met by ensuring that the authoring tool user interface itself is accessible (addressed by Part A of the guidelines), and * end users of web content, whose needs are met by ensuring that all authors are enabled, supported, and guided towards producing accessible web content (addressed by Part B of the guidelines). It is important to note that, while the requirements for meeting these two sets of user needs are separated for clarity within the guidelines, the accelerating trend toward user-produced content means that in reality they are deeply inter-connected. For example, when a user participates in an online forum they frequently author web content that is then incorporated with other content authored by other users. Accessibility problems in either the authoring user interface or the web content produced by the other forum users would reduce the overall accessibility of the forum". [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. | @@AUWG: The "Essential" wording is in an informative part of the document and comes from the "Understanding Conformance" text from Understanding WCAG 2.0 so we prefer not to change it too much. But we have added a reference to the built-in accessibility features of the platform. JR Proposal: "- whether the success criterion is essential (in other words, if the success criterion is not met, then even the built-in accessibility features of the platform (e.g., keyboard interface) and assistive technology cannot make the authoring tool user interface accessible) " |
||
| GL10. MEDIUM: Criteria need not apply to all types of authoring tools. The section "Understanding Levels of Conformance" says "factors evaluated when setting the level in Part A included:...whether it is possible to satisfy the success criterion for all types of authoring tools that the success criteria would apply to (e.g., text editors, WYSIWYG editors, content management systems, etc.)" I don't believe a potential success criterion should be excluded just because it does not apply to all authoring tools; rather: | @AUWG: We agree and believe that we have addressed the issue using conditional phrasing on many of the success criteria.In addition we have added this wording in the conformance section: "Specialized Authoring Tools: Some authoring tools provide a fairly limited set of authoring functions compared to the range of possible authoring functions addressed in these guidelines (e.g., a photo editor, a CSS editor, a status update field in a social networking application, etc.). In this case, most of the ATAG 2.0 requirements are simply not applicable, since most of the requirements are conditional on particular authoring functions being present (e.g., automatically generated content must only be accessible if this functionality exists). " | ||
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. |
AUWG: 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. [ADDRESSED] 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. | AUWG: The WG requires specific comments on levels per success criteria, not in general, which fortunately are also provided in later comments. [ADDRESSED] | ||
| Conformance | WCAGWG2: Required Components of an ATAG 2.0 Conformance Claim #5 (Authoring tool information): Consider adding information about the role and requirements for information about extensions, plugins or modules that may have modified or extended the authoring tool to meet a requirement. | AUWG: The existing note covers this concern, but we will try to be more clear.[ADDRESSED] | |
| WCAGWG3: Required Components of an ATAG 2.0 Conformance Claim #6 (Web content technologies produced): Consider dropping the requirement for a list of technologies not included as this can be derived from the list of technologies that the tool is capable of producing when compared to the list of technologies included in the claim. | AUWG: The developer knows what they are producing (e.g., via "Save As", "Export"). It would be easier for them to include this information than to expect every reader of a conformance claim to determine this.[ADDRESSED] | ||
| WCAGWG4: Required Components of an ATAG 2.0 Conformance Claim #7 (Declarations) and Checklist: This requirement implies that each claim would have to list each SC that is met. It should be possible to declare a range of SC that have been met. (ex. All Level A). Additionally, inviting claimants to declare success criteria that are not applicable may be a slippery slope and often leads to inaccurate claims. Instead, suggest including a statement that says that where an authoring tool does not include a feature that is relevant to a given SC, then that SC is automatically satisfied. | AUWG: We think it is more clear to have to address each success criteria individually. It is problematic to categorize not applicable SCs as "automatically satisfied" because it provides less information as to the thinking of the Claimant. [ADDRESSED] |
||
| WCAGWG5: Waiving of WCAG 2.0's conformance requirement #4: Only Accessibility-Supported Ways of Using Technologies. Many of ATAG's success criteria rely on conformance with WCAG 2.0 but allow for information or functionality provided in a way that is not accessibility supported. This is potentially quite a loophole and can easily mislead (intentional or not) the intended audience regarding the production of content that conforms to WCAG 2.0. | AUWG: In order not to unintentionally mislead readers about WCAG 2.0's conformance requirements, we have switched from saying "conforms to WCAG 2.0" to "meets the WCAG 2.0 success criteria" [ADDRESSED] | ||
| GG3: Conformance claims: Is there going to be a Conformance Claim program to validate claims made by developers, and by others representing authoring tools? ATAG differs from WCAG in claims made in that WCAG is easily checked with a variety of tools to confirm conformance claims. Such a tool does not exist to confirm ATAG conformance claims. Experience with the claims process for another standards organization I'm involved with, raises questions about the "honesty" of claimants, or perhaps the "scope" of a particular claim that omits points of failure. Self-claims are easy to make, but they don't hold much clout, and they can easily deceive or mislead potential users. As a purchaser of an ATAG conformant authoring tool, I'd want something more than a self-claim. A dishonest developer could potentially have a competitive advantage over an honest one. Perhaps there should be a distinction between self-reported compliance, and W3C (or another granting body) endorsed compliance. Or, perhaps setup something that legally binds a claimant, such as submitting a claim through a central, perhaps W3C, claims site, where they must agree to a legal statement before making a claim. This would discourage invalid claims, and potentially provide recourse in the event that a fraudulent (or less than complete) claim is made to the detriment of other developers or users of an authoring tool. | AUWG: We agree that this is an issue, but it is out of scope. [ADDRESSED] | ||
| MS2: The biggest concern for ATAG 2.0 is that it is never clear if ATAG is for a single tool or a collection of tools. It is trying to be both. This leads to a great deal of structural problems. If it is for a single tool, then the SCs are too far reaching and the conformance requirement does not make room for a simple specialized tool to conform. How does ATAG 2.0 conformance work for something like a web accessibility toolbar, photo editor, FTP client, or a social networking site? You need to allow tool makers to say their tool does not provide certain function and it is not intended to do so, but the tool conforms where it is applicable. On the other hand, how would conformance work for a collection of tools where some criteria are met via a portion of the tools? Would one have to specify which tool(s) is used to conform to any given criterion? If the collection of tools include tool(s) in which the conformance claimer has no Intellectual property ownership, would the claimer then be held responsible for the accuracy of the claim of such tool? What if is there is discrepancy between the tool manufacturer and claimers? What if the collection is still not applicable to ATAG in full—for example, only relevant to part A? Is the collection deemed incomplete? Additionally, where does the value chain of the authoring process end? Without knowing the scope, then ATAG 2.0 may require consideration of software such as scanner application, a database, a web service, or enterprise backend systems. Does a mail client become a “web authoring tool” only when it sends a message to somebody who access their email via the web? How is one supposed to know if the mail recipient uses a web client? These are extremely difficult questions. But if left unanswered, ATAG 2.0 will not be viable in practice. The conformance section requires fundamental revision to be viable. Please revise accordingly. | @@@AUWG: We believe that we have addressed the issue in the following ways: |
||
| MS3: Conformance Condition 1 WCAG 2.0 does not require conformance claim be made in the web or not. This condition is unnecessary. Please remove condition. | AUWG: Conformance claims are optional. Being public about the conformance details is consistent with W3C principles. [ADDRESSED] -MS still a concern that it is inconsistent with WCAG2 |
||
| MS4: Conformance Condition 6 This is an “encouragement”. Thus, it does not belong to the normative part of the ATAG 2.0. Please move condition 6 to non-normative part of ATAG 2.0 | AUWG: This text has been moved to an informative note. [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.)" | AUWG: Text editors has been dropped from the list of examples. [ADDRESSED] | ||
| IBM11: In this sentence defined "proportionally greater" as this is vague: In other words, the user interface issue must cause a proportionately greater problem for authors with disabilities than it causes authors without disabilities and must be specific to authoring tool software, as opposed to software in general. | AUWG: The text is harmonized with text in WCAG 2.0's Understanding Document (http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html). The text has been moved to the Implementing ATAG 2.0 document. [ADDRESSED] | ||
| IBM58: Conditions on Conformance Claims- bullet 4: BLOCKING ISSUE: we raised an issue last time about anybody being able to make a claim even for stuff they don't own. What if a government enacts procurement regulations requiring ATAG compliance, we provide a compliance statement on one of our products that differs from what a journalist somewhere publishes about our product? The journalist might falsely claim that our product is compliant. Would the customer then hold us liable? Or conversely, we may be claiming compliance due to some particular situation about how the product is going to be used by this customer but the journalist claims it is not compliant. We might lose the sale. | AUWG: We have dropped the language referring to who can make a claim that explicitly mentionned "anyone". [ADDRESSED] | ||
| 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. | @SEE IBM58 [ADDRESSED] | ||
| IBM60: bullet 5 seems especially problematic for us where we have bundled third party components that are not licensed to the customer by IBM: "Claimants are solely responsible for the accuracy of their claims (including claims that include products for which they are not responsible) and keeping claims up to date." | AUWG: This wording was actually put in to protect developers from the claims of others. But since it has only caused more confusion, it will be removed. [ADDRESSED] | ||
| 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). Proposal: Note at top of glossary "Many of the terms in the glossary are shared with WCAG 2.0. In some cases, the definition wordings have been adjusted to reflect the authoring tool domain, particularly the fact that authoring tools can be both web-based and non-web-based. Any cases in which the ATAG 2.0 definition of a shared term term differs substantially from the WCAG 2.0 definition will be noted. " |
|
| WCAGWG7: assistive technology: We suggest that you use the WCAG definition with an additional note about authoring tools providing direct accessibility features. | @AUWG: The WCAG definition has too many Web and browser specific references to use it directly.
|
||
| WCAGWG8: programmatically determined: We suggest that you use the WCAG definition and include your second sentence as a Note. | @AUWG: The WCAG definition has too many Web and browser specific references to use it directly. @SEE GL1 | ||
| WCAGWG9: non-text content: We believe that it is critical that your definition include the phrase "can be programmatically determined". | AUWG: Agreed: Non-text content: "Any content that is not a sequence of characters that can be programmatically determined or where the sequence is not expressing something in human language. This includes ASCII Art (which is a pattern of characters), emoticons, and images representing text." [ADDRESSED] |
||
| 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 major-issue. ALSO I propose we remove the "recognized" term. It only appears in A.2.1.1 and B.2.4.4, which should be updated as follows: A.2.1.1 Alternative Content: If web content is rendered in editing-views, its alternative content can be programmatically determined. (Level A) B.2.4.4: Suggest Previous Author Entries: Authors have the option to have alternative content for non-text content that they have previously authored suggested when the same non-text content is re-used. (Level AA)
|
||
| GL8. MEDIUM: Broaden definition of authoring tool. Re the definition of "authoring tool", I wonder whether you also want to explicitly cover tools that cannot directly output Web formats, but can output rich content that can then be converted into Web formats. For examples, imagine a word processor that cannot save documents as HTML but can copy rich text and graphics to the clipboard, from which they can be pasted into a tool that can save them as HTML. The source editor could take steps, such as prompting the user for Alt text for an image, so that the rich content it creates can be converted to Web formats that conform to WCAG. The only nod to this in the definition is the one example that is not explicitly Web-related, "multimedia authoring tools", and that is ambiguous. | @AUWG: As a W3C recommendation, we need to stick to Web content. It would be fairly easy to apply ATAG 2.0 to Word processor applications creating only word processor documents if one wished too. | ||
| IBM1: Authoring tool- the numbered items look like "notes" which further explain the
definition. They should be labeled Note 1, Note 2, etc. |
AUWG: This change has been made. [ADDRESSED] | ||
| IBM2: Authoring tool- The examples include debugging tools for web content". I don't understand how debugging tools can be considered an authoring tool. | AUWG: This has been removed.[ADDRESSED] | ||
| IBM3: Authoring tool- authoring tools it includes email clients. If an email client
supports accessible web content authoring do we know that the mail format
preserves the accessibility information that would be prompted for in an
email authoring tool? Such as:alt text, ARIA semantics, table structure,
keyboard navigation.This applies to other document formats. |
@AUWG: Plain email is an unstructured format, which is not considered Web content. But HTML email certainly is structured. Note in the authoring defn that tools might also do other things (e.g. edit content that isn'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. |
AUWG: Right. A browser plug-in is an acceptable authoring tool component. [ADDRESSED] | ||
| 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 understand the concern. [ADDRESSED] | ||
| IBM6: view - The numbered items in this definition look like additional terms. In fact, there are links from the document to the terms in the numbered list yet they don't make sense unless you read the parent definition. For example, Guideline A.2.2 rationale links to the term "editing view" but the bullet "editing views are editable" is not a sufficient definition to understand what the term means in the context in which it is used. Creating separate terms in the glossary with definitions that stand alone and also reference the more general term would be a better approach. |
AUWG: We will break up the definitions into single terms. [ADDRESSED] | ||
| IBM7: programmatically determined (programmatically determinable) - (Blocking issue) do not agree with the definition of programmatically determined. It is inadequate and should not be limited to "platform accessibility architecture." Platform accessibility architecture is also inconsistent with the U.S. 508 refresh. Do not want to mislead people to thing that only what is available in the platform accessibility architecture can be used. Definition must refer to platform accessibility services and platform accessibility services to be any recognized accessibility services layer supported by assistive technologies that support full interoperability with web content technology capable of supporting WCAG 2. | @AUWG: We will reword the definition of programmatically determined to add: "IAccessible2" and "General APIs". @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. | AUWG: We have changed to using "( )". [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. | AUWG: 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. [ADDRESSED] |
||
| IBM13: A.1.1 and A.1.2 refers to Web-based and non web-based authoring tools. Web-based is not clearly defined. When stating web-based do you mean W3C document standards or do you mean that to include any web delivered standard such as Flash, Flex, Silverlight, etc.? | AUWG: We have added Flex, and Silverlight as examples Web-based technologies. Flash already was an example. [ADDRESSED] | ||
| IBM14: A.1.1 Web-based functionality: For web-based UIs, some of the subsequent requirements modify WCAG 2.0 requirements. Has the work been done to determine if it is even possible to comply with A.1.1 (comply with WCAG) AND comply with all of the subsequent requirements that are tweaks on WCAG 2.0 requirements? If the rationale is that these things are needed for non-web-based functionality, then the provision should be scoped to non-web-based functionality. For example, why is A.3.2.2 needed for web-based content when it also has to comply with WCAG 2.0 via A.1.1? | @AUWG: The reason for the duplication is that ATAG2 applies to both web-based and non-web-based authoring tools. As long as we have kept the requirements the same (which is our intention), there won't be any problem for Web based tools. In the Implementing ATAG 2.0 document, we have referenced the relevant WCAG 2.0 success criteria. | ||
| IBM15: A.1.1 and A.1.2 refer to web content but they don't state that the web content be supported by at least one user agent to be consistent with UAAG 2. If you don't have this stipulation then the user will be unable to use the web content. Somewhere in ATAG this does need to be stipulated. | AUWG: If this refers to WCAG 2.0's "Accessibility Support" concept, this is explained in the conformance section. Also, ATAG 2.0 does not attempt to grade web content formats.[ADDRESSED] | ||
| 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 major-issue, my suggestion would not be).[@Proposal due from: SN] |
| 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". | AUWG: Changed to "editing-view" and reworded as "If web content is rendered in editing-views, recognized alternative content can be programmatically determined." [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. | AUWG: reworded as "If web content is rendered in editing-views, recognized alternative content can be programmatically determined." [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. | AUWG: reworded as "If web 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: [@Proposal due from: TB, JR] |
| MS6: A.2.2.1: “Additional information” is undefined. In order to determine what is considered additional information, one must know what is considered baseline information. We realize that AUWG considers underlining of misspelled words to be a piece of “additional information”, but there is no way to tell what is it that makes such information qualified as being “additional”. This will make it impossible to determine if the criterion is met.. We can at best project the concept into the similar scenarios for grammatical errors and coding errors—purely because it is an educated guess. Define “additional information” to make it objectively testable or revise the success criterion. | @@AUWG: JR: Proposal: A.2.2.1 Editing-View Messages: If an editing-view provides messages to authors by modifying the content renderings or adding temporary content, then those messages can be programmatically determined. ACTION: alastairc to reword the proposal for MS6 on spellchecking in the editing view. |
||
| 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". | @SEE WCAGWG11 |
||
| 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. | @SEE WCAGWG11 |
||
| 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. | AUWG: We do not understand the comment. [ADDRESSED] | ||
| IBM18: A.2.2.2 Access to text presentation: The use of the word "and" in the sub-bullets is unnecessary as the provision wording is clear that if any of these presentation characteristics are supported, they must be programmatically exposed. | AUWG: We have followed the WCAG 2.0 style. [ADDRESSED] | ||
| 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 GL1 | ||
| 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. | AUWG: "(including WYSIWYG views)" might be confusing and has been removed. WYSIWYG is not exactly clear because the end-user can quite often modify what they get. We just want to say that the author should similarly be able to modify what the author (not the end-user) gets as they edit 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 | AUWG: Agreed. Moved to A.3.6.1.[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. | AUWG: The two requirements are now together in the same Guideline, but they have different levels and address different issues. [ADDRESSED] | ||
| A.3.1 [For the authoring tool user interface] Provide keyboard access to authoring features. |
|
JC2: re: A.3.1.1 Please change "Keyboard Access" to "Keyboard Equivalent Access" and change "keyboard interface" to "keyboard equivalent interface."For example, all functionality of iOS and accessible iOS applications is available through a keyboard equivalent and is accessible through multi-sensory output (sight and sound, and touch if using a external braille display), and does not require a standard keyboard interface to be accessible. Example: See Victor Tsaran's demo of iPhone4/iOS4 with an external braille display. http://www.youtube.com/watch? v=6_TFHqIHBqM |
AUWG: This is addressed in the definition of "Keyboard Interface" (which is intentionally different than keyboard) which comes from WCAG 2.0. We have changed the handle to "Keyboard" in order to harmonize with WCAG 2.0. [ADDRESSED]
|
| 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 MS8 - MS will revisit |
||
| MS9: A.3.1.1 Why does the language differ from WCAG “except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints” Either reconcile the difference or provide rationale for the difference. | AUWG: We have re-harmonized with WCAG 2.0 but added this line to the first note: "The path exception encompasses other input variables that are continuously sampled from pointing devices, including pressure, speed, and angle." [ADDRESSED] | ||
| MS10: A.3.1.2 Why does the language differ from WCAG “...if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away." Either reconcile the difference or provide rationale for the difference. | AUWG: We have re-harmonized with WCAG 2.0 for (a), which is under the control of the developer. The rationale for (b) is that the content being rendered might include keyboard traps.[ADDRESSED] | ||
| GL3. HIGH: Keyboard trapping too narrowly defined. Re "A.3.1.2 No Content Keyboard Traps:...(b) In Editing Views that Render Web Content: If an editing view renders web content (e.g., WYSIWYG view), then a documented keyboard command is provided that will always restore keyboard focus to a known location (e.g., the menus)." The problem with this wording is that being able to move the focus from an object to the authoring tool's menu is not sufficient if, when they return to editing mode, the keyboard focus returns to a trapped state. For example, imagine that you are authoring content and use a command insert a Flash object, leaving the focus on that object and no keyboard command such as Tab to move it off; the only thing you can do is press a key combination to move the active keyboard focus to a menu, but upon dismissing the menu the focus is back on the Flash object, and you still cannot get to the rest of the document, and you presumably have to close the document and reopen it again to get back into a usable editing mode. The true intent should be to allow the author to move the keyboard focus to other elements inside the content--specifically, being able to move the focus elsewhere within its current viewport and to any other viewports that can take keyboard focus. |
AUWG: Agreed. Here is the new wording: "(b) In Editing Views that Render Web Content: If an editing-view renders web content (e.g., WYSIWYG view), then a documented keyboard command is provided that moves the editing-view keyboard focus to a known location (e.g., the start of the editing-view)."[ADDRESSED] |
||
| IBM21: A.3.1.2 No keyboard traps a) requires a keyboard way to exit all content that can be entered using the keyboard. Is this always possible for authoring tools? For example, say you have an authoring tool that allows the addition of third party UI widgets. If you drag insert one of those widgets into the content you are editing and move keyboard focus to it, who now owns the keyboard focus? The widget or the authoring tool? If it's the widget, then how does the authoring tool guarantee that you can exit the widget with the keyboard? |
AUWG: The third-party UI widget issue has been addressed by the rewording of Part A Applicability note #1 @SEE GL34 | ||
| 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 | ||
| A.3.2 [For the authoring tool user interface] Provide authors with enough time. |
|
JC3: re: A.3.2.2(F): Minor: I'm pretty sure the 508 refresh requires 8 hours for the exception, not 20. If you have a good reason to refute 508, please file a comment on that requirement. Otherwise, I'd suggest remaining consistent and using the 8 hour exception. | AUWG: We are simply remaining consistent with WCAG 2.0. Frankly, the number is fairly arbitrary either way. [ADDRESSED] |
| WCAGWG12: A.3.2.2 Timing Adjustable: What would be an example of an authoring tool time limit where extending the time limit would invalidate the activity (e)? | AUWG: An example might be authoring something as part of a exam. [ADDRESSED] | ||
| IBM25: A.3.2.1 Data saved: What does "submitted content edits" mean in a non-web-based authoring tool? | AUWG: That language should be moved to clarifying guidance. [ADDRESSED] | ||
| IBM26: A.3.2 What happens if the authoring tool give the author the ability
for the author to set the refresh rate of the page? This is something the
author has set. Does this require warnings to the author when during a test
run the time is about to expire? |
AUWG: The author control has been addressed by the rewording of Part A Applicability note #1. @SEE GL34 [ADDRESSED] | ||
| A.3.3 [For the authoring tool user interface] Help authors avoid flashing that could cause seizures. |
|
MS11: A.3.3.1 It should be recognized that there is a fundamental conflict between the necessity to view the animation during animation editing process and the need to disable animation to prevent seizure. This cannot be at level A in its current form. Is this applicable to non-visual time based content too? If so, what is the rationale? Move the SC to AA or AAA, explain that there is a potential for fundamental alteration, and to exclude all non-visual time-based content. | AUWG: Agreed. Reworded as: "Editing-views that render visual, time-based content (e.g., animations) can be paused and can be set to not play automatically" [ADDRESSED] |
| 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 major-issue change)@@@MS |
| 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. | @SEE MS12 | ||
| 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. | @SEE MS12 | ||
| MS15: A.3.4.1 & A.3.4.2 What does “make use of” means? Please provide definition. | @SEE MS12 | ||
GL22. MEDIUM: Low bar for A.3.4.1 Edit By Structure. "A.3.4.1 Edit By Structure: Editing views for structured web content include editing mechanism(s) that can make use of the structure. (Level A)" and "A.3.4.2 Navigate By Structure: Editing views for structured web content include navigation mechanism(s) that can make use of the structure. (Level A)" both seem particularly broad, as having any a single feature that makes use of structure would be enough to comply. That makes it easy for an authoring tool to comply with the letter of the requirement without addressing its spirit. For example, it appears that displaying a completely static outline of a document in a separate window would be enough to comply, even though it would provide relatively little benefit. |
@@AUWG: 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. |
@SEE MS12 | ||
| 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." | @SEE MS12 | ||
| 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. | @SEE MS12 | ||
| 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. | @SEE MS12 | ||
| A.3.7 [For the authoring tool user interface] Ensure that previews are as accessible as existing user agents. |
|
WCAGWG13: A.3.7.2 Preview: As worded, it appears that a UA that utilizes any third-party user agent for preview would automatically meet this SC. Suggest that part (a) be revised to require the use of the author's default user agent, which would avoid a situation where the author is unable to preview content in the UA that best meets their accessibility needs. | AUWG: The intention is to leave this up to developers - e.g. to embed user agents directly into the authoring tool UI. [ADDRESSED] |
| UAWG3: Suggest changing (a) Third-Party User Agent: The preview makes use of an existing third-party user agent; or to be (a) Third-Party User Agent: The preview makes use of an existing third-party accessible user agent; We think a clearer, less subjective wording for may also be "The preview makes use of an existing third-party user agent that conforms to the User Agent Accessibility Guidelines Level A; or". However, we should also acknowledge that the authoring tool may allow the user to configure which third-party user agent should be used, and should be able to pick an accessible one but should not be prohibited from choosing an inaccessible one. I haven't had time to draft wording that entirely works. | AUWG: Actually the logic is a bit different. It is that previews are meant to show how content will appear to end users in the "real world" - i.e. in an existing user agent where the user agent accessibility is the user agent developer's concern. (a) is the straightforward way to provide this. But if the authoring tool developer wants to depart from existing user agents, then the accessibility of that new user agent becomes THEIR concern and so UAAG would apply. [ADDRESSED] | ||
| MS16: A.3.7.1 This criterion is redundant to A.3.1.2. Please remove the criterion. | AUWG: Agreed. We have removed this SC. [ADDRESSED] | ||
| MS17: A.3.7.2 Please remove the term “third-party” from option A. It is not appropriate. This is saying that Microsoft cannot use IE; Google cannot use Chrome; and Apple cannot use Safari. Please remove the term “third-party” completely. | AUWG: We have replaced this term with "pre-existing" to distinguish "user agents" in the marketplace from something developed from scratch. [ADDRESSED] | ||
| OC9: -A.3.7 – We wonder if there should be a Level AAA requirement that the preview be accessible. | AUWG: We have considered that in the past, but decided that the point of a Preview is to experience authored content the way it will be experienced in “real-world” user agents. Instead we are including a AAA SC to allow author choice of user agents: A.3.7.1 Preview (Enhanced): If a preview is provided, authors can specify which user agent performs the preview (Level AAA) [ADDRESSED]
|
||
OC10: -The Rationale for A.3.7 – Regarding the last sentence “Authors with disabilities need to be able to follow the same workflow”, we feel that this may not necessarily be the case. They need to follow ‘a' workflow, which is supported, documented, etc. but it may not be the ‘same' as an author without a disability. Or perhaps a ‘workflow of similar effort'. |
AUWG: We have reworded as: “Authors with disabilities need the same opportunity to check their work.”[ADDRESSED] |
||
| 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. | @SEE MS17 |
||
| IBM34: A.3.7.1 You need a provision for gestures. I.E. devices that support only gestures should provide a discrete gesture that does this. That gesture should be operable by devices that support people with mobility impairments. Also, you are referring to UAAG 1.0. This document is so dependent on UAAG that I think UAAG 2.0 and ATAG 2.0 need to come to last call together. UAAG 1.0 is 8 years old. | AUWG: We do not understand the "gesture" comment. The UAAG requirement is only a last resort requirement. [ADDRESSED] | ||
| 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? | @SEE MS17 | ||
| A.4.1 [For the authoring tool user interface] Help users avoid and correct mistakes. |
|
MS18: A.4.1.1 How many layers of undo are needed to meet the criterion? Since it is unspecified, we assume one is adequate. Please specify if more than one layer of undo is needed to satisfy the SC. | AUWG: One is sufficient. [ADDRESSED] |
| MS19: A.4.1.1 “Undo” is normally not feasible for many scenarios for basic web form authoring tool or it depends on the browser to carry out the undo. In reality, most actions are reversible without having the “undo” function. If action is reversible, then why impose the specific function of “undo”? Change the SC to read: “Authoring actions are reversible or include warning to authors that the action is irreversible.” | AUWG: Reworded with "undo" as an example: "Authoring actions are either reversible (e.g., by an "undo" function) or include a warning to authors that the action is irreversible." [ADDRESSED] | ||
| MS20: A.4.1.1 This SC requires a warning every time the user execute a file save or the like. This runs against user expectations and will become a serious annoyance. Please add exception for the like of file save from having to give warning. | AUWG: We have modified the definition of "Authoring Actions" to exempt save and publish: "Any action that authors can take using the authoring tool user interface that results in creating or editing web content (e.g., typing text, deleting, inserting an element, applying a template). Most authoring tool user interfaces also enable actions that do not edit content (e.g., saving, publishing, setting preferences, viewing documentation)." [ADDRESSED] | ||
| MS21: Definition of Authoring Action It is hard to see what an author can do with the tool that is not considered authoring action. Please provide examples of non-authoring actions. Please provide examples of what is not considered authoring action and tighten the definition as necessary. | AUWG: The existing definition includes examples of non-authoring actions: "Any action that authors can take using the authoring tool user interface that results in creating or editing web content (e.g., typing text, deleting, inserting an element, applying a template). Most authoring tool user interfaces also enable actions that do not edit content (e.g., saving, publishing, setting preferences, viewing documentation)." [ADDRESSED] | ||
| MS22: A.4.1.1 What is the definition of “committing action”? Please add definition | @AUWG: Proposal: Removing Note 2. | ||
| GL18. MEDIUM: Consider recommending an Undo stack. A.4.1 discusses Undo and Redo, but only applies to a single operation. As one error may invalidate actions taken after it, and a user may not recognize an error immediately (especially when using AT), consider adding a Level AA or AAA success criteria about allowing the user to undo more than just the single most recent operation (i.e. a stack for undo or undo/redo operations). | AUWG: We will add this new SC: A.4.1.X Content Changes Reversible (Enhanced): Authors can sequentially reverse a series of reversible authoring actions (e.g., by an "undo" function). (Level AAA)[ADDRESSED] |
||
| GL44. MINOR: Methods of undoing settings changes. Something else to think about regarding "Implementing Success Criterion A.4.1.2 Undo Setting Changes: Actions that modify authoring tool settings are either reversible or include a warning to authors that the action is irreversible. (Level A)": the text noticeably does not mention "Undo" as a method for achieving this. I can tell you from first hand experience that when speech recognition enters the wrong command into a program, the user interface can be changed in a way that is very difficult to correct because you don't know what command made the change. That argues for an "undo" method for application settings. On the other hand, when applications like Adobe Photoshop Lightroom place interface changes and content changes into the same undo stack it causes another set of major usability problems. | AUWG: We have added this example in the Implementing doc: "Cancel: On each preference settings page are two options, OK and Cancel. Canceling prevents the setting changes from being applied."[ADDRESSED] | ||
GL32. MEDIUM: Clarify minimum for A.4.1.2 Undo Settings Changes. In "Implementing Success Criterion A.4.1.2 Undo Setting Changes: Actions that modify authoring tool settings are either reversible or include a warning to authors that the action is irreversible. (Level A)", what is the minimum acceptable level of functionality? Would it be acceptable for an application to make the user quit and restart the application to get out of a mode? What if the application provides only a single command to reset all settings to factory default? That would seem to not meet the intent, since it may reset settings that the user needs in order to make the application accessible. (See my other comment on this SC.) |
AUWG: We have added "can be reversed by the same mechanism that made the change" as in : "A.4.1.2 Setting Changes: If actions modify authoring tool settings, then one of the following are true: |
||
OC12: -A.4.1.1 –By ‘Authoring actions', is this referring to any action, or only those that are ‘significant', ‘harmful', etc.? Is a workflow in the authoring tool that a user must explicitly save an example of ‘undo'? (the author could always choose to not save and open the last-saved file.) |
AUWG: "Authoring actions" is a defined term. The example would not meet this, because it would undo lots of authoring actions.[ADDRESSED] |
||
| IBM36: A.4.1 Do you have a limit to the number of Undos the author needs to support? One undo is not very helpful. | AUWG: One is sufficient. Of course the option to have more aids usability, but setting a particular number would be arbitrary. [ADDRESSED] | ||
| A.4.2 [For the authoring tool user interface] Document the user interface including all accessibility features. |
|
WCAGWG14: A.4.2.1 Document Accessibility Features: Suggest incorporating the accessibility of the documentation in the SC text itself or include the note from the implementation guide, "The accessibility of the documentation is covered by Guideline A.1.1 and Guideline A.1.2." with the SC. | AUWG: This note has been added: "Note: The accessibility of the documentation is covered by Guideline A.1.1 and Guideline A.1.2." [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." | @SEE WCAGWG14 | ||
| GL45. MINOR: Ambiguous phrase in A.4.2.1 Document Accessibility Features. Re "A.4.2.1 Document Accessibility Features: All features that are specifically required to meet Part A of this document (e.g. keyboard shortcuts, text search, etc.) are documented. (Level A)", this is probably silly but the phrase "features that are specifically required to meet" is grammatically ambiguous as to whether it means every feature that is specifically covered by Part A (e.g. all display of content, which is required to be implemented in such a way as to comply with A.2.2.2) or every feature that is implemented specifically to comply with Part A (e.g. undo, which A.4.1.1 requires to be implemented). | AUWG: Reworded: 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) [ADDRESSED] | ||
| OC13: -A.4.2.1 – Regarding documenting “all features” we feel this is too broad. This is a requirement for all users, not just people with disabilities so we feel it isn't applicable to ATAG. Even with narrowing to “all ‘accessibility-related' features” this could still be very broad. For example, why would features that are programmatically determinable, such as keyboard shortcuts, need to be ‘documented'? | AUWG: We believe this should remain unchanged. People with some disabilities (esp. cognitive, etc.) benefit more from documentation than users in general. [ADDRESSED] | ||
| 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. | AUWG: The wording is meant to be general with more specific details dealt with later. [ADDRESSED] |
| 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." | AUWG: We have taken a different approach to B.1.2. [ADDRESSED] |
| MS21: B.1.2.2 Condition b is absolutely not possible if the output is a third party format. This SC essentially asks authoring tool makers to judge and make claim to users which format is less accessible. It would require constant update to keep such info up-to-date and the potential liability of claiming one format is less accessible than another is not something that any manufacturer can accept, especially when it comes to 3rd party format. Please remove condition b. | @@AUWG: Proposal: Reworded: (b) Warning: if accessibility information required to meet the WCAG 2.0 success criteria will not be preserved in the output, then authors are warned (e.g., when saving a structured graphic to a raster image format). ACTION: Jan to reword MS21 issue on B.1.2.2 with Alastair and GregP |
||
| GL16. MEDIUM: Save information for round-tripping. "B.1.2.2 End Product Cannot Preserve Accessibility Information", "(a) Option to Save: authors have the option to save the accessibility information in another way (e.g., as a "comment", as a backup copy of the input)" should support round-tripping. That is, if the authoring tool recognizes accessibility information in the source format that cannot be converted to an equivalent in the output format, it should try to encode the information in the output format in such a way that, when the output format is transformed into back into the original format or to another format that does have the same or equivalent information, the accessibility information can be restored to its proper function. For example, the information can be encoded as comments in the first output format, using a consistent, parsable convention that can be recognized by the authoring tool, and ideally should also be documented for use by third-party authoring and conversion tools. | AUWG: That would be nice, but may not be possible in some situations. E.g., when converting vector graphics to bitmap and back there simply is nowhere for the accessibility info to go. [ADDRESSED] | ||
OC14: In Part B, we have a concern with the use of the term “accessibility information” and wonder if the correct term is really “programmatically determinable.” The term “accessibility information” is too broad and by changing the term it helps to narrow what is being referred to. We are also concerned with the phrase “human judgment” that is used in many places. What are your expectations for this? It seems to be leading to the tool must almost supply artificial intelligence to know what to do. |
AUWG: “programmatically determinable” is a property of many things, not just things related to accessibility. E.g. the height and width of images can be programmatically determined. By “human judgment” we always mean decisions by the human author. [ADDRESSED] |
||
| 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.” | @SEE MS21 | ||
| IBM39: B.1.2.1 and B.1.2.3: the parenthetical (WCAG 2.0 Level A) and (up to WCAG 2.0 Level AAA) are critical to the provisions and should not be in parentheticals. | AUWG: We have taken a different approach to B.1.2. [ADDRESSED] | ||
| 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. | @SEE IBM39 | ||
| IBM42: B.1.2.2 and B.1.2.4: the sub-bullets don't need the word "or" at the end as it is clear from the parent provision that only one of these is required. | AUWG: We are following the WCAG 2.0 style [ADDRESSED] | ||
| 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. | AUWG: That B.2.1 reference is outdated and has been removed. [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. | @@@AUWG: JR Proposal: Change "prior to publishing" to "when published" and add this line to Intent: "The "when published" clause addresses the fact that prior to publishing, automatically generated content may not be in a form that can be checked for accessibility."
[@Proposal due from: GP] |
||
| OC17: -B.1.3 – What is the significance of “prior to publishing” in each guideline? | AUWG: It is 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. @SEE MS22 |
||
| IBM44: B.1.3 The Rationale: is not a complete sentence. (must impose, should impose, etc.) This section refers to repair tasks but does not really address what the repair tasks are other than to say that the generated content must be compliant. Seems confusing. | AUWG: If authoring tools automatically generate content that is not accessible, then additional repair tasks are imposed on authors. [ADDRESSED] | ||
| IBM45: B.1.3.1: needs to be clarified that the tool must provide a mode of operation that complies with this requirement. It should be allowed to be turned off and it should not be required to be the default at Level A. Requiring it by default would be okay at Level AAA. | AUWG: Agreed. New text: "If the authoring tool automatically generates content, then it provides the default option of having that web content meet the WCAG 2.0 success criteria when published."[ADDRESSED] | ||
| 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. |
@SEE MS22 | ||
| 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. | @AUWG: "provide support for the production of accessible content" is already a wordy term without adding a reference to WCAG. ACTION: JR to With JS to reword WCAGWG (awkward for-for, don't want to imply an extra dialog) |
| MS23: B.2.1.1 No commercial product, or even most non-commercial one, would take on the liability of claiming accessibility on behalf of a 3rd party technology. This is SC is absolutely not implementable. Please remove B.2.1.1 | @AUWG: This appears to be a misunderstanding. This SC does not require any claims about 3rd party technology. Rather, it just asks if there are accessibility supports (e.g., ability to add alternative content, checking, etc.) in the authoring tool in question for that format. We need to clarify the text. @@@MS |
||
| MS24: B.2.1.2 What happens if there some properties are set via context menu, some are set on the ribbon, and some are set in a separate dialogue? This SC implies the accessibility-related properties need to be in all of them. We believe there is an unstated assumption that all the mechanisms are interchangeable. That is not a valid assumption. Please revise B.2.1.2 | AUWG: Reworded to not imply that the mechanisms need to be directly associate:d.JR Proposal: B.2.1.2 If the authoring tool provides mechanisms to set web content properties (e.g., attribute values, etc.), then mechanisms are also provided to set web content properties related to accessibility information required to meet the WCAG 2.0 success criteria: [Implementing B.2.1.2] Note: Success Criterion B.3.2.4 addresses the prominence of the mechanisms. |
||
| MS25: B.2.1.2 “Accessibility-related properties” is undefined. Please define. | @See MS24 | ||
| 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: Agree to work in "if the content supports association of accessibility info". The read-only issue is not a concern because the association is a wrapper that doesn't affect the read-only content. JR Proposal: Remove this SC. Our best examples (alt text on images, alternate content for objects) are covered by WCAG and therefore covered in other ATAG checkpoints. |
||
GL24. MEDIUM: Low bar for B2.1.1 Decision Support. Re "B.2.1.1 Decision Support", it seems the intent is that the author should be actively warned when the authoring tool does not support accessible content creation for a specific output format, but the wording is broad enough that all the authoring tool needs to do is (a) provide a note on the Web site or buried in their documentation, and (b) provide at least one output format for which it does provide accessible content creation. The authoring tool should be required to identify less accessible formats at the points where the author chooses one. (I feel this issue is handled much better in "B.2.5.4 Template Selection Mechanism", which says "the selection mechanism indicates...") |
@AUWG: We wanted to steer away from saying there are "accessible" and "inaccessible" formats to 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? |
@AUWG: We believe that 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. |
AUWG: The definition of Technology encompasses format. The term was worked out with WCAG-WG and UAWG so we would prefer not to change it. [ADDRESSED] | ||
OC19: -B.2.1.2 – We feel this should be reworded to “At least one typical method to…” instead of “Mechanisms that…”. |
@AUWG: We disagree because “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. | @@See MS26 |
||
| 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? | @SEE WCAGWG17 | ||
| IBM48: Also, I am a bit surprised by the fact that the definition of Web Content Technology does not include things like Silverlight or Flash given that WCAG 2 applies to anything delivered over the web. W3C needs to be consistent. | AUWG: Flash is already included and we will add Silverlight. [ADDRESSED] | ||
| 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? | @See MS24 | ||
| 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 | @AUWG: We will drop "in a manner appropriate to the workflow of the authoring tool". @@We might also drop the SC, since availability is also addressed here: B.3.2 |
| MS28: B.2.2.2 What happens when there is no defined workflow? Revise SC B.2.2.2 | @See MS27 | ||
| 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 | @@@We should directly address "live authoring" (where the first submit to the authoring tool also make it live). Re: Online banking: This doesn't tend to author content for other people to consume (an imagined exception might be if a client and their advisor jointly worked on a wiki), so these are generally not considered authoring tools by ATAG's definition. AGREED. Publishing: The point at which the authors or authoring tool make web content available to end users (e.g., uploading a web page, committing a change in a wiki). |
||
| MS30: B.2.2.3 This is an AA level SC because B.2.2.1 already provides adequate guidance at A level. Move to AA. | AUWG: This is necessary at Level A since many authors will be unfamiliar with web accessibility considerations. [ADDRESSED] | ||
| MS31: B.2.2.3 AUWG needs to specify which WCAG 2.0 SCs require author judgment. Add a normative note of which SCs in WCAG 2.0 require author judgment. | AUWG: It can depend on the implementation of the check. E.g. one tool might detect single-colour images as spacers, another might require user input. The SC doesn't refer to WCAG2, it refers to whether a particular authoring tool's UI is asking the author to make a decision. [ADDRESSED] - MS: ok |
||
| MS32: B.2.2.4 This SC is AA or AAA. How is a tool supposed to help locate relevant content to meet WCAG 2.0 3.3.2 or 1.3.3, for example? This SC demands far too much intelligence from the tool to be level A. Move SC to AA or AAA. | AUWG: We have clarified that for certain types of problems, the best help in locating that a tool can provide is instructions: B.2.2.4 Help Authors Locate: For checks that require authors to decide whether a potential web content accessibility problem is correctly identified (i.e., manual checking and semi-automated checking), the relevant content is identified to the authors. (Level A) Note: Depending on the nature of the editing-view and the scope of the potential web content accessibility problem, identification might involve highlighting elements or renderings of elements, displaying line numbers, or providing instructions.[ADDRESSED] |
||
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: Proposal: B.2.2.1 Check Accessibility (WCAG Level A): If the authoring tool provides authors with the ability to add or modify web content so that any WCAG 2.0 Level A Success Criterion can be violated, then accessibility checking for those success criteria is provided. IDEA: Provide automated checks where "semantic heuristics" exist. +define |
||
GL27. MEDIUM: Clarify minimum requirements for Help Authors Decide. "Implementing Success Criterion B.2.2.3 Help Authors Decide" again may want to clarify whether simply providing instructions in the manual or online help is sufficient, without any active prompting or guiding the user during their task. If not, how can you phrase it so this is clear? |
AUWG: We have reworded to clarify that instructions are sufficient: B.2.2.3 Help Authors Decide: For checks that require authors to decide whether a potential web content accessibility problem is correctly identified (i.e., manual checking and semi-automated checking), instructions are provided from the check that describe how to make the decision. (Level A) [ADDRESSED] | ||
| 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? | @See MS29 |
||
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. |
@SEE GL27 |
||
| IBM50: B.2.2.1: I think "manual checking" is the wrong term here. The authoring tool is not doing the manual check but rather providing guidance to the author in performing the manual check. The "checking" should only be required where automated checks can be performed. | @AUWG: This term is also used by ERT in EARL. | ||
| IBM51: B.2.2 this should be a configurable item achieved through the use of a plug-in. Also, has the working group considered assisting authors who are creating DHTML content where accessibility changes dynamically during application authoring? This seems to be a gap in that authors may not be aware of. | @AUWG: This can be provided by a plug-in. In DHTML, the main difference is that checking may require the content to be rendered in real-time. | ||
| IBM52: B.2.2.4 Determining where accessibility issues are can be problematic with dynamically generated content. | @AUWG: This is definitely a challenge, but of course one that needs to be met if the resulting content is to be accessible. | ||
| 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." | AUWG: Agreed.[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. | AUWG: A checker without any further information isn't going to help most people. We will re-phrase as suggestions: "If checking (see Success Criterion B.2.2.1) can detect that a WCAG 2.0 success criterion is not met, then repair suggestion(s) are provided" [ADDRESSED] |
||
| 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. | AUWG: The point is that all authors need to be able to edit alternative content. [ADDRESSED] |
| WCAGWG20: B.2.4.2 Automated Suggestions: The use of the word "can" makes this SC sound like it's optional. "During the authoring session, the authoring tool can automatically suggest alternative content..." Suggest "can [be configured to] automatically suggest...." | AUWG: It is meant to be optional. Maybe needs more explanation as to why in the "Implementing" doc. [ADDRESSED] | ||
| GG6: B2.4.2 Automated Suggestions may be too complex to implement in an authoring tool to be a Level A requirement. I see this more as an advanced feature. In terms of Level A "must does" automated suggestion is nice to have, but not a necessary requirement for creating accessible content. If I were an authoring tool developer, I might see this requirement as too strict. This might be a Level AA requirement. B2.4.2 and B2.4.4 would be implemented together. B2.4.4 would be implemented first, to provide the reusable suggestions that would then provide data for automated suggestions. | AUWG: ATAG2 is not requiring 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.. | AUWG: Only if that type of accessibility information is editable using the tool. [ADDRESSED] | ||
| 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 | @See GG6. [ADDRESSED] | ||
| MS35: B.2.4.2 “Relevant sources” need testable definition. Please add definition. | AUWG: "Relevant sources" is just the handle. The group considers the text that follows to be testable: "The suggested 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)." [ADDRESSED] | ||
| 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. | @@ACTION to propose rewordings. @@@@ | ||
| GL13. MEDIUM: Standardize on "both of the following are true". I think the phrasing used in B.2.1.1 "both of the following are true: ... ; and ...", is clearer than that used in SC such as B.2.4.2, which only provide the subtle, trailing "; and" to tell the reader that it's an AND rather than OR clause. | AUWG: Agreed. [ADDRESSED] | ||
| GL14. MEDIUM: Clarify what authoring tool may repair. "Implementing Success Criterion B.2.4.3 Let User Agents Repair" is great but "c. Repairs are also allowed that go beyond simple text processing to directly processing images, audio or video. The intent here is to encourage progress in these rapidly advancing fields" carves out a category of exception that's not actually reflected in the normative text. In theory, the user agent has just as much access to an audio clip as the authoring tool does, and therefore could perform speech recognition itself or outsource the task to a network resource. Therefore you might want to modify the SC to explicitly make an exception for specialized or processor-intensive tasks (e.g. speech recognition to generate a text transcript or captions from an audio file). | AUWG: This is intended to be addressed by the phrasing "text value". This explained further in the Implementing doc. [ADDRESSED] | ||
GL39. MINOR: Clarify it can use metadata that will be stripped. "Implementing Success Criterion B.2.4.3 Let User Agents Repair", although you certainly don't need to, you might want to elaborate on the existing example, that in this same scenario the authoring tool would be justified in generating repair alternative content based on the image metadata if it knows that metadata will be stripped from the image before it is presented to the user agent (e.g. Facebook). |
AUWG: We will add this to the Impementing document. [ADDRESSED] | ||
GL38. MINOR: Examples for automated omit confirmation. In "Implementing Success Criterion B.2.4.2 Automated Suggestions", the second example explicitly says that the user is given an opportunity to confirm or cancel the suggestion, as is required by the SC, but the other two examples omit this step. That encourages readers to think that confirmation is not an absolute requirement (especially given that the SC's current wording makes it easy to miss the fact that the list of requirements are AND rather than OR). |
AUWG: Agreed the examples will be fixed. [ADDRESSED] | ||
GL37. MINOR: Image metadata Description is not equivalent to longdesc. Re "B.2.4.2 Automated Suggestions", "(b) Relevant Sources: The suggested alternative content is only derived from sources designed to fulfill the same purpose (e.g., suggesting the value of an image's 'description' metadata field as a long description).", if your position is that the "long description" (e.g. longdesc or aria-describedby) should be a visual description, rather than a functional description or additional instructions, then it would not do to automatically use an image's Description metadata field defined by IPTC Core/XMP metadata, as those are equivalent to IPTC-NAA IIM 4.1 "Caption/Abstract" and thus not generally used for visual descriptions. (Whether the HTML5 equivalent of aria-describedby should be limited to visual descriptions is apparently an ongoing discussion.) |
AUWG: That's why we put in (a) condition: Author Control: Authors have the opportunity to accept, modify, or reject the suggested alternative content prior to insertion. [ADDRESSED]. | ||
OC25: -B.2.4.3 – The wording of this item is really difficult to understand. It takes many times through to get an idea of what is being asked for. Recommend rewriting. |
AUWG: We have tried to reword a bit for clarity: The authoring tool does not attempt to repair alternative content for non-text content using text values that are equally available to user agents (e.g., do not use the image filename).[ADDRESSED] |
||
| IBM55: B.2.4 Techniques should cover:alt text for graphics, labels for widgets (aria-label, title attribute) and standard input controls, descriptive text as optional (longdesc, aria-describedy, etc.) |
AUWG: We will add these to the examples. | ||
| B.2.5 Assist authors with accessible templates and other pre-authored content. |
|
WCAGWG21: B.2.5.2 Provide Accessible Templates: Suggest incorporating a requirement to clearly identify accessible template options. (ex. "If the authoring tool provides templates, then there are accessible template options for a range of template uses [and accessible templates are clearly identified as such]." Another approach would be to require that they be "at least as prominent as other templates. | AUWG: This is addressed by B.2.5.4. [ADDRESSED] |
| 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? | @We're not saying that every template needs to be accessible. But rather, that at least some of the templates need to be accessible. 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. AGREED ACTION to clarify @@@@ | ||
| 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 major-issue change) @@@@ [@Proposal due from: JS] |
||
GL40. MINOR: Clarify definition of template. Re "B.2.5.1 Templates Accessible (WCAG Level A)", would a task like inserting a radio button in a WYSIWIG form editor count as using a template? If so, you might want to include it as another example as people might not think of that type of operation as being a template. You might want to clarify this in the glossary entry for template. |
AUWG: Depending on the details, this would be a template or automatically generated content, which is also covered by ATAG 2.0. [ADDRESSED] | ||
| GL31. MEDIUM: Clarify minimum for Provide Accessible Templates. "Criterion B.2.5.2 Provide Accessible Templates" strictly speaking says that the authoring tool needs to provide a minimum of two accessible templates in order to comply. If it includes ten different types of templates (e.g. themed home pages, forms, etc.) is the minimum still two total for the entire authoring tool? | AUWG: It's not perfect, but yes the minimum is two.We will add an AAA in which all templates are accessible.[ADDRESSED] | ||
OC27: - B.2.5 Several standards mention a ‘recorded accessibility status', but no advice is provided on how this is to be measured. |
@We should add some advice on this to the Implementing doc. Essentially, a WCAG 2.0 conformance test is performed on the content. AGREED ACTION |
||
| OC28: -B.2.5 – We recommend adding a Level AAA where all templates are accessible. | AUWG: Every template is at least Level-A. [ADDRESSED] |
||
| IBM56: B.2.5.1 There should be an accessible template alternative for components. Some templates may be from third parties and may be inaccessible. | AUWG: Agree that third party templates are exempt if not provided by developer: [ADDRESSED] | ||
| 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). |
@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. |
@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. | AUWG: Hard to control bad UI design. But if they start off they may NEVER get turned on.We will suggest more Implementing guidance on this point instead. [Addressed] |
| MS37: B.3.2.1, B.3.2.2, B.3.2.3 The SC assumes that there is some feature to be “turned on” which is an invalid assumption. Please add condition of “If there is a changeable on/off status for such features.” | AUWG: We will make the 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. | AUWG: We will make the change [Addressed] | ||
| GL12. MEDIUM: Deactivation warning should prompt for confirmation. "B.3.2.3 Deactivation Warning" would be more effective if it required the authoring tool to prompt for confirmation; that is, not only inform the author of the implications of their decision to turn off an accessible content support feature, but also gives them the opportunity to cancel that operation (as is shown in the example). | AUWG: We will make the change [Addressed] | ||
GL43. MINOR: Example contradicts Active by Default. In "Implementing Success Criterion B.3.2.1 Active by Default", the example is supposed to show "ALL accessible content support features turned on by default" (emphasis added), yet the dialog box shows one of those features ("U.S. Section 508") turned off. Even if you have a reason for this, the first reaction of this reader was to be puzzled, then to decide it's probably an error... |
AUWG: We will make the change [Addressed] | ||
| OC30: -B.3.2.1 – We recommend dividing this into three entries similar to B.3.1.1-B3.1.3 having one entry for each of the Level A, AA and AAA. For example, for Level A all WCAG 2.0 A accessibility features turned on by default. | AUWG: We will make the change [Addressed] |
||
| 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. | @AUWG: The idea is that they don't need to be clearly identified - they are simply worked into the routine documentation. |
| GL21. MEDIUM: Identify inaccessible practices demonstrated in documentation. In addition to B.2.4.1 requiring that a "range of examples in the documentation...demonstrate WCAG 2.0 Level A accessible authoring practices", consider adding an SC to the effect that any examples in documentation that demonstrate inaccessible authoring practices should include a warning to that effect. | @AUWG: While we can see the point, 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: Proposal: Examples in the documentation (e.g., markup, screen shots of WYSIWYG editing views) demonstrate WCAG 2.0 accessible authoring practices.
ACTION: JR to reword GL33 proposal |
| 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. |
|
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." [@Proposal due from: JR] @@@@ |
| 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. @@@@ | ||
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. | @See MS39 | ||
| 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. | @See MS39 | ||
| A.3.5 [For the authoring tool user interface] Provide text search of the content. |
|
WCAGWG24: A.3.5.1 (b): To avoid confusion with bi-directional text, consider changing the short name of this item to "Two-way." | AUWG: Agreed. [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. AGREED ACTION: add as example? MS:ok |
||
| 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)" | @We 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. ACTION AGREED | ||
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" | @WCAG20 style | ||
| 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. | @We should talk to UAWG about this. | ||
| 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. | @For A.3.6.1: change to Save all preference settings. AGREED ACTION @For A.3.6.2: change to "Accessibility Settings" AGREED ACTION |
| 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. | @A.3.6.1 applies to more than just keystrokes. e.g., that I had set my default editing zoom to 150%. AGREED | ||
| 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 major-issue change) [Addressed] | ||
| MS44: A.3.6.2 Please define “respects” or use more precise language. Please define “respects” or use more precise language | @"apply" ACTION AGREED | ||
| 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 "apply system settings as the default"? ACTION AGREED | ||
| 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. | @Are there really email clients that let you login, change the theme etc. and then fail to save that? | ||
| 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? | @@@Modify to say "system setting that are available" | ||
| A.4.1 [For the authoring tool user interface] Help users avoid and correct mistakes. |
|
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. | @We will remove A.4.1.3 and note in A.4.1.1 that it needs to be possible to undo an undo.AGREED ACTION |
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. This is a AA requirement for people with cognitive disabilities, people who have difficulty exploring UIs, etc. |
| IBM37: A.4.2.2 Does this require statements of UAAG conformance? | @We 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 major-issue). [@Proposal due from: JR] |
||
| 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 major-issue). | ||
| 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 major-issue 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 major-issue change) [@Proposal due from: JR] |
||
| 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 major-issue 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): | AUWG: Agreed. [ADDRESSED] |
| 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 major-issue 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? | AUWG: Your point is taken, but at some point we can't control bad UI design. [ADDRESSED] | ||
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. | AUWG: The group has decided this is a Level AA because... |
||
| 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. | @Would go along with a checker | ||
| 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.” | Proposal: "B.2.4.4: Suggest Previous Author Entries: If the authoring tool prompts authors for alternative content for non-text content, then both of the following are true (Level AA): |
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. |
|||
| OC26: -B.2.4.4 – We recommend making this Level AAA as this is applies equally to non- accessibility related content and moves into a product usability feature. | AUWG: Except that authors may sometimes view accessibility as “extra work” so it's more important to simplify time-intensive accessibility tasks. [ADDRESSED] |
||
| B.2.5 Assist authors with accessible templates and other pre-authored content. |
|
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. | @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 actually used it for any particular piece of pre-authored content. AGREED ACTION @@@@ |
| UAWG6: B.2.5.4: The definition for prominence says in part: For purposes of conformance to ATAG 2.0, item A is considered to be at least as prominent as item B if: both items occur in the same item container (e.g., a menu for menu items, a list for list items, a dialog box for text boxes); if item B is emphasized, then so is item A; so if the accessible option is at the bottom of a menu separated from the less accessible option by 10 entires, this is acceptable? If the list has 25 items and the user must scroll to see the accessible option, is this then acceptable? Off the topic somewhat, but the question of whether accessible options should be displayed as prominently as, and/or in proximity to, their inaccessible counterparts applies to more things than just templates (for example, a list of schemes). | AUWG: It's not perfect, but it is very difficult to get more prescriptive about the order within a container because the order is dependent on so many factors. | ||
| 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... @@@@ | ||
| 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. | @It might be just in the name, or in the keywords or in a description or a field stating whether the template had been checked for accessibility. AGREED ACTION (put these in examples) @@@@ | ||
| 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. | @At least as prominence is not the same as taking precedence. ACTION in defn of prominence change (c) to be clear it is outside of container. AGREED @@@@ | ||
| 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. | @Use them and then check the content for conformance with WCAG 2.0.@@@@ | ||
| 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. | @If that was the case, the templates could be automatically labeled as such. AGREED ACTION to add example. - we need to think about the human element. @@@@ |
||
| 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 - update examples. AGREED ACTION @@@@ | ||
| 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 major-issue)@@@@ |
| 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 major-issue 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 major-issue 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 major-issue.@@@@ | ||
| 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 | AUWG: Yes two or more. [ADDRESSED] |
| 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) | AUWG: We 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: If a presentation property for text is both rendered and editable by an editing-view, then the property can be programmatically determined. (Level AAA)[ADDRESSED] |
| 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. |
|
WCAGWG28: A.3.2.4 Content Edits Saved (Extended): Suggest revising this SC to include "automatically" (The authoring tool can be set to [automatically] save all content edits made by authors.) | AUWG: Change made.[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. |
AUWG: Proposal: Add to Intent section: "Increasing the frequency with which content edits are saved also helps authors recover more easily from inadvertent actions. " | ||
| 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. |
AUWG: Some users are aided by the ability to have multiple sets of preferences (e.g., because their vision or motor control fatigues easily). [ADDRESSED] |
| 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) | AUWG: Agreed [ADDRESSED] |
| 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. |
|
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. | @It definitely makes sense to clarify the distinction between what the developer provides and what is submitted by other users. AGREED ACTION @@@@ |
| 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. | AUWG: At AAA a template should include Alt in clip art it uses. AGREED @@@@ | ||
| 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. |
|
GL20. MEDIUM: Identify accessibility features in documentation. B.3.3 requires that features that support the production of accessible content be documented, but I would suggest adding (either as a best practice or as a new SC) that the user should be able to find a list or index of such features. This would be equivalent to UAAG 2.0's "5.3.4 Centralized View: There is a centralized view of all features of the user agent that benefit accessibility, in a dedicated section of the documentation. (Level AA)" However, in ATAG this should apply to both accessible content support features and to features that make the tool's user interface accessible. | AUWG: We have added a centralized index of documentation at AAA. Proposal: "B.3.3.X Instruction Index: The documentation contains an index to the instructions for using the accessible content support features. (AAA)"[ADDRESSED] |
| B.3.4 Ensure that any authoring practices demonstrated in documentation are accessible. |
|