WAI: Strategies, guidelines, resources to make the Web accessible to people with disabilities
Site Navigation: W3C Home > WAI Home > AUWG
The following table lists the comments received on the April 2012 Last Call Working Draft of the Authoring Tool Accessibility Guidelines (ATAG) 2.0, the responses and action taken by the Authoring Tool Accessibility Guidelines Working Group (AUWG). The columns show the text from the ATAG LCWD that prompted the comment; the text of the comment; and the responses by AUWG. The final two columns are for reporting purposes, showing how AUWG disposed of the comment and whether the person making the comment accepted the responses. Where comments or issues repeat, they reference the first instance.
The comments are sorted by commenter response then by disposition, to show the objections first (there were none), then the comments which were not accepted by AUWG. Comments from IBM and Microsoft represent multiple commenters inside the company which were presented to AUWG as an aggregated list. The comments were accepted by the member representative in AUWG.
| ATAG Text | Comments | Responses | Disposition | Commenter Response |
| General Comments | GZ1: Problem: In the document, it is stated several times that these guidelines will make authoring tools "more accessible", but without giving a reference point. The reader is left with the question "more accessible than what?". Probably, the authors don't want to claim that the guidelines make authoring tools FULLY accessible, and this is understandable. Proposed modification: "increase accessibility of ..." rather than "more accessible". |
AUWG: The reference point is, implicitly, compared with tools that do not follow any of the requirements of ATAG 2.0. The suggested wording "Increase the accessibility of..." also has the same implicit comparison point. | 1-Not accepted | 3-Accept |
| A.3.4.1 Navigate By Structure: If editing-views expose the markup elements in the web content being edited, then the markup elements (e.g., source code, content renderings) are selectable and navigation mechanisms are provided to move the selection focus between elements. (Level AA) |
IBM11: A.3.4.1 - The navigate by structure states that you can navigate among structural elements (or at least that is implied). However, Structure may be defined through ARIA attributes such as landmarks. So this section implies that structure is defined by element semantics alone and not the attributes applied. Clarification is required. | AUWG: The success criterion was not meant to imply this because it is quite difficult to quantify. The success criterion is simply that any exposed markup elements can be be leveraged to allow more efficient navigation of the markup. This could be simple tree-traversal or, as you state, something more sophisticated, such as navigation by ARIA landmark. | 1-Not accepted | 3-Accept |
| A.3.6.1 Independence of Display: If the authoring tool includes display settings for editing-views, then the authoring tool allows authors to adjust these settings without modifying the web content being edited. (Level A) |
IBM12: A.3.6.1 - seems weird to include audio and haptic settings in "display settings". | AUWG: The AUWG intends for "display" to be used in the sense of presenting information across multiple possible modes. While audio and haptic display settings are less commonly utilized, they are still valid examples. | 1-Not accepted | 3-Accept |
| B.2.2.1 Accessible Option Prominence (WCAG): If authors are provided with a choice of authoring actions for achieving the same authoring outcome (e.g., styling text), then options that will result in accessible web content (WCAG) are at least as prominent as options that will not. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria) |
GZ4: Quote: If authors are provided with a choice of authoring actions for achieving the same authoring outcome (e.g., styling text), then options that will result in accessible web content (WCAG) are at least as prominent as options that will not." Problem: What's missing here is that the authoring tool should clearly mark the accessible options vs. the inaccessible options. Cf. Guideline B.2.4.2, where this requirement is included for templates: "B.2.4.2 Identify Template Accessibility (Minimum): If the authoring tool includes a template selection mechanism and provides any non-accessible template (WCAG) options, then the templates are provided such that the template selection mechanism can display distinctions between the accessible and non-accessible options." Proposed modification: Add to B.2.2.1: "... and the options are provided such that the option selection mechanism can display distinctions between the accessible and non-accessible options." | AUWG: The Working Group has judged it infeasible to place accessibility markings throughout the interface as would probably be required to meet the suggested wording. B.2.4.2 is a special case because information about templates (e.g. their name, author, description, etc.) is already frequently displayed. | 1-Not accepted | 3-Accept |
| B.2.3.2 Conditions on Automated Suggestions: If the authoring tool automatically suggests text alternatives for non-text content during the authoring session, then the text alternatives may only be suggested under the following conditions: (Level A) (a) Author Control: Authors have the opportunity to accept, modify, or reject the suggested text alternatives prior to insertion; and (b) Relevant Sources: The suggested text alternatives are only derived from sources designed to fulfill the same purpose (e.g., suggesting the value of an image's "description" metadata field as a long description). |
IBM19: B.2.3.2 - not sure "relevant sources" is testable. Sounds very subjective. |
AUWG: "Relevant Sources" is only the handle, not the testable part of the condition. See rewording under MS3. | 1-Not accepted | 3-Accept |
| B.2.4.1 Accessible Template Options (WCAG): If the authoring tool provides templates, then there are accessible template (WCAG) options for a range of template uses. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria) |
GZ5: Quote: "If the authoring tool provides templates, then there are accessible template (WCAG) options for a range of template uses." Problem: "range" is defined as: "More than one item within a multi-item set." One template only is too few as a requirement. There should be at least one accessible template for every use case. Proposed modification: "If the authoring tool provides templates, then there are accessible template (WCAG) options for every use case." | AUWG: While the Working Group recognizes that "range" is a weak term, the Working Group considered stronger language, but no workable solution was found. For example, if we required an accessible template for every use case, would we be prepared to fail an entire tool if it included many accessible templates, but lacked one for a challenging domain, such as a calendar? The Working Group decided to use wording that clearly conveyed our intent while remaining testable. We have repeated the informative note that already appears under "Range" in the glossary ("Note: ATAG 2.0 uses the term "range" in several success criteria in which absolute measurements may not be practical (e.g., the set of all help documentation examples, the set of all templates). While the strict testable requirement is the definition "More than one item within a multi-item set", implementers are strongly encouraged to implement the success criteria more broadly.") under the intent sections of all of the SCs where it is used. |
1-Not accepted | 3-Accept |
| B.3.1.1 Checking Assistance (WCAG): If the authoring tool provides authors with the ability to add or modify web content in such a way that a WCAG 2.0 success criterion can be violated, then accessibility checking for that success criterion is provided (e.g., an HTML authoring tool that inserts images should check for alternative text; a video authoring tool with the ability to edit text tracks should check for captions). (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria) Note: Automated and semi-automated checking is possible (and encouraged) for many types of web content accessibility problems (WCAG). However, manual checking is the minimum requirement to meet this success criterion. In manual checking, the authoring tool provides authors with instructions for detecting problems, which authors must carry out by themselves. For more information on checking, see Implementing ATAG 2.0 - Appendix B: Levels of Checking Automation. |
IBM22: B.3.1.1 - change "accessibility checking for that success criterion is provided" to "accessibility checking or suggestions for manual checking for that success criterion is provided" | AUWG: The term "checking" is clearly defined as encompassing manual checking and a note is also provided as an additional measure. The problem with cutting manual checking out of the definition of accessible checking is that there is a continuous progression of increasing automation that defies easy delineation. | 1-Not accepted | 3-Accept |
| B.4.2.1 Model Practice (WCAG): A range of examples in the documentation (e.g., markup, screen shots of WYSIWYG editing-views) demonstrate accessible authoring practices (WCAG). (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria) |
GZ6: Quote: "A range of examples in the documentation (e.g., markup, screen shots of WYSIWYG editing-views) demonstrate accessible authoring practices (WCAG)." Problem: "range" is too weak. Proposed modification: "For every use case, at least one example in the documentation (e.g., markup, screen shots of WYSIWYG editing-views) demonstrates accessible authoring practices (WCAG)." | AUWG: While the Working Group recognizes that "range" is a weak term, documentation can run to hundreds of thousands of pages making a sweeping requirement very difficult to test. Instead of dropping the requirement entirely, the Working Group decided to use wording that clearly conveyed our intent while remaining testable. | 1-Not accepted | 3-Accept |
| PRINCIPLE A.1: Authoring tool user interfaces must follow applicable accessibility guidelines | IBM1: I am reading principle A and I find a very big hole in the specification. Both ARIA and HTML5 specify how content is mapped to platform accessibility service layers. If an author were to deliver "accessible" web content and the user agent is not required to support accessibility API services for a recognized platform or have built in AT that satisfy performance criteria then how can the user agent be considered accessible? In other words, despite an authors best effort the authoring tool fails to map the information to the AT. A.1.1 only talks about the authoring tool chrome. I am thinking of a browser plug-in like Policy tester. This is browser specific and so the browser must support mapping the accessible web content to the accessibility API. So, to summarize, any browser component must be able to map the accessible content in the authoring tool to the accessibility API. ... or does hidden content refer to alt text. Hidden should be a glossary item to be clear. What I think we need to do is say that if tool consists of web content then you must also be operable in a browser that supports your content in the form of accessibility services | AUWG: The Working Group understands this comment to be saying that WCAG conformance is only part of the requirement and that that the missing part is a requirement along the lines of "Web-based user interfaces must be usable on user agents that implement communication with platform accessibility services." This make sense, however, there is much more to user agent accessibility than API communication, so the Working Group has decided to leave requirements in this area to UAAG 2.0. To provide clarification, the following text will be added to the relevant (informative) intent sections: "For A.1.1.1: Note: Even when a web-based user interface has met the requirements of WCAG 2.0, many factors will determine the accessibility of any particular end-user's experience, including (but not limited to): the features and settings of the end-user's user agent, platform, and assistive technology (if any). It is recommended, therefore, that developers of web-based authoring tools be familiar with the accessibility guidance that the User Agent Accessibility Guidelines (UAAG) provides to the developers of user agents. At the time of publication, UAAG version 1.0 is a W3C Recommendation and version 2.0 is under development. For A.1.2.1: (Proposed) Note 2 (to follow the existing Note): Even when a non-web-based user interface has followed the relevant user interface accessibility guidelines for the platform, many factors will determine the accessibility of any particular end-user's experience, including (but not limited to): the features and settings of the platform and assistive technology (if any). For A.1.2.2: (Proposed) Note 2 (to follow the existing Note): Even when a non-web-based user interface has been designed to expose accessibility information through platform accessibility services, many factors will determine the accessibility of any particular end-user's experience, including (but not limited to): the features and settings of the platform and assistive technology (if any). " |
2-Partial accept | 3-Accept |
| B.2.3.1 Alternative Content is Editable (WCAG): If the authoring tool provides functionality for adding non-text content, then authors are able to modify programmatically associated text alternatives for non-text content. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria) |
IBM18: B.2.3.1 - if the tool supports inserting a video, then this requirement means the authoring tool has to provide a way to add/edit captions and video descriptions? | AUWG: No. Text alternatives to non-text content are defined as: "text alternatives for non-text content: Text that is programmatically associated with non-text content or referred to from text that is programmatically associated with non-text content. For example, an image of a chart might have two text alternatives: a description in the paragraph after the chart and a short text alternative for the chart indicating in words that a description follows." Captions and audio descriptions are instead types of "alternatives for time-based media", which is the next defined term in the glossary. | 3-Question | 3-Accept |
| B.4.1.1 Features Active by Default: All accessible content support features are turned on by default. (Level A) |
IBM17: B.4.1.1 - Are you sure you want authoring prompting turned on by default? That is heavy weight. You do say *All* | AUWG: Whether it is heavyweight depends on the design of the prompting. Unobtrusive error detection, such as the red-underlining frequently employed for spell checking is often turned on by default. | 3-Question | 3-Accept |
| A.1.2.1 Accessibility Guidelines: If the authoring tool contains non-web-based user interfaces, then those non-web-based user interfaces follow user interface accessibility guidelines for the platform. (Level A) Note: The (optional) explanation of conformance claim results should record the user interface accessibility guidelines that were followed. |
IBM2: A.1.2.1 - requires following user interface accessibility guidelines for the platform. Should also accept international standards such as ISO 9241-171 or government standards such as Section 508. | AUWG: The Working Group intended that developers should be able to follow such standards, but it may not be clear from the current Intent section, so this section will be modified as follows: "...Unless special circumstances exist (e.g., a document has been superseded, the platform has undergone major architectural changes), the listed resources should be assumed to be relevant to the platforms listed. Several general software accessibility guidelines are also referenced. It is acceptable to follow one of these sources of general guidance, and in most cases, the techniques for implementing the general guidance on a platform will entail following the same platform accessibility guidelines." |
4-Accepted | 3-Accept |
| A.1.2.2 Platform Accessibility Services: If the authoring tool contains non-web-based user interfaces, then those non-web-based user interfaces implement communication with platform accessibility services. (Level A) Note: The (optional) explanation of conformance claim results should record the platform accessibility service(s) that were implemented. |
IBM3: A.1.2.2 - requires software to implement "communication with platform accessibility services" - seems like this should be tied to the concept of "programmatically determined" somehow. I'm not sure communicate "with" platform accessibility services is the right concept. Isn't it more like "using" accessibility services. And finally, it should just say "accessibility services", not "platform accessibility services" to allow for IAccessible2 implementations. Accessibility services are provided by platforms most of the time but where platform accessibility services fall short, other implementations that fill the gaps, such as IAccessible2, should be allowed. | AUWG: There are several points made in the comment: Re: tying communication with platform accessibility services with programmatically determined, it is already tied by a reference to "platform accessibility service" in "programmatically determined". Re: "communicate with", vs "using": The Working Group feels that "using" is too vague and instead proposes: "Platform Accessibility Services: If the authoring tool contains non-web-based user interfaces, then those non-web-based user interfaces expose accessibility information through platform accessibility services." Re: "platform accessibility service": The Working Group is concerned that that term is too vague. The definition should make it clear that IAccessible2 is covered and in fact IAccessible 2 is an example. |
4-Accepted | 3-Accept |
| A.2.2.1 Editing-View Status Indicators: If an editing-view adds status indicators to the content being edited, then the status messages being indicated can be programmatically determined. (Level A) Note: Status indicators may indicate errors (e.g., spelling errors), tracked changes, hidden elements, or other information. |
IBM4: Why does A.2.2.1 include hidden elements? Please elaborate. Hidden content is often dirty and not ready for consumption. Is it referring to alt text? The solution is editorial but important and it is something we have had to address in ARIA and HTML 5 too. |
"Time Limit: The amount of time that an authoring tool provides to an author to perform a task (e.g., read a message, select an item, save a change). Examples include: authoring session timeouts, time-based presentations (e.g. tutorial video)." | 4-Accepted | 3-Accept |
| A.2.2.1 Editing-View Status Indicators: If an editing-view adds status indicators to the content being edited, then the status messages being indicated can be programmatically determined. (Level A) Note: Status indicators may indicate errors (e.g., spelling errors), tracked changes, hidden elements, or other information. |
IBM5: A.2.2.1 - "status messages being indicated" is very odd wording. I only understood this when I read the implementing information. Now that I know what it is, I suggest "information being conveyed by the status indicators" instead. | AUWG This change has been made: “information being conveyed by the status indicators can be programmatically determined.” | 4-Accepted | 3-Accept |
| PRINCIPLE A.3: Editing-views must be operable | IBM6: A.3. - While I understand you are adapting this for WCAG 2 which requires keyboard access we have a general problem in that most mobile browsers do not respond to keyboard input. So, this is a gap in WCAG and ATAG. The 508 refresh punts this a bit in that it uses functional performance criteria as a round about way to address the problem. I don't think that is a great solution either. In short, we can't always assume a keyboard. We need something on the order of allowing users to be able to control navigation using device independent means. ... We need to work this now or in an ATAG 2.1 refresh but this is a significant gap for mobile. The good thing is that there are not a lot of mobile web app authoring tools out there. A.3.1., A.3.1.1, A.3.1.2 - these are already covered in WCAG which is required by A.1.1.1. If these are for non-Web based authoring tools, then they should be scoped to such tools. | AUWG: This point was discussed at length within the group in light of the fact that most smart phones do in fact include keyboard control (iOS devices can be controlled by an external Bluetooth keyboard - http://support.apple.com/kb/HT4112, Android devices can be controlled with a D-Pad (or D-pad emulator), many BlackBerry devices include physical keyboards and support keyboard shortcuts). The discussion led to the following note on A.3.1.1: "Note 1: Keyboard interfaces are programmatic services provided by many platforms that allow operation in a device independent manner. This success criterion does not imply the presence of a hardware keyboard." | 4-Accepted | 3-Accept |
| Guideline A.3.1: (For the authoring tool user interface) Provide keyboard access to authoring features. | IBM7: A.3.1 - all of these are about keyboard operation which used to be the "device independent" way of providing input. But now that we know we have devices without keyboards that might have some other kind of device independent input mechanism, should we go ahead and fix this even though WCAG also has the problem? | AUWG: See the response to IBM6. | 4-Accepted | 3-Accept |
| A.3.1.3 Efficient Keyboard Access: The authoring tool user interface includes mechanisms to make keyboard access more efficient than sequential keyboard access. (Level AA) |
IBM8: A.3.1.3 - the example in the "implementing" material uses links as the example. Suggest using landmarks instead of links. | AUWG: Good idea, this example has been updated: "In a web-based environment: A web-based CMS uses WAI-ARIA landmarks (e.g., banner, main, navigation, search, etc.) to allow authors to navigate more quickly." |
4-Accepted | 3-Accept |
| A.3.2.2 Timing Adjustable: If a time limit is set by the authoring tool, then at least one of the following is true: (Level A) (a) Turn Off: Authors are allowed to turn off the time limit before encountering it; or (b) Adjust: Authors are allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or (c) Extend: Authors are warned before time expires and given at least 20 seconds to extend the time limit with a simple action (e.g., "press the space bar"), and authors are allowed to extend the time limit at least ten times; or (d) Real-time Exception: The time limit is a required part of a real-time event (e.g., a collaborative authoring system), and no alternative to the time limit is possible; or (e) Essential Exception: The time limit is essential and extending it would invalidate the activity; or (f) 20 Hour Exception: The time limit is longer than 20 hours. |
IBM9: A.3.2.2 - the Timing Adjustable requirement is already in WCAG so this is a duplicate. If intended for non-web based UIs, then add an appropriate scope statement. | AUWG: Rather than adding additional text to scope the success criterion, a note already appears in the intent: "Web-based authoring tools will already be required to meet this success criterion as part of a Success Criterion A.1.1.1." which is the requirement for web-based user interfaces to follow WCAG 2.0. | 4-Accepted | 3-Accept |
| A.3.2.2 Timing Adjustable: If a time limit is set by the authoring tool, then at least one of the following is true: (Level A) (a) Turn Off: Authors are allowed to turn off the time limit before encountering it; or (b) Adjust: Authors are allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or (c) Extend: Authors are warned before time expires and given at least 20 seconds to extend the time limit with a simple action (e.g., "press the space bar"), and authors are allowed to extend the time limit at least ten times; or (d) Real-time Exception: The time limit is a required part of a real-time event (e.g., a collaborative authoring system), and no alternative to the time limit is possible; or (e) Essential Exception: The time limit is essential and extending it would invalidate the activity; or (f) 20 Hour Exception: The time limit is longer than 20 hours. |
IBM10: A.3.2.2 - So, if timing is not adjustable you are saying that you don't need to have one? I think you need a glossary item on what it means to have a timing limit. e.g. a timeout, a refresh rate, a frame play rate (slowing up and speeding out a video) etc. Again, I understand what you want but you need a glossary item to be prescriptive. | AUWG: WCAG 2.0 does not include a definition of Time Limit, but in the interest of clarity, the Working Group has added one to ATAG 2.0: | 4-Accepted | 3-Accept |
| A.3.5.1 Text Search: If the authoring tool provides an editing-view of text-based content, then the editing-view enables text search, such that all of the following are true: (Level AA) (a) All Editable Text: Any text content that is editable by the editing-view is searchable (including alternative content); and (b) Match: Matching results can be made visible to authors and given focus; and (c) No Match: Authors are informed when no results are found; and (d) Two-way: The search can be made forwards or backwards. |
GZ2: Quote: "(b) Match: Matching results can be made visible to authors and given focus". Problem: The words "made visible" should be changed to "presented", in order not to give the impression that the presentation of search results should be presented in visual form only. | AUWG: This change has been made: (b) Match: Matching results can be presented to authors and given focus" |
4-Accepted | 3-Accept |
| A.3.7.1 Preview (Minimum): If a preview is provided, then at least one of the following is true: (Level A) (a) In-Market User Agent: The preview renders content using a user agent that is in-market; or (b) UAAG (Level A): The preview conforms to the User Agent Accessibility Guidelines 1.0 Level A [UAAG]. |
GZ3: Quote: "Guideline A.3.7: (For the authoring tool user interface) Ensure that previews are at least as accessible as in-market user agents." Problem: The word "in-market" is not defined which makes this guideline rather fuzzy and hard to test. Proposed modification: Add a glossary entry for "in-market user agents". IBM13: A.3.7.1 - Provide a glossary definition for in-market. |
AUWG: The following changes will be made to the "User Agent" glossary entry: User agent: Any software that retrieves, renders and facilitates end user interaction with web content (e.g. web browsers, browser plug-ins, and media players). - In-Market User Agent: A user agent, that can be procured by members of the public (free or otherwise). Usually, an in-market user agent will be a separate software from the authoring tool, however, sometimes a software may combine user agent and authoring tool functionality. These cases include: - Preview-Only: If the user agent can only render web content that it receives from the associated authoring functionality, then the software is an authoring tool with a "preview" feature. Such preview-only features are not considered in-market user agents. - User Agent with Authoring Tool Mode: If the user agent functionality must retrieve and open web content before it can be sent to the authoring tool functionality, then the software is a user agent with an authoring tool mode. If the user agent is used to "preview" content produced by the authoring tool mode, then it is to be considered an in-market user agent. - Combined User Agent/Authoring Tool: A user agent in which the default mode of user interaction enables editing the web content. These tools do not need previews because the author is already experiencing the content in the same way as end users. And the following entry will be changed: "previews: Views in which no authoring actions are provided (i.e., the view is not editable). Previews are provided to present the web content being edited by the authoring tool as it would appear to end users of user agents. Previews may be implemented using actual in-market user agents, but this is not necessary. See the defintion of user agent for more information. And the following will be added to note #5 in the introduction. "User Agent Accessibility Guidelines (UAAG) Overview (This will be of special interest to developers of "Combined User Agent/Authoring Tools" and "User Agents with Authoring Tool Modes"). AUWG: See response to GZ3. |
4-Accepted | 3-Accept |
| A.3.7.1 Preview (Minimum): If a preview is provided, then at least one of the following is true: (Level A) (a) In-Market User Agent: The preview renders content using a user agent that is in-market; or (b) UAAG (Level A): The preview conforms to the User Agent Accessibility Guidelines 1.0 Level A [UAAG]. |
GZ3: Quote: "Guideline A.3.7: (For the authoring tool user interface) Ensure that previews are at least as accessible as in-market user agents." Problem: The word "in-market" is not defined which makes this guideline rather fuzzy and hard to test. Proposed modification: Add a glossary entry for "in-market user agents". IBM13: A.3.7.1 - Provide a glossary definition for in-market. |
See GZ3 | 4-Accepted | 3-Accept |
| Guideline B.1.1: Ensure automatically specified content is accessible. | MS1: Please simplify or clarify B.1.1 "Rationale: If authoring tools automatically specify web content with accessibility problems (WCAG), then additional repair tasks are imposed on authors." We found the wording confusing. | AUWG: The Working Group has changed the wording to: B.1.1 "Rationale: If authoring tools automatically produce web content that includes accessibility problems (WCAG), then this will impose additional repair tasks on authors." |
4-Accepted | 3-Accept |
| B.1.2.2 Copy-Paste Inside Authoring Tool (WCAG): If the authoring tool supports copy and paste of structured content, then any accessibility information (WCAG) in the copied content is preserved when the authoring tool is both the source and destination of the copy-paste. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria) |
IBM16: B.1.2.2 - So, when copying to the clipboard, each platform has standards for formatted content in the clipboard. What happens if the those formats do not support the accessibility information? ... In other words it *may* not be possible. | AUWG: The following clarification will be added: "If the authoring tool supports copy and paste of structured content, then any accessibility information (WCAG) in the copied content is preserved when the authoring tool is both the source and destination of the copy-paste and the source and destination use the same web content technology." |
4-Accepted | 3-Accept |
| B.1.2.2 Copy-Paste Inside Authoring Tool (WCAG): If the authoring tool supports copy and paste of structured content, then any accessibility information (WCAG) in the copied content is preserved when the authoring tool is both the source and destination of the copy-paste. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria) |
IBM14: B.1.2.2 need the phrase "if equivalent mechanisms exist in the web content technology of the output" and the Note that the success criteria only applies when the output technology is "included" for conformance. |
AUWG: The following clarification will be added: "If the authoring tool supports copy and paste of structured content, then any accessibility information (WCAG) in the copied content is preserved when the authoring tool is both the source and destination of the copy-paste and the source and destination use the same web content technology." |
4-Accepted | 3-Accept |
| B.1.2.3 Optimizations Preserve Accessibility: If the authoring tool provides optimizing web content transformations, then any accessibility information (WCAG) in the input is preserved in the output. (Level A). |
IBM15: B.1.2.3 need the phrase "if equivalent mechanisms exist in the web content technology of the output" and the Note that the success criteria only applies when the output technology is "included" for conformance. | AUWG: Optimizations do not involve any change in format. The definition is: "Optimizing Content Transformations: Transformations in which the content technology is not changed and the structural features of the content technology that are employed also stay the same. Changes would not be expected to result in information loss (e.g., removing whitespace, replacing in-line styles with an external stylesheet)." | 4-Accepted | 3-Accept |
| B.2.3.1 Alternative Content is Editable (WCAG): If the authoring tool provides functionality for adding non-text content, then authors are able to modify programmatically associated text alternatives for non-text content. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria) |
MS2: It would be helpful to have exception for B.2.3.1 in the case of CAPTCHA, decorative, formatting, and invisible images. | AUWG: A note will be added as follows: "B.2.3.1 Alternative Content is Editable (WCAG): If the authoring tool provides functionality for adding non-text content, then authors are able to modify programmatically associated text alternatives for non-text content. Note: An exception can be made when non-text content is known to be decoration, formatting, invisible or a CAPTCHA." | 4-Accepted | 3-Accept |
| B.2.3.2 Conditions on Automated Suggestions: If the authoring tool automatically suggests text alternatives for non-text content during the authoring session, then the text alternatives may only be suggested under the following conditions: (Level A) (a) Author Control: Authors have the opportunity to accept, modify, or reject the suggested text alternatives prior to insertion; and (b) Relevant Sources: The suggested text alternatives are only derived from sources designed to fulfill the same purpose (e.g., suggesting the value of an image's "description" metadata field as a long description). |
MS3: The wording "text alternatives may only be suggested under the following conditions" under B.2.3.2 makes it sounds like text alternative suggestion is not a good practice. Please make minor reword to remove the negative connotation. | AUWG: The Working Group agrees that this could be clarified and that the stem text should change to better synch with B.2.3.3 (the style also follows that employed for the stems of B.1.1.1 and B.1.1.2). The text has been reworded as follows: "Repair of Text Alternatives During Authoring Sessions: If the authoring tool attempts to automatically or semi-automatically repair text alternatives for non-text content ("repair strings") during an authoring session, then the following are both true: (Level A) (a) Suitable Text Sources: Repair strings are only ever derived from text sources designed to fulfill the same purpose as the text alternative (e.g., suggesting an image's "description" metadata field as a long description). Other text attributes (e.g., the file name, file format) or generic strings (e.g. "image") are not used; and (b) Author Control: Authors have the opportunity to accept, modify, or reject the repair strings prior to insertion in the content. Question for AUWG members: Should contextual information and pattern recognition be allowed? In which case B.2.3.2 and B.2.3.3 might be combined. |
4-Accepted | 3-Accept |
| B.2.3.3 Let User Agents Repair: If the authoring tool provides automatic repair of text alternatives for non-text content after the end of an authoring session, then the authoring tool avoids using text values that would also be available to user agents. (Level A) Note: Examples of text values that are also available to user agents, and should be avoided, include the filename, the file format, and generic phrases (e.g. "image"). |
MS4: The text for B2.3.3 still requires improvements. Text value for text alternative is, by definition, available to user agents-making this SC rather illogical. |
AUWG: The Working Group agrees and will use the more familiar term "text string". See rewording under MS3. |
4-Accepted | 3-Accept |
| B.2.3.3 Let User Agents Repair: If the authoring tool provides automatic repair of text alternatives for non-text content after the end of an authoring session, then the authoring tool avoids using text values that would also be available to user agents. (Level A) Note: Examples of text values that are also available to user agents, and should be avoided, include the filename, the file format, and generic phrases (e.g. "image"). |
IBM20: B.2.3.3 - why is this requirement limited to automatic repair of text alternatives "after the end of an authoring session". Seems like it is also relevant if the repair is being done during the authoring session. | AUWG: The Working Group intends B.2.3.2 to handle the "During" case, however, the success criterion has been reworded for clarity: B.2.3.3 Repair of Text Alternatives After Authoring Sessions: If the authoring tool attempts to automatically repair text alternatives for non-text content after an authoring session has ended, then it must not do so from text sources that are otherwise still available to user agents (e.g. the file name, metadata stored in non-text content) or generic text strings (e.g., "image"). Note: Examples of acceptable repair strings include those derived from contextual information (e.g., that an image is the author's profile picture) or from performing pattern recognition on the non-text content. (Level A) |
4-Accepted | 3-Accept |
| B.2.5.1 Pre-Authored Content Selection Mechanism: If authors are provided with a selection mechanism for pre-authored content other than templates (e.g., clip art gallery, widget repository, design themes), then both of the following are true: (Level AA) (a) Indicate: The selection mechanism indicates the accessibility status of the pre-authored content (if known); and (b) Prominence: Any accessible (WCAG) options are at least as prominent as other pre-authored content options. |
IBM21: B.2.5.1 - requires the pre-authored content selection mechanism to display the accessibility status of the pre-authored content. But the example is a clip art repository that displays the alt text associated with each clip art object. "alt text" is accessibility information but it is not the accessibility status. | AUWG: A note will be added: Note: The nature of the accessibility status indicator is not specified and will depend on the type of content. For example, a widget gallery might indicate a WCAG 2.0 conformance level for each widget, while a clip-art gallery might simply indicate whether an alt text string is provided for each image. |
4-Accepted | 3-Accept |
| B.4.1.3 Feature Availability Information: If the authoring tool supports production of any web content technologies for publishing for which the authoring tool does not provide support for the production of accessible web content (WCAG), then this is documented. (Level AA) Note: This success criterion concerns the presence or absence of support features, such as accessibility checkers, not any intrinsic property of web content technologies. |
IBM23: B.4.1.3 - requires tools that do not comply with the requirements of Part B to document the fact that they don't comply. There is no leverage to get a tool developer to do this. If they document that they don't comply, they still don't comply. | AUWG: This success criterion was actually added by the Working Group to increase flexibility for developers. Instead of requiring that tools support accessibility for all of the formats they might output, then only need to support accessibility for one format and then document the fact that accessibility support is not offered for the other formats. | 4-Accepted | 3-Accept |
Skip to Content 