(Draft) Comment Responses for ATAG 2.0 (10 April 2012 Last Call Draft)

 

Commenters:

Gottfried Zimmermann (GZ)

IBM (IBM)

Microsoft (MS)

Legend:

[DRAFT-TEXT]: Addressed by a proposal
[APPROVED] Response approved by WG.

Where issues repeat, we link to the first instance.

Guidelines and Success Criteria

  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?".
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 requriements of ATAG 2.0. The suggested wording "Increase the accessibility of..." also has an implicit comparison point.
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.
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 general guidelines, because in most cases, the techniques for implementing the general guidelines on a platform will entail the same platform level guidance contained in the relevant platform accessibility guidelines."

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

  • (a) Option to Render: The authoring tool provides the option to render alternatives for the time-based media; or
  • (b) User Agent Option: Authors have the option to preview the time-based media in a user agent that is able to render the alternatives.
    
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)

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

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:
"The note provides some examples of status indicators that are relatively common in authoring tools. For example, many WYSIWYG editors include an option to display an icon to indicate the location of anchor tags and comments, both of which would otherwise be hidden from view. Another common status indicator is underlining spelling errors in red."

@@AUWG: The Working Group agrees with the wording suggestion:
"If an editing-view adds status indicators to the content being edited, then the information being conveyed by the status indicators can be programmatically determined."

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 contolled with a D-Pad (or D-pad emulator), many BlackBerry devices include physical shortcuts 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."
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.

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)

  • 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.
  • Note 2: The path exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input, but the underlying function (text input) does not. The path exception encompasses other input variables that are continuously sampled from pointing devices, including pressure, speed, and angle.
  • Note 3: This success criterion does not forbid and should not discourage other input methods (e.g., mouse, touch) in addition to keyboard operation.
    

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

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)

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

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

@@AUWG: WCAG 2.0 does not include a definition of Time Limit, but in the interest of clarity, the Working Group has added one:
"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)."

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

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)

  • Note: Depending on the web content technology and the nature of the authoring tool, relationships may include, but are not limited to, element nesting, headings, labeling, programmatic definitions, and ID relationships.
    
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)

  • (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"
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: Audio and haptic display settings are less commonly utilized, but still valid.

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)

  • (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, sometime 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.

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) Described in the documentation: Use of the feature is explained in the authoring tool's documentation; or
  • (b) Described in the interface: Use of the feature is explained in the authoring tool user interface; or
  • (c) Platform service: The feature is a service provided by an underlying platform; or
  • (d) Not used by authors: The feature is not used directly by authors (e.g., passing information to a platform accessibility service).
    

A.4.2.2 Document All Features:

For each authoring tool feature, at least one of the following is true: (Level AA)

  • (a) Described in the documentation: Use of the feature is explained in the authoring tool's documentation; or
  • (b) Described in the interface: Use of the feature is explained in the authoring tool user interface; or
  • (c) Platform service: The feature is a service provided by an underlying platform; or
  • (d) Not used by authors: The feature is not used directly by authors (e.g., passing information to a platform accessibility service).
    
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. @@MS1: 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."

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)
  • (a) Accessible: The content is accessible web content (WCAG) without author input; or
  • (b) Prompting: During the automatic generation process, authors are prompted for any required accessibility information (WCAG); or
  • (c) Automatic Checking: After the automatic generation process, accessibility checking is automatically performed; or
  • (d) Checking Suggested: After the automatic generation process, the authoring tool prompts authors to perform accessibility checking.
   
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)

  • (a) Preserve: Accessibility information (WCAG) is preserved in the output; or
  • (b) Warning: Authors have the default option to be warned that accessibility information (WCAG) may be lost (e.g., when saving a vector graphic into a raster image format); or
  • (c) Automatic Checking: After the transformation, accessibility checking is automatically performed; or
  • (d) Checking Suggested: After the transformation, the authoring tool prompts authors to perform accessibility checking.
   

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

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

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

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

  • Note: This success criteria only applies when the output technology is "included" for conformance.
    
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.

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:
"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 or invisible."
The case of CAPTCHA is not as clear because the purpose must be described and the author may need to contribute.

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

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.

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).
The text has been reworded as follows: "Repair of Text Alternatives During Authoring Sessions: If the authoring tool attempts tp 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.
(b) Author Control: Authors have the opportunity to accept, modify, or reject the repair strings prior to insertion in the content; and

@@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. See rewording under MS3.

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.

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:
"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 any repair strings do not include text that is also 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)

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)
  • (a) Save and Suggest: The text alternatives are automatically saved and suggested by the authoring tool, if the same non-text content is reused; and
  • (b) Edit Option: The author has the option to edit or delete the saved text alternatives.
    
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.

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)

  • Note: The distinction can involve providing information for the accessible templates, the non-accessible templates or both.
    

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)

  • Note: The distinction can involve providing information for the accessible templates (WCAG), the non-accessible templates or both.
    

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.

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

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)

  • Note: Depending on the nature of the editing-view and the scope of the potential web content accessibility problem (WCAG), identification might involve highlighting elements or renderings of elements, displaying line numbers, or providing instructions.
    

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)

  • Note: The format of the accessibility status report is not specified and they might include a listing of problems detected or a WCAG 2.0 conformance level, etc..
    

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. Unintrsuive error detection, such as the red-underlining frequently employed for spell checking is often turned on by default.

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)

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

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)