Authoring Tool Accessibility Guidelines 2.0

1.1 Definition of Authoring Tool

Any software or service that authors may use to create or modify Web content for publication. This includes software that enables authors to perform any of the following functions:

1. Text Editing: Authors manipulate plain text data (e.g. markup text, program code, etc.). [Example 1]
2. Symbol-Level Editing: Authors manipulate symbols (not WYSIWYG renderings) that represent low-level functional groups in the underlying plain text data (e.g. symbols in place of markup elements, programming code operations, multi-element placeholder, etc.) .[Example 2]
3. WYSIWYG Editing: Authors manipulate browser-like renderings of the underlying plain text data (e.g. rendered text, images, etc. in place of markup elements). [Example 3]
4. Graphics Editing: Authors manipulate renderings of object-oriented graphics (e.g. rendered lines, etc. in place of markup elements in a drawing program, animation tool stage, etc.). [Example 4]
5. Content Management: Authors exercise control of changes to Web content across whole documents or groups of documents, rather than at the level of individual instances of content (e.g. site building wizards, site management tools, courseware, content aggregators, etc.). [Example 5]
6. Constrained Editing: Authors make highly constrained inputs that are structured and styled according to static templates (e.g. guest books, message boards, etc.). [Example 6]
7. Timeline Editing: Authors manipulate time-dependent Web content (e.g. animation, music, etc.) using a user interface that represents a series of frames. [Example 7]
8. Format Conversion: Authors are assisted in causing Web content encoded in one format to become encoded in another (e.g. saving Web content created in one format in a different format, importing Web content from a different format, etc.) [Example 8]

1.3 How this document is organized

This document contains four guidelines that reflect the goals of accessible authoring tool design:

• Guideline 1: Ensure that the tool itself is accessible
• Guideline 2: Ensure that the tool is designed to produce accessible content
• Guideline 3: Support the author in the production of accessible content
• Guideline 4: Integrate accessibility solutions into the overall "look and feel"

Each guideline includes:

• The guideline number
• The statement of the guideline
• The rationale behind the guideline
• A list of checkpoints

Each checkpoint is intended to be sufficiently specific to be verifiable, while being sufficiently general to allow developers the freedom to use the most appropriate strategies to satisfy it. The checkpoints specify requirements for meeting the guidelines. Each checkpoint includes:

• The checkpoint number
• The statement of the checkpoint
• The priority of the checkpoint
• Checkpoint subtext, including:
  • a brief rationale for the checkpoint
  • a minimum basic functionality requirement that is normative
  • suggested functionality for more advanced implementation (this is optional)
  • references to further information and techniques

A separate document, entitled "Techniques for Authoring Tool Accessibility Guidelines 2.0" [ATAG20-TECHS], provides suggestions and examples of how to achieve the recommendations in this document. Another document [ATAG20-CHECKLIST] lists all checkpoints, ordered by priority, for convenient reference.

1.4 Checkpoint priorities

Each checkpoint in the specification has been assigned one of the following priority levels to indicate the importance of the checkpoint in satisfying the guidelines:

GUIDELINE 1: Ensure that the tool itself is accessible

This guideline requires that the design of all aspects of the authoring tool, including the user interface, installation procedure, documentation, and help files, must be accessible. This entails following the all applicable accessibility guidelines (Checkpoint 1.1) as well as other considerations specific to authoring interfaces.

1.1 Ensure that the authoring interface follows applicable software accessibility guidelines. ([Priority 1] for required elements of the software accessibility guidelines; [Priority 3] for recommended elements of the software accessibility guidelines.)

Rationale: If the authoring tool interface does not follow these conventions, the author who depends upon the techniques associated with the conventions is not likely to be able to use the tool.

Techniques: Implementation Techniques for Checkpoint 1.1, Evaluation Techniques for Checkpoint 1.1

Success Criteria:

1. The authoring interface must pass the Software Accessibility Guidelines testing criteria. (Priority 1 for Required criteria; Priority 3 for Recommended criteria)

Specific considerations when designing an accessible authoring interface

Note: This is proposed text.
The special nature of authoring interfaces dictates several other accessible user interface design considerations. The checkpoint requirements for this section include ensuring accessible editing of all properties (Checkpoint 1.2), allowing the editor display preferences to be changed independently of the markup (Checkpoint 1.3), making the use of document structure for navigation and editing (Checkpoint 1.4), and providing an effective searching mechanism (Checkpoint 1.5).

1.2 Ensure that the authoring interface enables accessible editing of element and object properties. [Priority 1]

Rationale: Element or object properties displayed and edited through graphic means are not accessible to authors using screen readers, Braille displays or screen enhancers. The explicit property value should be accessible to those technologies which read text and support authors editing text.

Techniques: Implementation Techniques for Checkpoint 1.2, Evaluation Techniques for Checkpoint 1.2

Success Criteria:

1. At least one editing method must pass the Software Accessibility Guidelines testing criteria for each element and object property editable by the tool. (Priority 1 for Required criteria; Priority 3 for Recommended criteria)

1.3 Allow the display preferences of the authoring interface to be changed without affecting the document markup. [Priority 1]

Rationale: Authors may require a set of display preferences to view and control the document that is different from the desired default
display style for the published document (e.g. a particular text-background combination that differs from the published version).

Techniques: Implementation Techniques for Checkpoint 1.3, Evaluation Techniques for Checkpoint 1.3

Success Criteria:

1. All editing views must display text equivalents for any non-text content
2. All editing views must either respect operating system display settings (for color, contrast, size, and font) or, from within the tool, provide a means of changing color, contrast, size and font, without affecting the content markup.

1.4 Ensure that the authoring interface enables the author to navigate the structure and perform structure-based edits. [Priority 2]

Rationale:
Efficient authoring requires that the author be able to move quickly to arbitrary locations in the content and, once there, make modifications beyond character-by-character edits. This is usually best accomplished by making use of any explicit structure that may have been encoded with hierarchy-based markup. When explicit structure is unavailable, the implicit structure in the visual look and layout of content may sometimes be used.

Techniques: Implementation Techniques for Checkpoint 1.4, Evaluation Techniques for Checkpoint 1.4

Success Criteria: (updated 22 July)

1. In any element hierarchy, the author must be able to move editing focus from any structural element to any element immediately above, immediately below or in the same level in the hierarchy.
2. In any element hierarchy, the author must be able to select, copy, cut and paste any element with its content.

1.5 Ensure the authoring interface allows the author to search within the editing views. [Priority 2]

Rationale: Search functions facilitate author navigation of content as it is being authored by allowing the author to move focus quickly to arbitrary points in the content. Including the capability to search within text equivalents of rendered non-text content increases the accessibility of the search function.

Techniques: Implementation Techniques for Checkpoint 1.5, Evaluation Techniques for Checkpoint 1.5

Success Criteria: (updated 22 July)

1. The authoring tool must have a search function for all editing views.
2. The author must be able to search for text within all text equivalents of any rendered non-text content.
3. The author must be able to specify whether to search content, markup, or both.

GUIDELINE 2: Ensure that the tool is designed to produce accessible content

Note: This is proposed text.
This guideline requires that authoring tools must generate standard markup and support accessible authoring practices. Meeting these requirements is an essential pre-requisite to the higher level functions required in the next guideline.

Generating standard markup:

Note: This is proposed text.
Conformance with standards enables content to be rendered more reliably by more user agents, including assistive technologies used by people with disabilities. The checkpoint requirements for this section include ensuring valid markup (Checkpoint 2.1) and using formats that have been formulated to enable accessible content (Checkpoint 2.2).

2.1 Ensure that markup which the tool automatically generates is valid for the language the tool is generating. [Priority 1]

Rationale: Following language specifications is the most basic requirement for accessible content production. When content is valid, it is easier to check and correct accessibility errors and user agents are better able to render the content properly and personalize the content to the needs of individual users' devices.

Techniques: Implementation Techniques for Checkpoint 2.2, Evaluation Techniques for Checkpoint 2.2

Success Criteria: (updated 22 July)

1. All markup strings written automatically by the tool (i.e. not authored "by hand") must conform to the applicable markup language specification.

2.2 Use the latest versions of W3C format Recommendations when they are available and appropriate for a task. [Priority 2]

Rationale: The W3C has implemented an accessibility review process for language recommendations that has resulted in addition of supports for accessibility within many of these languages as well as published Notes describing best use practices for some of the most popular languages. Because this process is ongoing, more recent versions of W3C language recommendations are likely to include better supports for accessibility than older ones.

Techniques: Implementation Techniques for Checkpoint 2.1, Evaluation Techniques for Checkpoint 2.1

Success Criteria:

1. Provide an accessible reading of web content in available, relevant W3C recommended language format and provide accessible means for editing and writing in that language format.
2. The tool may use non-W3C formats in addition to the W3C Recommendations.
3. A W3C Recommendation is considered available to a specific version of an authoring tool, if the Recommendation has reached the Candidate Recommendation phase at least two (2) years before the version of the tool in question is released for use.
4. Whether a W3C Recommendation is appropriate depends on the features of the tool. Critical relevance criteria will depend on the task, but may include support for media, scripting, or styling. When comparing the appropriateness of W3C recommendations with other, non-W3C formats for a particular task, accessibility must be included as a comparison criteria.
5. Inform the author in marketing, packaging and other documentary material of the name and version of any W3C Recommendations used. This notice must specify whether the conformance with the Recommendation is full or partial.

Supporting accessible authoring practices:

Note: This is proposed text.
Web content produced by an authoring tool is most likely to be accessible, if the content is created in accordance with the requirements of WCAG and preserved in that state throughout the authoring process. The checkpoint requirements for this section include ensuring the possibility of accessible content production (Checkpoint 2.3), preserving accessible or unknown content (Checkpoint 2.4 and 2.7), automatically generating accessible content (Checkpoint 2.5), and including accessible pre-authored content (Checkpoint 2.6).

2.3 Ensure that the author can produce accessible content in the markup language(s) supported by the tool. [Priority 1]

Rationale: If it is at least possible for the author to produce accessible content, then well-informed authors may be able to work around any accessibility short-comings in the rest of the authoring tool.

Techniques: Implementation Techniques for Checkpoint 2.3, Evaluation Techniques for Checkpoint 2.3

Success Criteria: (updated 22 July)

1. Tools must always meet at least one of the following:
   • generate accessible content automatically
   • provide a method for authoring "by hand"
   • provide the author with accessible options for every authoring task

2.4 Ensure that the tool preserves all accessibility information during transformations, and conversions. [Priority 1]

Rationale: Authors will be discouraged from adding accessibility information if it is discarded during conversions (i.e. taking content encoded in one markup language and re-encoding it in another) or transformations (i.e. modifying the encoding of content without changing the markup language).

Techniques: Implementation Techniques for Checkpoint 2.4, Evaluation Techniques for Checkpoint 2.4

Success Criteria: (updated 22 July)

1. During all transformations and conversions, any accessibility information must be preserved, unless prevented by limitations of the target format.
2. When accessibility information cannot be preserved during a conversion or transformation, the author must notified beforehand.

2.5 Ensure that when the tool automatically generates content it conforms to the WCAG. [Relative Priority]

Rationale: Authoring tools that automatically generate content that does not conform to WCAG are an obvious source of accessibility problems.

Techniques: Implementation Techniques for Checkpoint 2.5, Evaluation Techniques for Checkpoint 2.5

Success Criteria: (updated 22 July)

1. All markup strings written automatically by the tool (i.e. not authored "by hand") must conform to WCAG.

2.6 Ensure that all pre-authored content for the tool conforms to WCAG. [Relative Priority]

Rationale: Pre-authored content (e.g. templates, images, videos, etc.) is often included with authoring tools for the convenience of the author. Ensuring that pre-authored content is WCAG conformant increases that convenience by ensuring that authors can use any of the content without concern for the accessibility implications and relieving subsequent authors from having to compose their own version of alternative content.

Techniques: Implementation Techniques for Checkpoint 2.6, Evaluation Techniques for Checkpoint 2.6

Success Criteria: (updated 22 July)

1. Any Web content (e.g. templates, clip art, multimedia objects, scripts, applets, example pages, etc.) preferentially licensed (i.e. better terms of use for users of tool than for others) for users of the tool, must conform to WCAG.

2.7 Allow the author to preserve markup not recognized by the tool. [Priority 2]

Rationale: Markup that is not recognized by an authoring tool may have been added to enhance accessibility. Also, newer XML-based languages, such as XHTML 1.1, allow authors to include multiple languages in a single document, via namespaces. In the future, documents may contain metadata, including accessibility information, in another namespace. Authoring tools must not strip this information when it is encountered.

Techniques: Implementation Techniques for Checkpoint 2.7, Evaluation Techniques for Checkpoint 2.7

Success Criteria: (updated 22 July)

1. When unrecognized markup (e.g. external entity, unrecognized element or attribute name) is detected, the tool must query the author for consent to modify the markup. If the author refuses, and the markup cannot be processed, the tool must refuse to open the markup for editing.

GUIDELINE 3: Support the author in the production of accessible content

Most authoring tools provide the author with at least some measure of control over the produced content. This control may extend to the level of markup coding (e.g. authoring "by hand") or it may be limited to higher-level content, such as page layout and text content (e.g. WYSIWYG editing). In either case, the intervention of the author has the potential to effect the accessibility of content, either positively, if the author is purposefully following accessibility guidelines, or negatively, if the author is not. In order to manage these effects, authoring tools should support the author by guiding them to follow accessibility authoring practices as they produce that content that involves an element of human judgment or creativity, providing automated or semi-automated checking and correction facilities and by providing high quality accessibility-related documentation.

Guiding the author to produce accessible content:

3.1 Prompt and assist the author to create accessible content. [Relative Priority]

Rationale: Appropriate assistance should increase the likelihood that typical authors will create WCAG-conformant content. Different tool developers will accomplish this goal in ways that are appropriate to their products, processes and authors.

Techniques: Implementation Techniques for Checkpoint 3.1, Evaluation Techniques for Checkpoint 3.1

Success Criteria: (updated 22 July)

1. When the actions of the author risk creating accessibility problems (e.g. image inserted, author typing invalid element into a code view, author initiating a page creation wizard, etc.), the tool must intervene to introduce the appropriate accessible authoring practice. This intervention may proceed according to a user-configurable schedule.
2. The intervention must occur at least once before completion of authoring (e.g. final save, publishing, etc.).

3.2 Check for and inform the author of accessibility problems. [Relative Priority]

Rationale: Authors may not notice or be able to identify accessibility problems.

Techniques: Techniques for checkpoint 3.2, Evaluation Techniques for Checkpoint 3.2.

Success Criteria: (updated 22 July)

1. The tool must provide a check (automated check, semi-automated check or manual check) for detecting violations of each requirement of WCAG.

3.3 Assist authors in repairing accessibility problems. [Relative Priority]

Rationale: Assistance may expedite the task of correcting some authors' accessibility problems, while other authors may be unable to correct accessibility problems without this help.

Techniques: Techniques for checkpoint 3.3, Evaluation Techniques for Checkpoint 3.3

Success Criteria: (updated 22 July)

1. The tool must provide a repair (automated repair, semi-automated repair or manual repair) for correcting violations of each requirement of WCAG.

Specific considerations when providing this guidance

Note: This is proposed text.
When guiding the author towards the creation of accessible content, several specific factors should must be considered. The checkpoint requirements for this section include taking care not to automatically include inappropriate equivalent alternatives (Checkpoint 3.4), providing automated means for managing equivalent alternatives (Checkpoint 3.5), and providing accessibility status summaries (Checkpoint 3.6).

3.4 Do not automatically generate equivalent alternatives or reuse previously authored alternatives without author confirmation, except when the function is known with certainty. [Priority 1]

Rationale: Improperly generated alternatives can create accessibility problems and interfere with accessibility checking.

Techniques: Implementation Techniques for Checkpoint 3.4, Evaluation Techniques for Checkpoint 3.4

Success Criteria: (updated 22 July)

1. When the author inserts an unrecognized non-text object, the tool must not insert an automatically generated text equivalent (e.g. label generated from the file name).
2. When the author inserts a non-text object for which the tool has a previously authored equivalent (i.e. created by the author, tool designer, pre-authored content developer, etc.), but the function of the object is not known with certainty, the tool must prompt the author to confirm insertion of the equivalent. However, where the function of the non-text object is known with certainty (e.g. "home button" on a navigation bar, etc.), the tool may automatically insert the equivalent.

3.5 Provide functionality for managing, editing, and reusing alternative equivalents for multimedia objects. [Priority 3]

Rationale: Simplifying the initial production and later reuse of alternative equivalents will encourage authors to use them more frequently. In addition, such an alternative equivalent management system will facilitate meeting the requirements of Checkpoint 3.4.

Techniques: Implementation Techniques for Checkpoint 3.5, Evaluation Techniques for Checkpoint 3.5

Success Criteria: (updated 22 July)

1. When non-text objects have been previously inserted using the tool, the tool must suggest any previously authored textual equivalents for that non-text object.

3.6 Provide the author with a summary of the document's accessibility status. [Priority 3]

Rationale: This summary will prompt the author to: improve the accessibility status; keep track of problems; and monitor progress.

Techniques: Techniques for checkpoint 3.6, Evaluation Techniques for Checkpoint 3.6.

Success Criteria: (updated 22 July)

1. The tool must provide the author with an option to view a listing of all current accessibility problems.

Promoting accessibility in help and documentation:

Note: This is proposed text.
Because authors are likely to differ widely in their familiarity with Web content accessibility issues, the help and documentation of the authoring tool must address several types of use. The checkpoint requirements for this section include documenting accessible content promoting features (Checkpoint 3.7), ensuring that accessibility solutions are modeled in the documentation and help(Checkpoint 3.8), and including suggested workflow instructions for using the tool to produce accessible content (Checkpoint 3.9).

3.7 Document all features of the tool that promote the production of accessible content. [Priority 1]

Rationale: Without documention of the features that promote accessibility (e.g. prompts for alternates, code validators, accessibility checkers, etc.) authors may not find or use them.

Techniques: Techniques for checkpoint 3.7, Evaluation Techniques for Checkpoint 3.7.

Success Criteria: (updated 22 July)

1. All features that play a role in creating accessible content must be documented in the help system.

3.8 Ensure that accessibility is modeled in all documentation and help, including examples. [Priority 2]

Rationale: If authors must look somewhere special for information on accessible authoring practices, they may be unlikely to make the effort. Familiarity with these practices will be promoted by their integration.

Techniques: Implementation Techniques for Checkpoint 3.8, Evaluation Techniques for Checkpoint 3.8

Success Criteria: (updated 22 July)

1. All examples of markup code and views of the user interface (dialog screenshots, etc.) must meet the requirements of WCAG, regardless of whether the examples are intended to demonstrate accessibility authoring practices.

3.9 Document the workflow process of using the tool to produce accessible content. [Priority 3]Note: The term "workflow" still needs definition.

Rationale: Authors will be more likely to use features that promote accessibility if they understand when and how to use them.

Techniques: Techniques for checkpoint 3.9, Evaluation Techniques for Checkpoint 3.9

Success Criteria: (updated 22 July)

1. The documentation must contain suggested content creation workflow descriptions that include how and when to use the accessibility-related features of the tool.
2. For tools that lack a particular accessibility-related feature, the workflow description must include a workaround for that feature.

GUIDELINE 4: Promote and integrate accessibility solutions

Note: This is proposed text.
This guideline requires that authoring tools must promote accessible authoring practices within the tool as well as smoothly integrate any functions added to meet the other requirements in this document. The checkpoint requirements for this section include ensuring the availability of accessibility-related functions (Checkpoint 4.1), ensuring the priority for accessible means of completing for an authoring tasks (Checkpoint 4.2) and ensuring that accessibility-related functions fit into the overall look and feel of the tool (Checkpoint 4.3).

4.1 Ensure that accessibility prompting, checking, repair functions and documentation are always clearly available to the author [Priority 1]

Rationale: If the features that support accessible authoring are difficult to find, activate or use, they are less likely to be used. Ideally, these features should be turned on by default.

Techniques: Implementation Techniques for Checkpoint 4.1, Evaluation Techniques for Checkpoint 4.1

See Also: ATAG Checkpoints 3.1, 3.2, and 3.3.

Success Criteria: (updated 22 July)

1. If accessibility prompting (see Checkpoint 3.1), checking (see Checkpoint 3.2), and repairing (see Checkpoint 3.3) functions are not already active by default, the mechanism for activating them must be available to the author at all times during authoring and, at most, one level down in the user interface (e.g. in the first level of a drop-down menu).
2. The configuration mechanism (i.e. preferences, options, etc.) for these accessibility-related functions must be designed so that typical authors searching for the configuration mechanism will be likely to find it and that typical authors performing general configuration tasks will be likely to notice the configuration mechanism.
3. When these accessibility-related functions are combined with other authoring functions (i.e. one accessibility-related field in a general purpose dialog box), the y must be designed so that typical authors searching for the function will be likely to find it and that typical authors performing other general purpose tasks will be likely to notice the function.

4.2 Ensure that the most accessible option for an authoring task is given priority. [Priority 2]

Rationale: Authors are most likely to use the first and easiest options.

Techniques: Implementation Techniques for Checkpoint 4.2, Evaluation Techniques for Checkpoint 4.2

Success Criteria: (updated 22 July)

1. When a tool provides a means for markup to be added with a single mouse click or keystroke, that markup must meet the requirements of WCAG unless the markup was authored "by hand".
2. When an authoring action has several markup implementations (e.g. changing the color of text with presentation markup or style sheets), those markup implementation(s) that meet the requirements of WCAG must be equal to or higher on all of the following scales than those markup implementations that do not meet the WCAG requirements:
   • Prominence of location (in "power tools" such as floating menus, toolbars, etc.)
   • Position in layout (top to bottom and left to right in menus, dialog boxes, etc. )
   • Size of control (measured as screen area)
   • Actions to activate (number of mouse clicks or keystrokes)

4.3 Ensure that accessibility prompting, checking, repair functions and documentation are naturally integrated into the overall look and feel of the tool. [Priority 2]

Rationale: Most authors are reluctant to use features that depart from the conventions of a tool.

Techniques: Implementation Techniques for Checkpoint 4.3, Evaluation Techniques for Checkpoint 4.3

Success Criteria: (updated 22 July)

1. The mechanisms for accessibility prompting, checking, repair and documentation must be similar to comparable mechanisms in terms the following characteristics:
   • visual design (design metaphors, artistic sophistication, sizes, fonts, colors)
   • operation (degree of automation, number of actions for activation)
   • configurability (number and types of features)