[DRAFT-TEXT]: Addressed by a proposal
[APPROVED] Response approved by WG.
Where issues repeat, we link to the first instance.
| Comments | Responses | |
|---|---|---|
| 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?".
|
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. [APPROVED] |
| Part A: Conformance Applicability Note: Scope of "authoring tool user interface": 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 (e.g., menus, button bars, status bars, user preferences, documentation). | ||
| Part A: Conformance Applicability Note: Reflected content accessibility problems: The authoring tool is responsible for ensuring that editing-views display the web content being edited in a way that is more accessible to authors with disabilities (e.g., ensuring that text alternatives in the content can be programmatically determined). However, where an authoring tool user interface 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. | ||
| Part A: Conformance Applicability Note: Developer control: The Part A success criteria only apply to the authoring tool user interface as it is provided by the developer. They do not apply to any subsequent modifications by parties other than the authoring tool developer (e.g., user modifications of default settings, third-party plug-ins). | ||
| Part A: Conformance Applicability Note: User agent features: Web-based authoring tools may rely on user agent features (e.g., keyboard navigation, find functions, display preferences, undo features) to satisfy success criteria. Conformance claims are optional, but any claim that is made must record the user agent(s). | ||
| Part A: Conformance Applicability Note: Accessibility of features provided to meet Part A: 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). The only exemption is for preview features, as long as they meet the relevant success criteria in 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 functionality of user agents that are actually in use by end users. | ||
| Part A: Conformance Applicability Note: Unrecognizable content: When success criteria require authoring tools to treat web content according to semantic criteria, the success criteria do not apply when these semantics are missing (e.g., text that describes an image is only considered to be a text alternative when this role is encoded within markup). | ||
| Part B: Conformance Applicability Note: Author availability: Any Part B success criteria that refer to authors only apply during authoring sessions. | ||
| Part B: Conformance Applicability Note: Developer control: The Part B success criteria only apply to the authoring tool as it is provided by the developer. This does not include subsequent modifications by parties other than the authoring tool developer (e.g., third-party plug-ins, user-defined templates, user modifications of default settings). | ||
| Part B: Conformance Applicability Note: Applicability after the end of an authoring session: Authoring tools are responsible for the web content accessibility (WCAG) of web content that they automatically generate after the end of an author's authoring session (see Success Criterion B.1.1.1). 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 causes, whether it is author-generated or automatically-generated by another system that the author has specified (e.g., a third-party feed). | ||
| Part B: Conformance Applicability Note: 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 tool). | ||
| Part B: Conformance Applicability Note: Accessibility of features provided to meet Part B: The Part A success criteria apply to the entire authoring tool user interface, including any features that must be present to meet the success criteria in Part B (e.g., checking tools, repair tools, tutorials, documentation). | ||
| Part B: Conformance Applicability Note: Multiple authoring 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 authoring role. Accessible content support features should be made available to any authoring role where it would be useful. | ||
| Part B: Conformance Applicability Note: Unrecognizable content: When success criteria require authoring tools to treat web content according to semantic criteria, the success criteria do not apply when these semantics are missing (e.g., text that describes an image is only considered to be a text alternative when this role is encoded within markup). | ||
| PART A: Make the authoring tool user interface accessible | ||
| 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). " [APPROVED] |
| Guideline A.1.1: (For the authoring tool user interface) Ensure that web-based functionality is accessible. | ||
A.1.1.1 Web-Based Accessible (WCAG):If the authoring tool contains web-based user interfaces, then those web-based user interfaces meet the WCAG 2.0 success criteria. (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) |
||
| Guideline A.1.2: (For the authoring tool user interface) Ensure that non-web-based functionality is accessible. | ||
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)
|
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." [APPROVED] |
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)
|
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.[APPROVED] |
| PRINCIPLE A.2: Editing-views must be perceivable | ||
| Guideline A.2.1: (For the authoring tool user interface) Make alternative content available to authors. | ||
A.2.1.1 Text Alternatives for Rendered Non-Text Content:If an editing-view renders non-text content, then any programmatically associated text alternatives for the non-text content can be programmatically determined. (Level A) |
||
A.2.1.2 Alternatives for Rendered Time-Based Media:If an editing-view renders time-based media, then at least one of the following is true: (Level A)
|
||
| Guideline A.2.2: (For the authoring tool user interface) Editing-view presentation can be programmatically determined. | ||
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)
|
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. 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: It is not the "hidden elements", themselves, that are targeted by the success criterion, but rather status indicators placed into the authoring tool user interface by the authoring tool. For example, a WYSIWYG authoring tool might insert an icon to remind authors of the location of an anchor or a comment. The Working Group will clarify this with the following sentence in the intent: AUWG: The Working Group agrees with the wording suggestion: |
A.2.2.2 Access to Rendered Text Properties:If an editing-view renders any text formatting properties that authors can also edit using the editing-view, then the properties can be programmatically determined. (Level AA) |
||
| 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." [APPROVED] |
| 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. [APPROVED] |
A.3.1.1 Keyboard Access (Minimum):All functionality of the authoring tool is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. (Level A)
|
||
A.3.1.2 No Keyboard Traps:If keyboard focus can be moved to a component using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, authors are advised of the method for moving focus away. (Level A) |
||
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." [APPROVED] |
A.3.1.4 Keyboard Access (Enhanced):All functionality of the authoring tool is operable through a keyboard interface without requiring specific timings for individual keystrokes. (Level AAA) |
||
A.3.1.5 Customize Keyboard Access:If the authoring tool includes keyboard commands, then those keyboard commands can be customized. (Level AAA) |
||
A.3.1.6 Present Keyboard Commands:If the authoring tool includes keyboard commands, then the authoring tool provides a way for authors to determine the keyboard commands associated with authoring tool user interface components. (Level AAA) |
||
| Guideline A.3.2: (For the authoring tool user interface) Provide authors with enough time. | ||
A.3.2.1 Auto-Save (Minimum):If the authoring tool includes authoring session time limits, then the authoring tool can be set to automatically save web content edits made using the authoring tool before the session time limits are reached. (Level A) |
||
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)
|
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. 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: 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. [APPROVED] 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: |
A.3.2.3 Static Input Components:If authoring tool user interface components accept input and move, then authors can pause the movement. (Level A) |
||
A.3.2.4 Content Edits Saved (Extended):The authoring tool can be set to automatically save web content edits made using the authoring tool. (Level AAA) |
||
| Guideline A.3.3: (For the authoring tool user interface) Help authors avoid flashing that could cause seizures. | ||
A.3.3.1 Static View Option:If the authoring tool contains editing-views that render visual time-based content, then those editing-views can be paused and can be set to not play automatically. (Level A) |
||
| Guideline A.3.4: (For the authoring tool user interface) Enhance navigation and editing via content structure. | ||
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. [APPROVED] |
A.3.4.2 Navigate by Programmatic Relationships:If editing-views allow editing of programmatic relationships within web content, then mechanisms are provided that support navigation between the related content. (Level AAA)
|
||
| Guideline A.3.5: (For the authoring tool user interface) Provide text search of the content. | ||
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)
|
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" [APPROVED] |
| Guideline A.3.6: (For the authoring tool user interface) Manage preference settings. | ||
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. [APPROVED] |
A.3.6.2 Save Settings:If the authoring tool includes display and/or control settings, then these settings can be saved between authoring sessions. (Level AA) |
||
A.3.6.3 Apply Platform Settings:The authoring tool respects changes in platform display and control settings, unless authors select more specific display and control settings using the authoring tool. (Level AA) |
||
A.3.6.4 Multiple Sets:If the authoring tool includes display and/or control settings, then the authoring tool provides the option of saving and reloading multiple configurations of settings. (Level AAA) |
||
| Guideline A.3.7: (For the authoring tool user interface) Ensure that previews are at least as accessible as in-market user agents. | ||
A.3.7.1 Preview (Minimum):If a preview is provided, then at least one of the following is true: (Level A)
|
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: And the following entry will be changed: AUWG: See response to GZ3. [APPROVED] |
A.3.7.2 Preview (Enhanced):If a preview is provided, then authors can specify which user agent performs the preview. (Level AAA) |
||
| PRINCIPLE A.4: Editing-views must be understandable | ||
| Guideline A.4.1: (For the authoring tool user interface) Help authors avoid and correct mistakes. | ||
A.4.1.1 Content Changes Reversible (Minimum):All authoring actions are either reversible or the authoring tool requires author confirmation to proceed. (Level A) |
||
A.4.1.2 Settings Change Confirmation:If the authoring tool provides mechanisms for changing authoring tool user interface settings, then those mechanisms can reverse the setting changes, or the authoring tool requires author confirmation to proceed. (Level A) |
||
A.4.1.3 Content Changes Reversible (Enhanced):Authors can sequentially reverse a series of reversible authoring actions. (Level AAA)
|
||
| Guideline A.4.2: (For the authoring tool user interface) Document the user interface including all accessibility features. | ||
A.4.2.1 Describe Accessibility Features:For each authoring tool feature that is used to meet Part A of ATAG 2.0, at least one of the following is true: (Level A)
|
||
A.4.2.2 Document All Features:For each authoring tool feature, at least one of the following is true: (Level AA)
|
||
| PART B: Support the production of accessible content | ||
| PRINCIPLE B.1: Fully automatic processes must produce accessible content | ||
| 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." [APPROVED] |
B.1.1.1 Content Auto-Generation After Authoring Sessions (WCAG):If the authoring tool provides the functionality for automatically generating web content after the end of an authoring session, authors can specify that the content be accessible web content (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)
|
||
B.1.1.2 Content Auto-Generation During Authoring Sessions (WCAG):If the authoring tool provides the functionality for automatically generating web content during an authoring session, then at least one of the following is true: (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)
|
||
| Guideline B.1.2: Ensure accessibility information is preserved. | ||
B.1.2.1 Restructuring and Recoding Transformations (WCAG):If the authoring tool provides restructuring transformations or re-coding transformations, and if equivalent mechanisms exist in the web content technology of the output, then at least one of the following is true: (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)
|
||
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. 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: AUWG: ATAG 2.0 has introduced a new conformance type for such situations: "Partial ATAG 2.0 Conformance - Platform Limitations (Level A, AA, or AAA) This conformance option may be selected when an authoring tool is unable to meet one or more success criteria because of intrinsic limitations of the platform (e.g., lacking a platform accessibility service). The (optional) explanation of conformance claim results should explain what platform features are missing." [APPROVED] |
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)." [APPROVED] |
B.1.2.4 Text Alternatives for Non-Text Content are Preserved:If the authoring tool provides web content transformations that preserve non-text content in the output, then any text alternatives for that non-text content are also preserved, if equivalent mechanisms exist in the web content technology of the output. (Level A).
|
||
| PRINCIPLE B.2: Authors must be supported in producing accessible content | ||
| Guideline B.2.1: Ensure accessible content production is possible. | ||
B.2.1.1 Accessible Content Possible (WCAG):If the authoring tool places restrictions on the web content that authors can specify, then those restrictions do not prevent WCAG 2.0 success criteria from being met. (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) |
||
| Guideline B.2.2: Guide authors to produce accessible content. | ||
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. [APPROVED] |
B.2.2.2 Setting Accessibility Properties (WCAG):If the authoring tool provides mechanisms to set web content properties (e.g., attribute values), then mechanisms are also provided to set web content properties related to accessibility information (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)
|
||
| Guideline B.2.3: Assist authors with managing alternative content for non-text content. | ||
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. 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: A note will be added as follows: 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. [APPROVED] |
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)
|
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. IBM19: B.2.3.2 - not sure "relevant sources" is testable. Sounds very subjective.
|
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). @@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. AUWG: "Relevant Sources" is only the handle, not the testable part of the condition. See rewording under MS3. [APPROVED] |
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)
|
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. 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 agrees and will use the more familiar term "text string". See rewording under MS3. @@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.4 Save for Reuse:
If the authoring tool provides the functionality for adding non-text content, when authors enter programmatically associated text alternatives for non-text content, then both of the following are true: (Level AAA)
|
||
| Guideline B.2.4: Assist authors with accessible templates. | ||
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. [APPROVED] |
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. (Level AA)
|
||
B.2.4.3 Author-Created Templates:If the authoring tool includes a template selection mechanism and allows authors to create new non-accessible templates (WCAG), then authors can enable the template selection mechanism to display distinctions between accessible and non-accessible templates that they create. (Level AA)
|
||
B.2.4.4 Identify Template Accessibility (Enhanced):If the authoring tool provides any non-accessible templates (WCAG) options and does not include a template selection mechanism, then the non-accessible templates include accessibility warnings within the templates. (Level AAA) |
||
| Guideline B.2.5: Assist authors with accessible pre-authored content. | ||
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)
|
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. [APPROVED] |
B.2.5.2 Pre-Authored Content Accessibility Status:If the authoring tool provides a repository of pre-authored content, then each of the content objects has a recorded accessibility status. (Level AAA) |
||
| PRINCIPLE B.3: Authors must be supported in improving the accessibility of existing content | ||
| Guideline B.3.1: Assist authors in checking for accessibility problems. | ||
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)
|
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 on the success criterion. 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. [APPROVED] |
B.3.1.2 Help Authors Decide:If the authoring tool provides checks that require authors to decide whether a potential web content accessibility problem (WCAG) is correctly identified (i.e., manual checking and semi-automated checking), then instructions are provided from the check that describe how to decide. (Level A) |
||
B.3.1.3 Help Authors Locate:If the authoring tool provides checks that require authors to decide whether a potential web content accessibility problem (WCAG) is correctly identified (i.e., manual checking and semi-automated checking), then the relevant content is identified to the authors. (Level A)
|
||
B.3.1.4 Status Report:If the authoring tool provides checks, then authors can receive an accessibility status report based on the results of the accessibility checks. (Level AA) |
||
B.3.1.5 Programmatic Association of Results:If the authoring tool provides checks, then the authoring tool can programmatically associate accessibility checking results with the web content that was checked. (Level AA) |
||
| Guideline B.3.2: Assist authors in repairing accessibility problems. | ||
B.3.2.1 Repair Assistance (WCAG):If checking (see Success Criterion B.3.1.1) can detect that a WCAG 2.0 success criterion is not met, then repair suggestion(s) are provided: (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)
|
||
| PRINCIPLE B.4: Authoring tools must promote and integrate their accessibility features | ||
| Guideline B.4.1: Ensure the availability of features that support the production of accessible content. | ||
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. Unintrusive error detection, such as the red-underlining frequently employed for spell checking is often turned on by default. A note that users can be given the option to turn off accessibility features appears in the intent: "Note: This success criterion requires that features be on by default, but allows developers to provide authors with the option to turn them off or modify their settings." [APPROVED] |
B.4.1.2 Option to Reactivate Features:If authors can turn off an accessible content support feature, then they can turn the feature back on. (Level A) |
||
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)
|
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. |
B.4.1.4 Feature Deactivation Warning:If authors turn off an accessible content support feature, then the authoring tool informs them that this may increase the risk of content accessibility problems (WCAG). (Level AA) |
||
B.4.1.5 Feature Prominence:All accessible content support features are at least as prominent as features related to either invalid markup, syntax errors, spelling errors or grammar errors. (Level AA) |
||
| Guideline B.4.2: Ensure that documentation promotes the production of accessible content. | ||
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. |
B.4.2.2 Feature Instructions:Instructions for using any accessible content support features appear in the documentation. (Level A) |
||
B.4.2.3 Tutorial:The authoring tool provides a tutorial for an accessible authoring process that is specific to that authoring tool. (Level AAA) |
||
B.4.2.4 Instruction Index:The authoring tool documentation contains an index to the instructions for using any accessible content support features. (Level AAA) |