Authoring Tool Accessibility Guidelines 2.0

1.2 Definition of authoring tool

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. 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 conformance claim.
2. Required: Information about the authoring tool. If the authoring tool is comprised of components (e.g. markup editor, image editor, and validation tool), information should be provided separately for each component:
   • Name and version information for the component. Version information must be sufficient to identify the tool (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").
3. Required: A conformance profile that must include the following:
   • The version and URI of the Authoring Tool Accessibility Guidelines 2.0 document that was used for the evaluation.
   • The ATAG 2.0 conformance level that has been satisfied (choose one of: "A", "Double-A", "Triple-A").
   • The content type(s) produced by the authoring tool that are covered by the evaluation. For each content type covered by the evaluation, the URI of a content type-specific WCAG benchmark document must be provided. (e.g. "HTML 4.01, http://www.sample.org/html401_wcag20_benchmark.html")
   • For authoring tools with Web-based user interface components:
     • The version and URI of the Web Content Accessibility Guidelines document that the user interface was evaluated against ( e.g. "Web Content Accessibility Guidelines 2.0 Working Draft, http://www.w3.org/TR/WCAG20/"). @@(A content type-specific WCAG benchmark document may be provided for all of the content types with which the user interface is implemented).
     • The name and version number of the user agent(s) on which the components were evaluated for conformance.
   • For authoring tools with user interface components that are not Web-based:
     • The name and version number of the operating system platform(s) on which the authoring tool was evaluated for conformance.
   • For authoring tools with a preview feature that does not make use of external browser(s):
     • The name and version number of the user agent(s) which the preview feature is intended to emulate (or comes closest to emulating).
4. Required: A description of how the authoring tool meets each of the normative success criteria for each of the checkpoints that are required for the conformance level that has been specified by the conformance profile.
   • For relative priority checkpoints this means describing how the requirements of the Content Type-Specific WCAG Benchmark 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 ("What-you-see-is-what-you-get") 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.

It is important to note that:

• All of the requirements in the Benchmark document become mandatory for a particular evaluation by the act of the evaluator including a reference to the Benchmark URI in the ATAG 2.0 conformance profile.
• The Benchmark document can be created by any person or organization (although the AUWG does suggest checking to see if a Benchmark document has already been published by the W3C or other provider, before creating a new one).
• The Benchmark document must be publicly published on the Web (the URI will appear in the conformance profile) where it will be open to public and market scrutiny.

A.0.1 Ensure that browser-accessed functionality conforms to WCAG. [Relative Priority]

Rationale: Authors must be able to have access to authoring tool functionality that is implemented as Web content.

Note: For non-Web-based authoring tools, this is a relatively straightforward requirement, likely covering only a few areas of the interface (i.e. Web-based help features, etc.). 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.

Techniques: Implementation Techniques for Checkpoint A.0.1

Success Criteria:

1. Any component of an authoring tool that is accessed by the author within a Web browser must conform to WCAG.

GUIDELINE A.1 Authoring Interface must be Perceivable

A.1.1 Provide text alternatives for all non-text content in the user interface. [Priority 1]

Rationale: People who have difficulty perceiving non-text content can often access the same information if it is conveyed using a text alternative (by assistive technology or braille, for example).

Techniques: Implementation Techniques for Checkpoint A.1.1

Success Criteria:

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

For Web-Based Interface Components: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.

A.1.2 Provide synchronized alternatives for multimedia in the user interface. [Priority 1]

Rationale: People who have difficulty accessing or interpreting multimedia-supported information in the authoring 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 user interface multimedia that is used to convey information (e.g., tutorial videos, progress indicators, etc.) 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.

For Web-Based Interface Components: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.

A.1.3 Ensure that all displays are configurable. [Priority 1]

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

Note: The success criteria for this checkpoint are based on the capabilities of platforms (e.g. operating systems, browsers, GUI toolkits, etc. 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 (fonts, sizes, colors, spacing, positioning, etc.) 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 (volume, speech voices, etc.) 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.

For Web-Based Interface Components: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.

A.1.4 Allow the display preferences for the editing view 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 display styles that they want to define for the published document (e.g. a particular text-background combination that differs from the published version).

Techniques: Implementation Techniques for Checkpoint A.1.4

Success Criteria:

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

ATAG Checkpoint A.1.5: Ensure that information, functionality, and structure can be separated from presentation. [Priority 1]

Rationale: Separating content and structure from presentation allows 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 originally 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.

Success Criteria:

1. For author-controlled presentation (e.g. author has used a style class) in rendered editing views , all characteristics of the presentation (e.g. color, boldness, positioning, etc.) must be available programmatically.
2. For authoring tool-controlled presentation in editing views (e.g. coloring misspelled words, identifying tag text in a code view), the semantic description of the presentation must be available programmatically.
3. For the presentation of controls within the editing interface of the authoring tool user interface (e.g. dialog boxes, menus, button bars, user interface elements in the editing view), the semantic description of the presentation must be available programmatically.
4. Any information that is conveyed by color (e.g. red underlining for spelling error vs. green underlining for grammar error) is either visually evident when color is not available (e.g. by the shape of the underlining) or is provided by an alternative version that meets Part A (e.g. spell and grammar checking utilities).

For Web-Based Interface Components: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.

GUIDELINE A.2: Authoring Interface must be Operable

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

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 (e.g. navigating, selecting, and editing content within editing views, operating the user interface, installing and configuring the authoring tool, and accessing documentation) that is available through the user interface. (Note: an authoring task may have multiple user mechanisms, e.g. a menu item and a button bar item, at least one of which must satisfy this success criteria)
2. There must be an option that ensures that selection is separate from activation (e.g. navigating through the items in a dropdown menu without activating any of the items).
3. There must be an option to enable single-key access to the following functionalities:
   • move content focus to the next enabled control in user interface (e.g. using "tab" key).
   • navigate forward and backward within editing views (e.g. using "arrow" keys).
4. There must be an option to enable key-plus-modifier-key (or single-key) access to the following functionalities (if present):
   • move content focus to the previous enabled control (e.g. using "shift-tab" key).
   • navigate between panels or windows
   • open help system
   • open new content
   • open existing content
   • save content
   • close content
   • cut/copy/paste
   • undo/redo
   • open find/replace function
   • navigate to the start and end

For Web-Based Interface Components: Meeting Checkpoint A.0.1 will serve to meet success criteria 1 and 2 of this checkpoint. Browser 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. Also see Checkpoint A.3.1 when choosing keystrokes.

A.2.2 Ensure user configurable access to selectable actions. [Priority 3]

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

Techniques: Implementation Techniques for Checkpoint A.2.2

Success Criteria:

1. There must be an option to add and modify key-plus-modifier-key (or single-key) access to all selectable actions.
2. There must be an option to customize the items (from the set of all selectable actions) and their order within at least one area of the user interface that is controllable by a single selection (e.g. button bar, palette, panel, etc).

A.2.3 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. All user interface time limits must be author configurable unless they are controlled by time-sensitive external processes (e.g. time-outs of systems outside of the authoring tool).
2. If a time limit is under the control of the authoring tool, it must not be less than 20 seconds and must be extendible with a single input action.

For Web-Based Interface Components: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.

A.2.4 Allow authors to avoid content 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. Authors must be able to turn off flashing in the user interface that violates international health and safety standards for general flash or red flash.

For Web-Based Interface Components: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.

A.2.5 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 Web content in order to navigate editing views and perform edits.

Techniques: Implementation Techniques for Checkpoint A.2.5

Success Criteria:

1. For any structured element set, the author must always be able to move the editing focus from any element to any other element with the following relationship (if they exist): the element immediately above (i.e. parent), the first element immediately below (i.e. child), the element immediately preceding at the same level (i.e. previous sibling), and the element immediately following at the same level (i.e. next sibling).
2. For any structured element set, the author must always be able to select content and perform editing functions (e.g. cut, copy, paste, styling) on any element along with any content, including sub-elements.

A.2.6 Allow the author to search content and 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 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 content that is editable by the author.
2. The author must be able to perform text searches of all markup that is editable by the author.

For Web-Based Interface Components: Web-based authoring tools may make use of the find function of the browsers to help perform the searches.

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

Techniques: Implementation Techniques for Checkpoint A.2.7

Success Criteria:

1. Actions that modify content must be either reversible with an undo function or include a warning to the author that the action is irreversible.
2. The author must be able to perform a series of multiple undos.
3. The author must be able to undo any series of undos.

For Web-Based Interface Components: Web-based authoring tools may rely on the undo function of the browser to perform the undo function for editing actions that do not involve server communication (e.g. typing in a text area). Therefore, all Web-based interface components, that meet Checkpoint A.0.1 will serve to meet this checkpoint as long as the user agent(s) specified in the conformance profile have the ability to perform at least one level of text entry undo.

A.2.8 Provide personalized configuration. [Priority 2]

Rationale: When a large number of configuration settings are available, authors working on shared systems benefit from the ability to save and later reload a personal settings file.

Techniques: Implementation Techniques for Checkpoint A.2.8

Success Criteria:

1. The authoring tool must provide the ability to save and reload all configuration settings related to visual or auditory output and keyboard operability.
2. The author must be able to select, within the application, from multiple configuration sets.

A.2.9 Ensure previews emulate the accessible rendering features of target browsers [Priority 2]

Rationale: The workflow of many authoring tools includes periodically checking a preview of how content will appear to end users in a browser. Authors with disabilities need to have access to a preview so that they can check all aspects of their work (i.e. not just the accessibility of that work). For this reason the preview needs to be as, but not more, accessible than the target browser(s).

Note 1: This requirement serves, for the preview feature(s) only, in lieu of the other user interface accessibility requirements in Part A.

Note 2: In addition, it is expected that the operation of the preview accessibility features will be constrained by the accessibility and/or completeness of the content. For example, an incomplete document may not be renderable by the preview.

Techniques: Implementation Techniques for Checkpoint A.2.9

Success Criteria:

1. If a preview is provided, then:
   • (a) The author must be able to choose an external browser to perform the preview
   • (b) or, the preview must provide the same accessibility features as a target browser (which must be identified in the conformance profile) that is being emulated and the following must be true:
     • Any other part of the user interface other than the content being previewed must meet the other requirements of Part A.
     • A means of exiting the preview must be provided that meet the other requirements of Part A.
   • (c) or, the preview does not claim to emulate a specific browser, in which case it must meet all of the requirements of Part A. In other words, Note 1 does not apply.

GUIDELINE A.3 : Authoring Interface must be Understandable

A.3.1 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 current platform (specified in the conformance profile) must be followed.

For Web-Based Interface Components: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.

A.3.2 Maintain consistency within the authoring tool user interface. [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. User interface controls with the same text label or icon must perform the same function.
2. Any text label or icon must not have more than one function.
3. When the same function (e.g. saving, running a checker or canceling an action) is available in multiple areas of an authoring tool user interface, at least one method of controlling the function must be implemented for each area using identical user interface elements.

For Web-Based Interface Components: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.

A.3.3 Document the authoring interface including all interface accessibility features. [Priority 1]

Rationale: While intuitive authoring interface design is valuable to many authors, some authors may still not be able to understand or be able to operate the authoring interface without thorough documentation. For instance, an author who is blind may not find a graphical authoring interface intuitive without supporting 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 (Level 1) of WCAG (whether delivered on the Web, CD-ROM, etc.).
2. All features that benefit the accessibility of the authoring interface must be documented in the help system (e.g., keyboard shortcuts).
3. The current configuration of selectable actions must be displayed in either a centralized fashion (e.g., a list of keyboard shortcuts) or a distributed fashion (e.g., by listing keyboard shortcuts in the user interface menus).

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

A.4.1 Support interoperability with assistive technologies. [Priority 1]

Rationale: Assistive technologies (e.g. screen readers, screen magnifiers, etc.) used by many authors with disabilities rely on software applications to provide data and control via prescribed communication protocols.

Techniques: Implementation Techniques for Checkpoint A.4.1

Success Criteria:

1. The authoring tool must follow accessibility platform architectures (e.g. MSAA, Java Access, etc.).
2. If there is any authoring tool functionality or information that is not addressed by available accessibility platform architectures, another published interoperability mechanism must be provided so that all authoring tasks can be accomplished in at least one way by an assistive technology implementing the mechanism.

For Web-Based Interface Components: 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 Web 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 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 exists and always give prominence to those content types.

B.1.2 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 or transformations. Accessibility information should also be preserved.

Techniques: Implementation Techniques for Checkpoint B.1.2

Success Criteria:

1. During all transformations and conversions supported by the authoring tool, the author must be notified before any unrecognized markup is permanently removed.
2. During all transformations and conversions supported by the authoring tool, accessibility information must always be handled according to at least one of the following:
   • (a) preserve it in the target format such that the information can be "round-tripped" (i.e. converted or transformed back into its original form) by the same authoring tool,
   • (b) preserve it in some other way in the target format, or
   • (c) be removed only after the author has been notified and the content has been preserved in its original format.

B.1.3 Ensure that when the 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: WCAG includes a markup validity requirement.

Techniques: Implementation Techniques for Checkpoint B.1.3

Success Criteria:

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

B.1.4 Ensure that all pre-authored content for the 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.

Techniques: Implementation Techniques for Checkpoint B.1.4

Success Criteria:

1. Any Web content (e.g., templates, clip art, example pages, graphical widgets, etc.) 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. Every time that content that requires accessibility information from the author in order to conform to WCAG is added or updated, then the authoring tool must inform the author that this additional information is required (e.g. via input dialogs, interactive feedback, etc.).
2. Whenever the tool provides instructions to the author, either the instructions (if followed) must lead to the creation of Web content that conforms to WCAG, or the author must be informed 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 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, etc.) or apply to most or all elements (e.g. background color contrast, reading level, etc.), 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 Web 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) provide at least one of the following:
   • repair instructions, for the author to follow, that are specific to the accessibility problem
   • an automated repair or semi-automated repair mechanism

B.2.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 equivalent alternatives can create accessibility problems and interfere with accessibility checking.

Techniques: Implementation Techniques for Checkpoint B.2.4

Success Criteria:

1. The tool must never use automatically generated equivalent alternatives for a non-text object (e.g. a short text label generated from the file name of the object).
2. When a previously authored equivalent alternative is available (i.e. created by the author, pre-authored content developer, etc.), the tool must prompt the author to confirm insertion of the equivalent unless the function of the non-text object is known with certainty (e.g. "home button" on a navigation bar, etc.).

B.2.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 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 always keep a record of alternative equivalents that the author inserts for particular non-text objects in a way that allows the text equivalent to be offered back to the author for modification and re-use if the same non-text object is reused.

B.2.6 Provide the author with a summary of 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: 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 Document in the help system all features of the tool that support the production of accessible content. [Priority 2]

Rationale: Without documentation of the features that support the production of accessible content (e.g. prompts for alternatives, code validators, accessibility checkers, etc.) authors may not find or use them.

Techniques: Implementation Techniques for Checkpoint B.2.7

Success Criteria:

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

B.2.8 Ensure that accessibility is demonstrated in all documentation and help, including examples. [Priority 3]

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 can also facilitate a better understanding of the reasoning behind and the consequences of authoring accessible content.

Techniques: Implementation Techniques for Checkpoint B.2.8

Success Criteria:

1. All examples of markup and screenshots of the authoring tool user interface that appear in the documentation and help must demonstrate accessible Web content.

B.2.9 Provide 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: Implementation Techniques for Checkpoint B.2.9

Success Criteria:

1. A tutorial on the accessible authoring process for the specific authoring tool must be provided.

GUIDELINE B.3: Promote and integrate accessibility solutions

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.

Note: In addition to the normative requirements of this guideline, implementers should consider one other issue: the integration of accessibility features, such as prompting, checking and repair with the "look-and-feel" of other features of the authoring tool. This type of integration has the potential to:

• produce a seamless product;
• leverage the existing knowledge and skills of authors;
• make authors more receptive to new authoring requirements; and
• reduce the likelihood of confusion.

However, whenever new features are introduced into an authoring tool, striking the right design balance between the similarity with existing features and the provision of new functionality is often more of an art than a science.

B.3.1 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 option for a given authoring task.

Techniques: Implementation Techniques for Checkpoint B.3.1

Success Criteria:

1. When the author has more than one authoring option for a given task (e.g. changing the color of text can be changed with presentation markup or style sheets) then any options that conform to WCAG must have equal or higher prominence than any options that do not.
2. Any choices of content types or authoring practices presented to the author (e.g., in menus, toolbars or dialogs) that will lead to the creation of content that does not conforms to WCAG must be marked or labeled so that the author is aware of the consequences prior to making the choice.

B.3.2 Ensure that accessibility prompting, checking, repair functions, and documentation are always clearly available to the author. [Priority 2]

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

Techniques: Implementation Techniques for Checkpoint B.3.2

Success Criteria:

1. All accessibility prompting, checking, repair functions and documentation that is continuously active must always be enabled by default and if the author disables them (e.g. from a preferences screen), then the tool must inform the author that this may increase the risk of accessibility problems.
2. All user interface controls for accessibility prompting, checking, repair functions and documentation must have at least the same prominence as the controls for prompting, checking, repair and documentation for other types of Web content problems (e.g. markup validity, program code syntax, spelling and grammar).

B.3.3. Ensure that sequential authoring processes integrate accessible authoring practices. [Priority 2]

Rationale: Accessible design as an afterthought or separate process is much more onerous and therefore costly than when accessibility is considered from the start. If the authoring tool supports the author in considering accessibility before and/or during the authoring process it is more likely that accessible authoring practices will become a common practice. This is analogous to internationalization, which is much easier when it is considered from the beginning rather than handled last.

Techniques: Implementation Techniques for Checkpoint B.3.3

Success Criteria:

1. Interactive features that sequence author actions (e.g. object insertion dialogs, templates, wizards) must provide any accessibility prompts relevant to the content being authored at or before the first opportunity to complete the interactive feature (without canceling).
2. For read-only instruction text (e.g. tutorials, reference manuals, design guides, etc.) that includes a sequence of steps for the author to follow, the relevant accessibility authoring practices must appear in the step sequence before the first opportunity to complete the sequence.

B.3.4 Ensure that accessibility prompting, checking, repair functions and documentation are configurable. [Priority 3]

Rationale: A configurable tool is more likely to be adaptable to the work habits of more authors.

Techniques: Implementation Techniques for Checkpoint B.3.4

Success Criteria:

1. The configurability of all functions related to accessibility prompting, checking, repair, and documentation must at least match the configurability of other prompting, checking, repair, and documentation functions of the tool (respectively), in terms of both of the following:
   • (a) the range of options controllable by the author, and
   • (b) the degree to which each option can be controlled