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.

Within a single authoring tool, different parts of the authoring interface will fall under one or more of the following types of authoring functionality or functionality that falls outside this classification scheme. The types of authoring functions used will help determine which of the ATAG 2.0 implementation techniques are applicable to a particular tool:

1. Code-level Authoring Functions:

Author has full control over all aspects of the resulting Web content that have bearing on the final outcome. This covers, but is not limited to plain text editing, as this category also covers the manipulation of symbolic representations that are sufficiently fine-grained to allow the author the same freedom of control as plain text editing (e.g. graphical tag placeholders).
Examples: Text editors, text editors enhanced with graphical tags, etc.
Techniques symbol: TBA

2. WYSIWYG ("What-you-see-is-what-you-get") Authoring Functions:

Author has control over entities that closely resemble the final appearance and behaviour of the resulting Web content.
Examples: Rendered Web page editors, bitmap graphics editors, etc.
Techniques symbol: TBA

3. Object Oriented Authoring Functions:

Author has control over non-WYSIWYG entities that represent a functional abstraction from the low level aspects of the resulting Web content.
Examples: timelines, waveforms, vector-based graphic editors, etc.
Techniques symbol: TBA

4. Indirect Authoring Functions:

Authors have control of only high-level parameters related to the automated production of the resulting Web content.This may include interfaces that assist the author to create and organize Web content without the author having control over the markup or programming implementation.
Examples: Content managment systems, site building wizards, site management tools, courseware, weblogging tools, content aggregators and conversion tools, etc
Techniques symbol: TBA

1.2 Role of authoring tools in Web accessibility

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

2.2 Conformance

An ATAG conformance claim for an authoring tool must indicate which of the following conformance levels has been met:

Conformance Level "A"

Tool has met all Priority 1 checkpoints and has also met all Relative Priority checkpoints to at least Level 1.

Conformance Level "Double-A"

Tool has met all Priority 1 and 2 checkpoints and has also met all Relative Priority checkpoints to at least Level 2.

Conformance Level "Triple-A"

Tool has met all checkpoints and has also met all Relative Priority checkpoints to Level 3.

In the above, "meeting the checkpoints" means satisfying all of the success criteria associated with that particular checkpoint.

For the purposes of ATAG 2.0 conformance claims, tools may be bundled together (e.g. a markup editor and a evaluation and repair tool or a multimedia editor with a custom plug-in), however, this has two important consequences:

1. The bundled tools must be distributed together in order for each to maintain that conformance claim.
2. Bundled tools may have more difficulty meeting the checkpoints in Guideline 4 (Integrate accessibility solutions into the overall "look and feel") than single, integrated tools.

Satisfying certain success criteria may involve usability issues and as such may require integrating aspects of usability testing.

Conformance Icons: There are currently no conformance icons available for this draft specification. If it becomes a Recommendation, it is expected that there will be conformance icons like those available for ATAG 1.0.

2.3 Accessible authoring processes

From the standpoint of accessibility, Web authoring is a process that may involve one or more tools in parallel or in sequence. In order to ensure that the Web content produced as a result of a Web authoring process is accessible, developers and purchasers should choose tools that are either ATAG 2.0 conformant or ATAG 2.0-"Friendly". ATAG-"Friendly" tools are tools which, although they do not conform with ATAG, are also very unlikely to degrade the accessibility of Web content. For example, an ATAG-friendly tool is one that converts the URI locations in a Web page from absolute to relative prior to publishing.

In some cases, strategic ordering of the tools in a Web authoring process may increase the likelihood of producing accessible content. For example, a markup editor that does not conform to ATAG might be used before an ATAG conformant evaluation and repair tool. While this is, of course, preferable to not addressing accessibility at all, the original markup tool is still considered ATAG non-conformant. Considering the markup editor and evaluation and repair tool together is possible, but due to the low likelihood of proper integration between the tools, the result is unlikely to be a high level of ATAG conformance.

2. Guidelines

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

The creation of accessible content is dependent on the actions of the tool and the author. This guideline delineates the responsibilities that rest exclusively with the tool.

The first responsibility is to create valid, standards-based Web content, this can be rendered reliably by more user agents, including *assistive technologies* (Checkpoint 2.1). The next responsibility is to support formats that enable accessible content (Checkpoint 2.2).

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 that support this include ensuring that it is possible to author accessible content (Checkpoint 2.3), preserving accessible or unknown content (Checkpoint 2.4), automatically generating accessible content (Checkpoint 2.5), and including accessible pre-authored content (Checkpoint 2.6).

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.1, Evaluation Techniques for Checkpoint 2.1

Success Criteria:

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 Support formats that enable the creation of WCAG-conformant content. [Priority 1]

Rationale: Some formats are WCAG-capable, enabling the creation of web content that conforms to WCAG, while other formats may intrinsically preclude this possibility.

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

Success Criteria:

1. The authoring tool must support at least one WCAG-capable format for each Web content type produced.
2. When format selection is automatic, the selected format must be WCAG-capable.

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

Rationale: The ability to produce accessible Web content is the most basic requirement of this document.

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 the author with accessible options for every authoring task
   • provide a method for authoring "by hand"

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

Rationale: Unrecognized markup may include recent technologies that have been added to enhance accessibility and should be preserved 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). Accessibility information should also be preserved.

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

Success Criteria:

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

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:

1. Unless the author explicitly instructs the authoring tool otherwise, all content generated by the tool 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) is often included with authoring tools for the convenience of the author. When this content is WCAG-conformant, it is more convenient for users and more easily reused.

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

Success Criteria:

1. Any Web content (e.g. templates, clip art, multimedia objects, scripts, applets, example pages) that is bundled or preferentially licensed (i.e. better terms of use for users of the authoring tool than for the general public), must conform to WCAG.

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

Actions may be taken at the author's initiative that may result in *accessibility problems*. The authoring tool should include features that provide support and guidance to the author in these situations, so that *accessible authoring practices* can be followed and *accessible web content* can be produced.

This support includes prompting and assisting the author to create accessible web content (Checkpoint 3.1), especially for information that cannot be generated automatically, checking for accessibility problems (Checkpoint 3.2), and assisting in the repair of accessibility problems (Checkpoint 3.3). In performing these functions, the authoring tool must avoid including automatically generated equivalent alternatives or previously authored equivalent alternatives without author consent (Checkpoint 3.4). The authoring tool may also provide automated means for managing equivalent alternatives (Checkpoint 3.5) and provide accessibility status summaries (Checkpoint 3.6).

Accessibility-related documentation provides support and guidance to the author. The documentation must accommodate the various levels of author familiarity with web content accessibility issues. The checkpoint requirements include documenting accessible content promoting features (Checkpoint 3.7), and ensuring that *documentation* demonstrates authoring practices and workflow processes that result in accessible content (Checkpoint 3.8).

All functions that support *accessible authoring practices* should allow author preferences to be configurable to allow for different authoring styles. Custom configurations should improve use of the tool and make authors more receptive to assistive interventions from the authoring tool.

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:

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 introduce the appropriate accessible authoring practice. This introduction 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. The tool can assist in their identification.

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

Success Criteria:

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 by the tool may simplify the task of repairing accessibility problems for some authors, and make it possible for others.

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

Success Criteria:

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

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 2]

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:

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

1. When objects, for which alternative equivalents have been previously provided, are inserted, the tool must always offer those alternative equivalents for reuse or modification.

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

Rationale: This summary will help the author to improve the accessibility status of their work, keep track of problems and monitor progress.

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

Success Criteria:

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

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

Rationale: Without *documentation* 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:

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

3.8 Ensure that all *documentation* demonstrates authoring practices and workflow processes that result in accessible content. [Priority 2]

Rationale: If accessible authoring is integrated into instruction and guidance offered by the tool (e.g. documentation, help, tutorials, examples, and workflow processes), authors are more likely to follow accessible authoring as a common practice. This reinforces the message of accessibility that is being promoted and facilitates a better understanding of the reasoning behind its use and its consequences. Authors are also more likely to use features that promote accessibility if they understand when and how to use them.

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

Success Criteria:

1. All examples of markup code and views of the user interface (dialog screenshots, etc.) must demonstrate the requirements of *WCAG*, regardless of whether the examples are intended to demonstrate accessibility authoring practices.
2. All descriptions of authoring processes must integrate the steps needed to create accessible content.