(Draft) Comment Responses for ATAG 2.0 (21 July 2011 Public Working Draft)

(Draft) Comment Responses for ATAG 2.0 (21 July 2011 Public Working Draft)

11 August 2011

Commenters:

Timeless (TL)

Legend:

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

Where issues repeat, we link to the first instance.

Guidelines

PART A: Make the authoring tool user interface accessible

  Comments Responses
General Comments

TL1: This document isn't using RFC words. I expect a `should` or `must` before `follow`, the sentence feels awkward without it.

AUWG:WCAG 2.0 also does not use RFC words. What's the group's preference?@@@
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, such as menus, button bars, status bars, user preferences, documentation, etc.    
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 accessible to authors with disabilities (e.g. ensuring that text alternatives in the content can be programmatically determined). However, where an accessibility problem is caused directly by the content being edited (e.g. if an image in the content lacks a text alternative), then this would not be considered a deficiency in the accessibility of the authoring tool user interface.    
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. by plug-ins, user modifications, etc.).    
User agent features: Web-based authoring tools may rely on user agent features (e.g. keyboard navigation, find functions, display preferences, undo features, etc.) to satisfy success criteria. If a conformance claim is made for a web-based authoring tool, the claim must cite the user agent.

TL2:What do you mean `cite`?

AUWG: JR PROPOSAL :
Conformance claims are optional, but any claim that is made must record the user agent employed during evaluation. [DRAFT-TEXT]

Features for meeting Part A must be accessible: The Part A success criteria apply to the entire authoring tool user interface, including any features added to meet the success criteria in Part A (e.g. documentation, search functions, etc.). The only exemption is for preview features, as long as they meet 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.    

PRINCIPLE A.1: Authoring tool user interfaces must follow applicable accessibility guidelines

   

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

Web-based authoring tool 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:

Non-web-based authoring tool user interfaces follow user interface accessibility guidelines for the platform. (Level A)

  • Note: If a conformance claim is made, then the claim must cite the accessibility guidelines followed.

TL3:`cite` how? (An example or formal structure would be nice, is "Supports WCAG2" sufficient? Should it be "Supports <url> level X"?)

AUWG: JR PROPOSAL:
Conformance claims are optional, but any claim that is made must list the accessibility guideline(s) followed. [DRAFT-TEXT]

A.1.2.2 Platform Accessibility Services:

Non-web-based authoring tools implement communication with platform accessibility services. (Level A)

  • Note: If a conformance claim is made, then the claim must cite the platform accessibility service(s) implemented.
TL4:`cite` is a weird word, I think you want `list` here. AUWG: JR PROPOSAL:
Conformance claims
are optional, but any claim that is made must list the platform accessibility service(s) implemented. [DRAFT-TEXT]

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 with programmatically associated text alternatives, then the text alternatives can be programmatically determined. (Level A)

TL5:`programmatically` sounds wrong, to me <script> is programmatic. I think you mean `structurally`.

AUWG:"Programmatically" is a defined term that is borrowed from WCAG 2.0. This requirement deals with passing text alternative through from the content to assistive technologies. [DRAFT-TEXT]

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)

TL6:Always rendering captions doesn't seem like the right requirement. I think you want `can be rendered` not `are also rendered`. Being accessible doesn't mean burning captions into content (I just watched a movie last night where the captions were initially projected into the speakers below the screen... -- and I needed the captions). Note that the text for (b) is nicer, it says `has the option to... render the alternatives`, which is really what should be offered in (a).

AUWG:JR PROPOSAL:
(a) Option to Render: The authoring tool provides the option to render alternatives for the time-based content; or [DRAFT-TEXT]

Guideline A.2.2: (For the authoring tool user interface) Editing-view presentation can be programmatically determined.

A.2.2.1 Editing-View Status Information:

If an editing-view modifies the presentation to convey status information, then that status information can be programmatically determined. Status information conveyed by modifying the presentation of editing-views may include, but is not limited to, spelling, grammar and syntax errors. (Level A)

A.2.2.2 Access to Rendered Text Properties:

If a text property is both rendered and editable and the text property is supported by the implemented platform accessibility service, then the property is programmatically determinable. (Level A)

PRINCIPLE A.3: Editing-views must be operable

Guideline A.3.1: (For the authoring tool user interface) Provide keyboard access to authoring features.

A.3.1.1 Keyboard Access (Minimum):

All functionality of the authoring tool is operable through a keyboard interface 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: 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 2: This success criterion does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.

A.3.1.2 No Keyboard Traps:

Keyboard traps are prevented as follows: (Level A)

  • (a) In the Authoring Tool User Interface: 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, the user is advised of the method for moving focus away; and
  • (b) In Editing-Views that Render Content: If an editing-view renders content (e.g. WYSIWYG view), then a documented keyboard command is provided that moves the editing-view keyboard focus to a known location (e.g. the start of the editing-view).

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)

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:

Keyboard access to the authoring tool can be customized. (Level AAA)

TL7:I seem to recall writing feedback on this somewhere, but basically, I'm not sure I agree with this requirement. It makes more sense for a platform accessibility agent (OS or third party) to offer a consistent UI for customizing keyboard access than having dozens of applications each inventing their own incompatible models.

AUWG: Needs group discussion @@

A.3.1.6 Present Keyboard Commands:

Authoring tool user interface components can be presented with any associated keyboard commands. (Level AAA)

TL8:What does `presented` mean? (This sentence took me 5 minutes to decipher.) ~There should be a way for a user to determine the associated keyboard commands for authoring tool user interface components.~ ?

AUWG: Right, and it should be available in the user interface, not just by going to a long list of keyboard commands in the help documentation. [DRAFT-TEXT]

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.

A.3.2.3 Static Pointer Targets:

Authoring tool user interface components that accept pointer input are either stationary or 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 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:

Editing-views that render visual time-based content 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, etc.) are selectable and navigation mechanisms are provided to move the selection focus between elements. (Level AA)

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. 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. (Level AAA)

TL9:I've already commented that I don't like `programmatic`. You might mean `structural` or `DOM associated` or similar. Based on the context, I think `structural` is correct.

AUWG: The point here is to provide another quick way of moving around the authoring tool user interface, at a AAA level. [DRAFT-TEXT]

Guideline A.3.5: (For the authoring tool user interface) Provide text search of the content.

A.3.5.1 Text Search:

Editing-views enable 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; and
  • (e) Case Sensitive: The search can be in both case sensitive and case insensitive modes.

TL10:You don't define `case sensitive`. Please be aware that this area runs into I18n issues.

AUWG: This has been removed. [DRAFT-TEXT]

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 affecting the web content to be published. (Level A)

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 made by authors. (Level AA)

TL11:If the user has already specified custom settings in the application, then this requirement seems brittle. It should be compatible with the user being able to specify custom settings in the application.

AUWG:JR PROPOSAL:
The authoring tool respects changes in platform display and control settings unless they conflict with display and control settings of the authoring tool. [DRAFT-TEXT]

A.3.6.4 Multiple Sets:

If the authoring tool includes display and/or control settings, then authors can save and reload multiple sets of these settings. (Level AAA)

TL12:I think you mean complete sets as opposed to subsets of settings. And that multiple just means <app-full-settings-for-morning.settings> and <app-full-settings-for-evening.settings> and not <app-editor.settings> / <app-previewer.settings> -- I think your text sort of implies the latter, which seems to be overreaching, even for AAA.

 

AUWG:JR PROPOSAL:
If the authoring tool includes display and/or control settings, then the authoring tool provides the option of saving and reloading multiple sets of settings. [DRAFT-TEXT]

A.3.6.5 Assistance with Preferences:

If the authoring tool includes display and/or control settings, then the authoring tool includes a mechanism to help authors configure these settings. (Level AAA)

TL13:It sounds like you're asking for a Wizard. If you mean that, perhaps a `such as a Wizard` would be useful.

AUWG: JR PROPOSAL: Remove this because it really is not doing much. [DRAFT-TEXT]

Guideline A.3.7: (For the authoring tool user interface) Ensure that previews are as accessible as existing 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) Pre-existing User Agent: The preview makes use of a pre-existing user agent; or
  • (b) UAAG (Level A): The preview conforms to the User Agent Accessibility Guidelines Level A [UAAG].

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

For authoring actions, one of the following is true: (Level A)

  • (a) Reversible: The authoring action can be immediately reversed; or
  • (b) Warn and Confirm: The authoring tool provides a warning to authors that the action is irreversible and requires authors to confirm the action before proceeding.
  • Note 1: Reversing actions (e.g. an "undo" function) are also considered authoring actions, meaning they must also meet this success criterion (e.g. a "redo" function).
  • Note 2: It is acceptable to collect a series of text entry actions (e.g. typed words, a series of backspaces) into a single reversible authoring action.
  • Note 3: It is acceptable to clear the authoring action history at the end of authoring sessions.

JR PROPOSAL:

If an authoring action is not immediately reversible, then the authoring tool requires author confirmation to proceed. [DRAFT-TEXT]

A.4.1.2 Setting Changes Reversible:

If actions modify authoring tool settings, then one of the following is true: (Level A)

  • (a) Reversible: The authoring tool setting can be reversed by the same mechanism that made the change; or
  • (b) Warn and Confirm: The authoring tool provides a warning to authors that the setting change is irreversible and requires authors to confirm or save the current settings before proceeding.

TL14:Would it be sufficient to have a way to save and restore settings (with a warning/way to save current settings)?

AUWG: JR PROPOSAL:
If an authoring tool setting change is not reversible, then the authoring tool requires author confirmation to proceed. [DRAFT-TEXT]

A.4.1.3 Content Changes Reversible (Enhanced):

Authors can sequentially reverse a series of reversible authoring actions. (Level AAA)

  • Note: The notes for A.4.1.1 still apply.

Guideline A.4.2: (For the authoring tool user interface) Document the user interface including all accessibility features.

A.4.2.1 Document Accessibility Features:

All features of the authoring tool that must be present to meet Part A of ATAG 2.0 (e.g. keyboard shortcuts, text search, etc.) are documented. (Level A)

A.4.2.2 Document All Features:

The authoring tool includes documentation for its author-level user interface features. (Level AA)

PART B: Support the production of accessible content

Part B Conformance Applicability Notes:

  Comments Responses
Author availability: Any Part B success criteria that refer to authors only apply during authoring sessions.    
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. by plug-ins, user-defined templates, user modifications of default settings, etc.).    
Applicability after the end of an authoring session: Authoring tools are responsible for the accessibility 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 has specified, whether it is author-generated or automatically-generated by another system that the author has specified (e.g. a third-party feed).

TL15:s/specified/merely selected for use/ ... I'm not sure whether `merely` is needed, but my initial drafting does include it...

AUWG: JR PROPOSAL:
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). [DRAFT-TEXT]
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).    
Features for meeting Part B must be accessible: 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, etc.).    
Multiple author roles: Some authoring tools include multiple author roles, each with different views and content editing permissions (e.g. a content management system may separate the roles of designers, content authors, and quality assurers). In these cases, the Part B success criteria apply to the authoring tool as a whole, not to the view provided to any particular author role. Accessible content support features should be made available to any author role where it would be useful.    

PRINCIPLE B.1: Fully automatic processes must produce accessible content

   

Guideline B.1.1: Ensure automatically specified content is accessible.

B.1.1.1 Content Auto-Generation After Authoring Sessions (WCAG):

Authors have the default option that, when web content is automatically generated for publishing after the end of an authoring session, it is 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):

Authors have the default option that, when web content is automatically generated during an authoring session, then 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, 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 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.
  • Note: This success criteria only applies to transformations in which the output technology is an "included" technology for conformance.

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

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

B.2.2.2 Setting Accessibility Properties (WCAG):

If the authoring tool provides mechanisms to set web content properties (e.g. attribute values, etc.), then mechanisms are also provided to set web content properties related to accessibility information (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)

TL16:This blob did not end in a period, s/:/./
-- a note follows the `:` but it doesn't make sense to think of that as a `list`.

AUWG: Level indicator moved to the end of all SCs. [DRAFT-TEXT]

B.2.2.3 Technology Decision Support:

If the authoring tool provides the option of producing a web content technology for publishing for which the authoring tool does not provide support for the production of accessible content, then both of the following are true: (Level A)

TL17:I'm uncertain how (b) will be remotely useful to the user. If the application can produce 100 unrelated accessible things and the user is trying to create a certain 1 thing which is not related to the 100 unrelated accessible things, then other than being forced to have a somewhat prominent advertisement for unrelated features, I think the user is being done a disservice. Two possible ways to address my concern are: s/technologies/[related|similar] technologies/

AUWG:

JR PROPOSAL:

I tend to agree. And I don't think it rises to our own threshold for Level A ("even authors with a high degree of accessibility expertise would be unlikely to produce accessible content (WCAG) using an authoring tool"). Unfortunately, the related/similar suggestion isn't really testable. I suggest moving it to Level AA in Section B.4.1 and focusing on letting authors know when accessibility authoring support is not available, whether or not they are at the decision stage:

B.4.1.X 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 content, then the authoring tool provides the authors with the option of being informed when support for the production of accessible content is not available.

 

[Level AA]
Note: This requirement concerns the presence or absence of support features such as accessibility checkers. It does not concern any intrinsic property of web content technologies.

Guideline B.2.3: Assist authors with managing alternative content for non-text content.

B.2.3.1 Alternative Content is Editable (WCAG):

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)

B.2.3.2 Conditions on Automated Suggestions:

During the authoring session, the authoring tool may only automatically suggest programmatically associated text alternatives for non-text content 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).
TL18:You're using an rfc word (`may`) here, which is odd... AUWG:See TL1

B.2.3.3 Let User Agents Repair:

The authoring tool avoids repairing programmatically associated text alternatives for non-text content using any text value that would also be available to user agents (e.g. do not use the image filename). (Level A)

 

B.2.3.4 Save for Reuse:

When authors enter programmatically associated text alternatives for non-text content, 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)

  • Note: It is recommended that the accessible options be identified, but this is not required.

TL19:It's probably better to identify the inaccessible options.

AUWG: It is best left to the the developer. For example, if there are only a few accessible choices, it might be better to call them out.. [DRAFT-TEXT]

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-Create 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, 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)

  • (a) Indicate: The selection mechanism indicates the accessibility status of the pre-authored content (if known); and
  • (b) Prominence: Any accessible options are at least as prominent as other pre-authored content options.

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

B.3.1.2 Help Authors Decide:

For checks that require authors to decide whether a potential web content accessibility problem is correctly identified (i.e. manual checking and semi-automated checking), instructions are provided from the check that describe how to make the decision. (Level A)

B.3.1.3 Help Authors Locate:

For checks that require authors to decide whether a potential web content accessibility problem is correctly identified (i.e. manual checking and semi-automated checking), the relevant content is identified to the authors. (Level A)

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

B.3.1.4 Status Report:

Authors can receive an accessibility status report based on the results of the accessibility checks. (Level AA)

  • Note: The format of the accessibility status is not specified. For example, the status might be a listing of problems detected or a WCAG 2.0 conformance level, etc.

B.3.1.5 Programmatic Association of Results:

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

TL20:I don't know that this claim is supportable. Authoring tools back to the age of time (Netscape Gold) had an alt tag field for images, that didn't result in accessible content.

AUWG: We are giving a rationale rather than a hard claim. That said, alt use is higher than some less prominent accessibility attributes (e.g., longdesc). [DRAFT-TEXT]

B.4.1.1 Features Active by Default:

All accessible content support features are turned on by default. (Level A)

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 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. (Level AA)

TL21:Depending on the UI, this can be an incredibly stupid if not absolutely inane requirement. If I have a dialog called "Accessibility Options", and have check items for various features, then being required to give the user a warning after they uncheck such an option is just plain stupid.
Start>Shutdown, are you sure you really really want to shut down?
(I've actually seen dialogs which include `really`, sadly.) A better requirement would be to simply require that the user be aware that the option they are disabling will affect accessibility -- either through the UI design itself or via a subsequent warning.

AUWG: Informing does not have to take the form of a dialog box. [DRAFT-TEXT]

B.4.1.4 Feature Prominence:

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)

TL22:Having worked with web pages for well over a decade, I can say the same for invalid markup and syntax errors. Having worked in Europe, I can say with some level of confidence that spelling errors are absolutely ignored. As for grammar, people don't even bother looking at them if they don't pay attention to spelling. As such, this requirement has no teeth. You should be aware of this. OTOH, there really isn't any level beyond them to suggest....

AUWG: Authors will vary in the degree to which they heed any guidance from their authoring tool. The requirement is on authoring tools, not users of authoring tools. [DRAFT-TEXT]

Guideline B.4.2: Ensure that documentation promotes the production of accessible content.

Rationale: Without documentation of the features that support the production of accessible content (e.g. prompts for text alternatives, accessibility checking tools), some authors may not be able to use them. Demonstrating accessible authoring as routine practice will encourage its acceptance by some authors.

TL23:This doesn't make sense in context. Documentation is unlikely to include prompts. Perhaps *explanations* of prompts. And *descriptions* or *recommendations* of tools ..."some authors may not be able to use them." This doesn't follow. "Demonstrating accessible authoring as routine practice will encourage its acceptance by some authors." This is a pipe dream and doesn't seem suitable for a standards document. It's even rather weak given its use of `some`....

AUWG: JR PROPOSAL:
Rationale: Some authors need support in determining how to use accessible content production features (e.g. how to respond to prompts for text alternatives, how to use the accessibility checking tool). Demonstrating accessible authoring as routine practice or at least not demonstrating inaccessible practices will help to encourage acceptance of accessibility by some authors. [DRAFT-TEXT]

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

B.4.2.2 Feature Instructions:

Instructions for using the accessible content support features appear in the documentation. (Level A)

B.4.2.3 Tutorial:

A tutorial on an accessible authoring process that is specific to the authoring tool is provided. (Level AAA)

B.4.2.4 Instruction Index:

The documentation contains an index to the instructions for using the accessible content support features. (Level AAA)

Glossary

TL24: Prompts: s/promptings/prompts/ ? This whole thought makes me sick. Typically prompts just annoy users. Note that this last sentence is missing a <what>, perhaps "to do the right thing".

AUWG: JR PROPOSAL:
prompt: Any authoring tool initiated request for a decision or piece of information from authors. The term covers requests that must be responded to immediately (e.g. modal dialog boxes) as well as less urgent requests (e.g. underlining a misspelled word).[DRAFT-TEXT]

TL25: Irreversible Actions: s/irreversible/not undoable/g ? `irreversible` is not a common word, and its primary results on the web are NSFW.

AUWG: JR PROPOSAL:
Removed and replaced in text with "non-reversible". We don't use "undoable" because sometimes the mechanism is called "cancel", etc. [DRAFT-TEXT]

TL26:source views: s/unrendered/raw|underlying/ ? `unrendered` seems to be a term limited to FCP.

AUWG: We have not been able to find a better term. "raw" and "underlying" don't seem to fit the text editor context. [DRAFT-TEXT]