Authoring Tool Accessibility Guidelines 2.0

ATAG 2.0 defines an "authoring tool" as: any software, or collection of software components, that authors use to create or modify Web content for publication, where a "collection of software components" are any software products used together (e.g., base tool and plug-in) or separately (e.g., markup editor, image editor, and validation tool), regardless of whether there has been any formal collaboration between the developers of the products.

1. Required: The date of the claim.
2. Required: The name of the authoring tool and sufficient additional information, as required, to specify the version (e.g., vendor name, version number, minor release number, required patches or updates, natural language of the user interface or documentation). The version information may refer to a range of tools (e.g., "this claim refers to version 6.x"). Note: If the authoring tool is comprised of more than one component (e.g., a markup editor, an image editor, and a validation tool), then this information must be provided separately for each component, although the conformance claim will treat them as a whole.
3. Required: A conformance profile, which must include the following:
   • (a) The conformance level that has been satisfied (choose one of: "A", "Double-A", "Triple-A").
   • (b) A list of all of the content type(s) produced by the authoring tool. When content types are typically produced together (e.g., HTML and JavaScript, various compound document combinations), they can be listed separately or together as one content type item. For each content type, indicate whether it is either:
     • (i) covered by the conformance claim. For each of these content type items, the URI of a content type-specific WCAG benchmark document must be provided. Only the authoring of "covered" content type(s) is relevant when determining if the checkpoint success criteria have been met. At least one content type must be "covered" in order for a conformance claim to be valid.
     • (ii) not covered by the conformance claim. The authoring of "uncovered" content type(s) is not relevant when determining if the checkpoint success criteria have been met
   • (c) For authoring tools with Web-based functionality:
     • (i) The version and URI of the Web Content Accessibility Guidelines document that the user interface was evaluated against. It is optional to provide a content type-specific WCAG benchmark document for each content types used in the implementation of the user interface.
     • (ii)The name and version information of the user agent(s) on which the Web-based functionality was evaluated for conformance.
   • (d) For authoring tools with functionality that is not Web-based:
     • (i) The name and version information of the operating system platform(s) on which the authoring tool was evaluated for conformance.
     • (ii) The name and version of the accessibility platform architectures employed.
4. Required: A description of how the normative success criteria were met for each of the checkpoints that are required for the conformance level specified by the conformance profile. For relative priority checkpoints this means describing how the requirements of the content type-specific WCAG benchmark document are satisfied.
5. Optional: A description of the authoring tool that identifies the types of authoring tool functions that are present in the tool. Choose one or more of: (a) Code-level authoring functions, (b) WYSIWYG authoring functions, (c) object oriented authoring functions, and (d) indirect authoring functions.
6. Optional: Any additional information about the tool, including progress towards the next conformance level.

A.0.1 For the authoring tool user interface, ensure that Web-based functionality conforms to WCAG. [Relative Priority]

Rationale: Authors must be able to have access to Web-based authoring tool user interface functionality just as they do to other Web content.

Note: For non-Web-based authoring tools, this is a relatively straightforward requirement, likely covering only a few areas of the interface (e.g., Web-based help features). However, for most Web-based authoring tools the requirement will cover the majority of functionality in the tool and overlap many of the other requirements in Part A of the guidelines. When this is the case, a note entitled "For Web-based authoring tool user interface functionality" will appear below the success criteria to provide more information.

Techniques: Implementation Techniques for Checkpoint A.0.1

Success Criteria:

1. All Web-based authoring tool user interface functionality must conform to WCAG.

GUIDELINE A.1: Authoring Tool User Interface must be Perceivable

In order for an authoring tool to be accessible, authors with a wide range of abilities must be able to perceive its user interface controls.

A.1.1 For the authoring tool user interface, provide text alternatives for all non-text objects. [Priority 1]

Rationale: People who have difficulty perceiving non-text objects are often able to access text alternatives of the same information, since text is more easily transformed between various display methods (e.g., magnification and enhancement, text-to-speech, Braille output)

Techniques: Implementation Techniques for Checkpoint A.1.1

Success Criteria:

1. All editing interface non-text objects that are used to convey information (e.g., toolbar icon, graphical depiction of a tag, sound effect) must have a text alternative (e.g., alternative text label, long text description).
2. The author must have the option to access an accessible multimedia alternative to any multimedia in the editing interface.
3. All editing views must always include an option to display any available text alternatives for non-text objects in the content being edited.

For Web-based authoring tool user interface functionality: Meeting Checkpoint A.0.1 will serve to meet success criteria 1 of this checkpoint.

A.1.2 For the authoring tool user interface, provide synchronized alternatives for multimedia. [Priority 2]

Rationale: People who have difficulty accessing or interpreting multimedia-supported information in the authoring tool user interface can have the information made available to them by other means. For example, people who are deaf or have a hearing loss can access auditory information through captions, and people who are blind or have low vision, as well as those with cognitive disabilities, who have difficulty interpreting visually what is happening, can receive audio descriptions of visual information.

Techniques: Implementation Techniques for Checkpoint A.1.2

Success Criteria:

1. All editing interface multimedia that is used to convey information (e.g., tutorial videos) must have synchronized alternatives (e.g., captions, audio descriptions).
2. All editing views must always include an option to display any available synchronized alternatives for multimedia in the content being edited.

For Web-based authoring tool user interface functionality: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.

A.1.3 For the authoring tool user interface, ensure that all display preferences are configurable. [Priority 1]

Rationale: Some authors require alternative display configurations to use the authoring tool user interface.

Note: The success criteria for this checkpoint are based on the capabilities of platforms (e.g., operating systems, user agents, GUI toolkits) as defined in the conformance profile, however developers are free to provide additional configuration.

Techniques: Implementation Techniques for Checkpoint A.1.3

Success Criteria:

1. If the visual display (e.g., fonts, sizes, colors, spacing, positioning) is controlled by the authoring tool rather than by the platform, then the authoring tool must provide at least the same configurable properties with at least the same configuration ranges as the platform.
2. If the audio display (e.g., volume, speech voices) is controlled by the authoring tool rather than by the platform, then the authoring tool must provide at least the same configurable properties with at least the same configuration ranges as the platform.
3. Editing views that have their display characteristics set by rendering the content being edited (e.g., WYSWYG editing views) must override these characteristics if the author explicitly sets visual or audio display preferences as described in the previous two success criteria.
4. Any visual or audio display settings must be saved between authoring sessions.

For Web-based authoring tool user interface functionality: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.

A.1.4 For the authoring tool user interface, ensure changes to the display settings of editing views do not affect the content being edited. [Priority 1]

Rationale: Authors may require settings to render and control the content during editing that differ from the presentation defined for the published content (e.g., providing a high contrast setting to edit content that is not intended to be high contrast).

Techniques: Implementation Techniques for Checkpoint A.1.4

Success Criteria:

1. The author must be able to configure the display settings of editing views without affecting the content being edited.

A.1.5 For the authoring tool user interface, ensure that information, functionality, and structure can be separated from presentation. [Priority 1]

Rationale: Separating content and structure from presentation allows the user interfaces of authoring tools to be presented differently to meet the needs and constraints of different authors without losing any of the information or structure. For example, information can be presented via speech or Braille (text) that was primarily intended to be presented visually. It can also facilitate automatic emphasis of structure or more efficient navigation. All of these can benefit authors with cognitive, physical, hearing, and visual disabilities.

Techniques: Implementation Techniques for Checkpoint A.1.5

Success Criteria:

1. For rendered editing views (e.g., WYSIWYG editing view), all characteristics of the presentation (e.g., color, boldness, positioning) must be available programmatically.
2. For authoring tool-controlled presentation in editing views (e.g., coloring misspelled words, identifying tag text in a code-level view), the semantic description of the presentation must be available programmatically.
3. For the presentation of controls within the editing interface (e.g., dialog boxes, menus, button bars, user interface controls in the editing view), the semantic description of the presentation (e.g., "paragraph tag" instead of "blue-colored <p>") must be available programmatically.
4. Any information that is conveyed by color (e.g., different colored underlines to indicate spelling and grammar errors) must meet at least one of the following:
   • (a) visually evident when color is not available (e.g., by the shape of the underlining), or
   • (b) provided by an alternative version that meets Part A (e.g., spelling and grammar checking utilities that provide the same functionality as the colored underline).

For Web-based authoring tool user interface functionality: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.

GUIDELINE A.2: Authoring Tool User Interface must be Operable

In order for an authoring tool to be accessible, authors with a wide range of abilities must be able to operate its user interface controls.

A.2.1 For the authoring tool user interface, ensure that all functionality is operable via a keyboard or a keyboard interface. [Priority 1]

Rationale: Some individuals have difficulty manipulating graphical input devices such as a mouse or trackball. Providing alternate means of navigating the user interface that does not rely on such devices provides an accommodation for individuals with limited mobility or those with visual disabilities who cannot rely on hand eye coordination for navigating the user interface.

Note 1: This does not preclude and should not discourage the support of other input methods (such as a mouse) in addition to keyboard operation.

Note 2: Also see Checkpoint A.3.1 when choosing keystrokes.

Techniques: Implementation Techniques for Checkpoint A.2.1

Success Criteria:

1. The author must be able, through keyboard input alone, to perform any authoring task that is available through the authoring tool user interface (e.g., navigating, selecting, and editing content within editing views, operating the editing interface, installing and configuring the tool, and accessing documentation), except freeform drawing. This applies to at least one mechanism per task, allowing non-keyboard accessible mechanisms to remain available (e.g., inserting an image with an "insert image" menu item vs. drag-and-dropping the image file's icon into the document).
2. The author must have the option to ensure that selection is separate from activation (e.g., navigating through the items in a dropdown menu without activating any of the items).
3. The author must have the option to enable single-key access to both of the following functionalities:
   • (a) move content focus to the next enabled control in the editing interface (e.g., using "tab" key), and
   • (b) navigate forward and backward within editing views (e.g., using "arrow" keys).
4. The author must have the option to enable key-plus-modifier-key (or single-key) access to all of the following functionalities (if present):
   • (a) move content focus to the previous enabled control (e.g., using "shift-tab" key),
   • (b) navigate between panels or windows,
   • (c) open help system,
   • (d) open new content,
   • (e) open existing content,
   • (f) save content,
   • (g) close content,
   • (h) cut/copy/paste,
   • (i) undo/redo,
   • (j) open find/replace function, and
   • (k) navigate to the start and end of the content being edited.
5. Any keyboard operability settings must be saved between authoring sessions.
6. The current keyboard settings must be available to the author at all times (e.g. in either a central location such as a list, or a distributed location such as associating shortcuts with menu items).

For Web-based authoring tool user interface functionality: Meeting Checkpoint A.0.1 will serve to meet success criteria 1 and 2 of this checkpoint. User agent functionality (e.g., for "cut/copy/paste") or access keys (e.g., for "open new content") may be relied on to achieve success criteria 3 and 4 as long as the applicable user agent(s) are specified in the conformance profile.

A.2.2 For the authoring tool user interface, ensure author configurable access to selectable items. [Priority 3]

Rationale: Authors who have limited mobility require quick access to the items that they use frequently.

Techniques: Implementation Techniques for Checkpoint A.2.2

Success Criteria:

1. The author must have the option to set (and later modify) key-plus-modifier-key (or single-key) access for each selectable item.
2. There must be at least one editing interface area in which selectable items can be activated by a single action (e.g., toolbar, palette), where both of the following are true:
   • (a) the author can change the order of the items, and
   • (b) the author can select which items are available from the set of all selectable items.

A.2.3 For the authoring tool user interface, allow authors to control time limits. [Priority 1]

Rationale: Authors who have difficulty typing, operating the mouse, or processing information can be prevented from using systems with short time limits.

Note: Some time limits may be imposed by external systems. This checkpoint only applies to time limits within the control of the authoring tool.

Techniques: Implementation Techniques for Checkpoint A.2.3

Success Criteria:

1. If a time limit is not controlled by time-sensitive external constraints (e.g., actions of another author in a collaborative authoring system, external connection time-outs), then the time limit must meet at least one of the following:
   • (a) the author is able to deactivate the time limit,
   • (b) the author is able to adjust the time limit over a wide range that is at least ten times the length of the default setting, or
   • (c) the author is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (e.g., "hit any key"), and the author is allowed to extend the time limit at least ten times.

For Web-based authoring tool user interface functionality: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.

A.2.4 For the authoring tool user interface, allow authors to avoid flashing that could cause seizures due to photosensitivity. [Priority 1]

Rationale: Flashing can cause seizures in people with photosensitive epilepsy.

Techniques: Implementation Techniques for Checkpoint A.2.4

Success Criteria:

1. If flashing occurs in any part of the user interface (e.g., within a WYSIWYG editing view) that violates international health and safety standards for general flash or red flash, then the author must be able to do at least one of the following:
   • (a) the author is able to deactivate the flashing, or
   • (b) the author is able to adjust the rate of flashing so that it no longer violates international health and safety standards for general flash or red flash.

For Web-based authoring tool user interface functionality: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.

A.2.5 For the authoring tool user interface, ensure that editing views enable the author to navigate the structure and perform structure-based edits. [Priority 2]

Rationale: It is often efficient to make use of the structure that may be inherent within certain content in order to navigate editing views and perform edits. This is particularly important for people who are using a slow interface such as a small Braille device, speech output, or a single switch input device. It is equivalent to the ability provided by a mouse interface to move rapidly around the document.

Techniques: Implementation Techniques for Checkpoint A.2.5

Success Criteria:

1. If editing content that is a structured element set, the author must always be able to move the editing focus from any element to other elements in the set with any of the following relationships (if they exist):
   • (a) the element immediately above (i.e., parent),
   • (b) the first element immediately below (i.e., child),
   • (c) the element immediately preceding at the same level (i.e., previous sibling), and
   • (d) the element immediately following at the same level (i.e., next sibling).
2. If editing content that is a structured element set, the author must be able to select any element in the set and perform editing functions (e.g., cut, copy, paste, presentation) on that element, its contents, and its sub-elements.

A.2.6 For the authoring tool user interface, allow the author to search content, including markup, within the editing views. [Priority 2]

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

Techniques: Implementation Techniques for Checkpoint A.2.6

Success Criteria:

1. The author must be able to perform text searches of all text that is editable by the author, including text alternatives for non-text objects and metadata.
2. The author must be able to perform text searches of all markup that is editable by the author.

For Web-based authoring tool user interface functionality: Web-based authoring tools may rely on the "find" function of the user agent to help perform the searches, as long as the applicable user agent(s) are specified in the conformance profile.

A.2.7 For the authoring tool user interface, provide an undo function. [Priority 2]

Rationale: Authors who have difficulty making fine movements may be prone to making unintended actions. All authors benefit from the ability to easily recover from mistakes.

Note: It is acceptable to collect text entry actions (e.g., typed words, a series of backspaces) into a single author action.

Techniques: Implementation Techniques for Checkpoint A.2.7

Success Criteria:

1. Author actions that modify content must be either reversible by an "undo" function or include a warning to the author that the action is irreversible. An authoring tool may have certain committing actions (e.g., "save" function) that reset the undo history.
2. The author must be able to perform consecutive undos up to at least five reversible actions or until an irreversible action or committing action is reached.
3. The author must be able to immediately reverse the most recent undos (i.e., a "redo" function).

For Web-based authoring tool user interface functionality: Web-based authoring tools may rely on the "undo" function of the user agent to perform the undo function for some editing actions that do not involve server communication (e.g., typing in a text area), as long as the applicable user agent(s) are specified in the conformance profile.

A.2.8 For the authoring tool user interface, allow the author to have multiple sets of keyboard operability and display preferences settings. [Priority 2]

Rationale: Providing the ability to save and reload sets of keyboard and display preference settings is a benefit to authors using tools intended to be used by multiple authors as well as authors who have keyboard and display preference settings preferences that differ with fatigue, etc..

Techniques: Implementation Techniques for Checkpoint A.2.8

Success Criteria:

1. The author must be able to save and reload sets of preferences (e.g., personal profiles, personal settings), where each set contains preference settings related to the following (if present):
   • (a) keyboard operability (unless keyboard operability preferences are controlled by the platform),
   • (b) visual display (unless the visual display (e.g., fonts, sizes, colors, spacing, positioning) is controlled by the platform), and
   • (c) audio display (unless the audio display (e.g., volume, speech voices) is controlled by the platform).

A.2.9 For the authoring tool user interface, ensure previews emulate the accessible rendering features of target user agents. [Priority 2]

Rationale: Preview features are provided in many authoring tools because the workflow of authors often includes periodically checking how content will appear to end users in a user agent. In order to enable authors with disabilities to follow the same workflow as other authors, they must have access to any preview features that exist.

Note 1: Authors, including those with disabilities, will not be well-served if preview features diverge too much from the actual functionality of available user agents. Therefore, preview features are exempted from necessarily having to meet all of the other requirements in Part A of this guidelines document, if they meet this checkpoint.

Note 2: It is understood that the accessibility of the content display of a preview will be negatively affected if the content being rendered is inaccessible or incomplete. For example, a missing image label will result in an inaccessible image, which is useful information to the author.

Techniques: Implementation Techniques for Checkpoint A.2.9

Success Criteria:

1. If a preview feature is provided, then a mechanism of returning from the preview (i.e., moving focus back from, exiting from) must be provided that meets Checkpoint A.2.1 and is documented in the help system.
2. If a preview is provided, then it must meet at least one of the following:
   • (a) the preview makes use of an existing user agent (e.g., a third-party browser or browser component), or
   • (b) the preview meets all of the checkpoints in Part A.

GUIDELINE A.3: Authoring Tool User Interface must be Understandable

In order for an authoring tool to be accessible, authors with a wide range of abilities must be able to understand the user interface controls that they can perceive and operate.

A.3.1 For the authoring tool user interface, observe the accessibility conventions of the platform. [Priority 2]

Rationale: Authors are often familiar with accessibility conventions employed by the other applications built on a platform. Departures from those conventions have the tendency to disorient authors by creating an unfamiliar environment.

Techniques: Implementation Techniques for Checkpoint A.3.1

Success Criteria:

1. Focus and selection conventions for the current platform (specified in the conformance profile) must be followed.
2. Keyboard accessibility configuration conventions (e.g., default accelerator key bindings) for the platform (specified in the conformance profile) must be followed.

For Web-based authoring tool user interface functionality: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.

A.3.2 For the authoring tool user interface, maintain consistency. [Priority 2]

Rationale: Authors who may become disoriented easily will have less difficulty when consistent and predictable responses to author actions are provided. In general, consistent interfaces will benefit all authors to some degree.

Techniques: Implementation Techniques for Checkpoint A.3.2

Success Criteria:

1. Editing interface controls that are identified by the same text label or icon must always perform the same function.
2. When the same function (e.g., saving, running a checker or canceling an action) is available in multiple places within the editing interface (e.g., on multiple windows), at least one method of controlling the function must be available in each place using the same text label or icon.

For Web-based authoring tool user interface functionality: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.

A.3.3 For the authoring tool user interface, document the user interface including all accessibility features. [Priority 1]

Rationale: While intuitive user interface design is valuable to many authors, some authors may still not be able to understand or be able to operate the authoring tool user interface without proper documentation.

Techniques: Implementation Techniques for Checkpoint A.3.3

Success Criteria:

1. At least one version of the documentation must conform to the minimum requirements (e.g., "Level A") of WCAG, although it does not necessarily need to be located on-line.
2. All features from Part A that benefit the accessibility of the editing interface must be documented (e.g., keyboard shortcuts).

GUIDELINE A.4: Authoring Tool User Interface must be Access System Friendly

Assistive technologies (e.g., screen readers, screen magnifiers) can only provide augmented display and control to their users if the authoring tools support and document the communication protocols upon which they depend.

A.4.1 For the authoring tool user interface, support interoperability with assistive technologies. [Priority 1]

Rationale: Assistive technologies that are used by many authors with disabilities (e.g., screen readers, screen magnifiers) rely on the authoring tool to provide data and control via prescribed communication protocols.

Techniques: Implementation Techniques for Checkpoint A.4.1

Success Criteria:

1. The authoring tool must implement the accessibility platform architecture(s) relevant to the development platform (e.g., MSAA for Windows applications, Java Access for Java applications).
2. All of the following information must be published about the implementation of the accessibility platform architecture(s):
   • (a) Specify if only the default support is provided.
   • (b) Otherwise, provide information (e.g., accessible name, accessible description, accessible role) for each GUI component that can receive focus, as defined by the accessibility architecture used.
   • (c) Detail any deviation from their proper use (i.e., lack of use, incomplete use, inappropriate use) as defined by the documentation for the accessibility platform architecture.
3. If there is any authoring tool user interface functionality that is not supported by the relevant accessibility platform architecture(s), then at least one of the following must be done:
   • (a) provide an accessible equivalent for the functionality that is supported by the relevant accessibility platform architecture(s).
   • (b) provide an alternative interoperability mechanism with published documentation so that the functionality would be available to an assistive technology implementing the mechanism.
   • (c) describe the inaccessible functionality in the conformance claim.

For Web-based authoring tool user interface functionality: Web-based authoring tools will rely on the accessibility platform architecture support of the user agent and therefore meeting Checkpoint A.0.1 will serve to meet this checkpoint.

A.4.2 For the authoring tool user interface, document how the authoring interface makes use of existing accessibility architectures. [Priority 3]

Rationale: When the use of accessibility architectures is fully documented, assistive technology developers are able to provide enhanced user interface access.

Techniques: Implementation Techniques for Checkpoint A.4.2

Success Criteria:

1. Additional information must be published describing the nature and use of the information provided in Checkpoint A.4.1 (e.g., that the long description is different from the associated tool tip).

For Web-based authoring tool user interface functionality: Web-based authoring tools will rely on the accessibility platform architecture support of the user agent and therefore meeting Checkpoint A.0.1 will serve to meet this checkpoint.

GUIDELINE B.1: Enable the production of 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.

B.1.1 Support content types that enable the creation of content that conforms to WCAG. [Priority 1]

Rationale: Content types with published content type-specific WCAG benchmark documents facilitate the creation of Web content that can be assessed for accessibility with WCAG.

Techniques: Implementation Techniques for Checkpoint B.1.1

Success Criteria:

1. Any authoring tool that chooses the content type used for publication on the Web for the author must always choose content types for which a published content type-specific WCAG benchmark document exists.
2. Any authoring tool that allows authors to choose the content type used for publication on the Web must always support at least one content type for which a published content type-specific WCAG benchmark document exists and must always give prominence to those content types.

B.1.2 Ensure that the authoring tool preserves accessibility information during transformations and conversions. [Priority 1]

Rationale: Accessibility information is critical to maintaining comparable levels of accessibility across transformations and conversions.

Techniques: Implementation Techniques for Checkpoint B.1.2

Success Criteria:

1. During all transformations and conversions supported by the authoring tool, accessibility information must always be handled according to the following:
   • (a) the accessibility information is available to end users in the result of the transformation or conversion, or
   • (b) if the accessibility information cannot be preserved, notify the author and keep a copy in the original form (e.g., by commenting out a table converted into a list, by saving a document prior to converting it into a different format).

B.1.3 Ensure that the author is notified before content is automatically removed. [Priority 2]

Rationale: Automatically removing markup can cause the unintentional loss of structural information. Even unrecognized markup may have accessibility value, since it may include recent technologies that have been added to enhance accessibility.

Techniques: Implementation Techniques for Checkpoint B.1.3

Success Criteria:

1. The authoring tool must provide an option to notify the author before permanently removing content using an automatic process.

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

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

Note: If accessibility information is required from the author during the automatic generation process, Checkpoint B.2.1 applies.

Techniques: Implementation Techniques for Checkpoint B.1.4

Success Criteria:

1. All content that is automatically generated by the authoring tool (i.e., not authored "by hand") must conform to WCAG.

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

Rationale: Pre-authored content, such as templates, images, and videos, is often included with authoring tools for use by the author. When this content conforms to WCAG, it is more convenient for authors and more easily reused.

Note: If accessibility information is required from the author during use, Checkpoint B.2.1 applies.

Techniques: Implementation Techniques for Checkpoint B.1.5

Success Criteria:

1. Any content (e.g., templates, clip art, example pages, graphical widgets) that is bundled with the authoring tool or preferentially licensed to the users of the authoring tool (i.e., provided for free or sold at a discount) must conform to WCAG when used by the author.

GUIDELINE B.2: 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.

B.2.1 Prompt and assist the author to create content that conforms to WCAG. [Relative Priority]

Rationale: The authoring tool should help to prevent the author from making decisions or omissions that cause accessibility problems. If Web content accessibility problems are prevented, less effort is required to create content that conforms to WCAG. Different tool developers will accomplish this goal in ways that are appropriate to their products, processes, and authors.

Techniques: Implementation Techniques for Checkpoint B.2.1

Success Criteria:

1. The authoring tool must provide an option to notify the author when content is added or updated, that requires accessibility information from the author to conform to WCAG (e.g., using a dialog box, using interactive feedback).
2. Instructions provided to the author by the authoring tool must (if followed) meet one of the following:
   • (a) lead to the creation of content that conforms to WCAG, or
   • (b) inform the author that following the instructions would lead to Web content accessibility problems.

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

Rationale: Authors may not notice or be able to check for accessibility problems without assistance from the authoring tool.

Note: While automated checking and more advanced implementations of semi-automated checking may improve the authoring experience, this is not required to meet the success criteria for this checkpoint.

Techniques: Implementation Techniques for Checkpoint B.2.2

Success Criteria:

1. An individual check must be associated with each requirement in the content type-specific WCAG benchmark document (i.e., not blanket statements such as "does the content meet all the requirements").
2. For checks that are associated with a type of element (e.g., img), each element instance must be individually identified as potential accessibility problems. For checks that are relevant across multiple elements (e.g., consistent navigation) or apply to most or all elements (e.g., background color contrast, reading level), the entire span of elements must be identified as potential accessibility problems, up to the entire content if applicable.
3. If the authoring tool relies on author judgment to determine if a potential accessibility problem is correctly identified, then the message to the author must be tailored to that potential accessibility problem (i.e., to that requirement in the context of that element or span of elements).
4. The authoring tool must present checking as an option to the author at or before the completion of authoring.

Note: This checkpoint does not apply to authoring tools that constrain authoring choice to such a degree that it is not possible to create content that does not conform to WCAG.

B.2.3 Assist authors in repairing accessibility problems. [Relative Priority]

Rationale: Assistance by the authoring tool may simplify the task of repairing accessibility problems for some authors, and make it possible for others.

Note: While automated repair and semi-automated repair may improve the authoring experience, providing repair instructions is sufficient to meet the success criteria for this checkpoint.

Techniques: Implementation Techniques for Checkpoint B.2.3

Success Criteria:

1. For each potential accessibility problem identified by the checking function (required in Checkpoint B.2.2), at least one of the following must be provided:
   • (a) repair instructions, for the author to follow, that are specific to the accessibility problem or
   • (b) an automated repair or semi-automated repair mechanism.

B.2.4 Assist authors to ensure that equivalent alternatives for non-text objects are accurate and fit the context. [Priority 1]

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

Techniques: Implementation Techniques for Checkpoint B.2.4

Success Criteria:

1. If the authoring tool offers text alternatives for non-text objects, then the source of the alternatives for each object must be at least one of the following:
   • (a) text alternatives previously entered by authors for the non-text object (e.g., by the same author, or another author on a collaborative system),
   • (b) text alternatives stored with the non-text object in an image database (or equivalent), or
   • (c) null text alternatives for non-text objects that are only used only for visual formatting.
   (Text alternatives should not be generated from unreliable sources. File names are generally not acceptable, although in some cases they will be (e.g., if they store alternatives previously entered by authors))
2. The authoring tool must allow the author to accept, modify, or reject equivalent alternatives.

B.2.5 Provide functionality for managing, editing, and reusing equivalent alternatives. [Priority 3]

Rationale: Simplifying the initial production and later reuse of equivalent alternatives will encourage authors to use them more frequently. In addition, such an alternative equivalent management system will facilitate meeting the requirements of Checkpoints B.2.1, B.2.2, B.2.3 and B.2.4.

Techniques: Implementation Techniques for Checkpoint B.2.5

Success Criteria:

1. The authoring tool must have the option of storing for future re-use the following author added equivalent alternatives for non-text objects (if applicable):
   • (a) plain text text alternatives that the authoring tool stores directly (e.g., alternative text labels, long text descriptions), and
   • (b) URI referenced synchronized alternatives or accessible multimedia alternatives that the authoring tool stores only indirectly (i.e., as URIs to external resources) (e.g., captions for video, sign language interpretation videos).

B.2.6 Provide the author with a summary of accessibility status. [Priority 3]

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

Techniques: Implementation Techniques for Checkpoint B.2.6

Success Criteria:

1. The authoring tool must provide an option to view a list of all known accessibility problems (i.e., detected by automated checking or identified by the author) prior to completion of authoring.

B.2.7 Provide the author with a tutorial on the process of accessible authoring. [Priority 3]

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

Techniques: