W3C

Appendix A. Checklist of Checkpoints for Authoring Tool Accessibility Guidelines 2.0

This version:
http://www.robertoscano.info/files/atag20/full-checklist.html
Latest version:
http://www.robertoscano.info/files/atag20/full-checklist-20060225.html
Previous version:
http://www.robertoscano.info/files/atag20/full-checklist-20051024.html
Editors:
Roberto Scano - IWA/HWG

Abstract

This document is an appendix to the W3C "Authoring Tool Accessibility Guidelines 2.0" (W3C Working Draft 16 December 2005). It provides a list of all checkpoints from the Authoring Tool Accessibility Guidelines 2.0, organized by priority, as a checklist for authoring tools developers, authoring tools users and evalutators. Please refer to the Guidelines document for introductory information, information about related documents, a glossary of terms, and more.

This list may be used to review an authoring tool for accessibility. For each checkpoint, indicate whether the checkpoint has been satisfied, has not been satisfied, or is not applicable.

This document has been produced as part of the Web Accessibility Initiative. The goal of the WAI Authoring Tool Accessibility Guidelines Working Group is discussed in the Working Group charter.

Status of this document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document is an appendix to a document which will supersede the W3C Recommendation Authoring Tool Accessibility Guidelines 1.0 [ATAG10]. It has been made available for review by W3C Members and other interested parties, in accordance with W3C Process. It is not endorsed by the W3C or its Members. It is inappropriate to refer to this document other than as a work in progress.

This document has been produced by the Authoring Tool Accessibility Guidelines Working Group (AUWG) as part of the Web Accessibility Initiative (WAI). The goals of the Working Group are discussed in the AUWG charter. The AUWG is part of the WAI Technical Activity.

The Working Group maintains a list of patent disclosures and issues related to ATAG 2.0.

ATAG 2.0 depends on WCAG to act as a benchmark for judging the accessibility of Web content and Web-based authoring interfaces and also to define the terms "Accessible Web Content" and "Accessible Authoring Interface".

At the time of publication, version 1.0 of WCAG is a W3C Recommendation [WCAG10], and a second version of the guidelines is under development [WCAG20]. @@edit when WCAG is rec@@ Importantly, WCAG 2.0 has a different Conformance Model than that of WCAG 1.0 (see discussion in the conformance section of WCAG 2.0)

Note that within the guidelines section of ATAG 2.0, references are made to WCAG without an associated version number. This has been done to allow developers to select, and record in the conformance profile, whichever version of WCAG is most appropriate for the circumstances of a given authoring tool. The Working Group does recommend considering the following factors when deciding on which WCAG version to use:

The AUWG expects the ATAG 2.0 to be backwards-compatible with ATAG 1.0, or at most to make only minor changes in requirements. Before this document reaches last call, the Working Group will publish a detailed analysis of the differences in requirements.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

Please send comments about this document to the public mailing list: w3c-wai-au@w3.org (public archives). Please note that this document may contain typographical errors. It was published as soon as possible since review of the content itself is important, although noting typographical errors is also helpful.

For information about the current activities of the working group, please refer to the AUWG home page. This page includes an explanation of the inter-relation of each document as well as minutes and previous drafts.

Checkpoint priority levels

Each checkpoint has been assigned a priority level that indicates the importance of the checkpoint in satisfying the guideline under which the checkpoint appears. The priority of a checkpoint determines whether that checkpoint must be met in order for an authoring tool to achieve a particular conformance level. There are three levels of "regular priority" checkpoints as well as a special class of "relative priority" checkpoints that rely on WCAG as a benchmark for determining what is considered accessible Web content.

"Regular Priority" Checkpoints

Priority 1
in Part A: Indicates that if the authoring tool does not satisfy these checkpoints, one or more groups of authors with disabilities will find it impossible to author for the Web.
in Part B: Indicates that these checkpoints are essential for any authors using the authoring tool to create Web content that conforms to WCAG.
Priority 2
in Part A: Indicates that if the authoring tool does not satisfy these checkpoints, one or more groups of authors with disabilities will find it difficult to author for the Web.
in Part B: Indicates that these checkpoints are important for any authors using the authoring tool to create Web content that conforms to WCAG.
Priority 3
in Part A: Indicates that if the authoring tool does not satisfy these checkpoints, one or more groups of authors with disabilities will find it inefficient to author for the Web.
in Part B: Indicates that these checkpoints are beneficial for any authors using the authoring tool to create Web content that conforms to WCAG.

"Relative Priority" Checkpoints

The importance of the "relative priority" checkpoints depends on the requirements defined by whichever version of WCAG the evaluator has defined in the conformance profile. These checkpoints can be met to one of three levels:

Level 1
in Part A: Indicates that the WCAG benchmark met by the Web content in the authoring interface (if this is applicable) is set at the minimum conformance level (either WCAG 1.0 Level "A" or WCAG 2.0 Level "A" (as defined in the conformance profile)).
in Part B: Indicates that the WCAG benchmark produced by the tool is set at the minimum conformance level (either WCAG 1.0 Level "A" or WCAG 2.0 Level "A" (as defined in the conformance profile)).
Level 2
in Part A: Indicates that the WCAG benchmark met by the Web content in the authoring interface (if this is applicable) is set at the intermediate conformance level (either WCAG 1.0 Level "Double-A" or "WCAG 2.0 Level AA" (as defined in the conformance profile)).
in Part B: Indicates that the WCAG benchmark produced by the tool is set at the intermediate conformance level (either WCAG 1.0 Level "Double-A" or "WCAG 2.0 Level AA" (as defined in the conformance profile)).
Level 3
in Part A: Indicates that the WCAG benchmark met by the Web content in the authoring interface (if this is applicable) is set at the stringent conformance level (either WCAG 1.0 Level "Triple-A" or "WCAG 2.0 Level AAA" (as defined in the conformance profile)).
in Part B: Indicates that the WCAG benchmark produced by the tool is set at the stringent conformance level (either WCAG 1.0 Level "Triple-A" or "WCAG 2.0 Level AAA" (as defined in the conformance profile)).

Note: The choice of priority level for each checkpoint is based on the assumption that the author is a competent, but not necessarily expert, user of the authoring tool, and that the author has little or no knowledge of accessibility. For example, the author is not expected to have read all of the documentation, but is expected to know how to turn to the documentation for assistance.

"Regular Priority" Checkpoints

Priority 1 checkpoints

CheckpointSuccess CriteriaYesNoN/A
A.1.1 Provide text alternatives for all non-text content in the user interface. (Techniques for A.1.1)
  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. (Techniques for A.1.2)
  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. (Techniques for A.1.3)
  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. (Techniques for A.1.4)
  1. The author must be able to configure the presentation settings of editing views without affecting the Web content being edited.
     
A.1.5 Ensure that information, functionality, and structure can be separated from presentation. (Techniques for A.1.5)
  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.

     
A.2.1 Ensure that all functionality is operable via a keyboard or a keyboard interface. (Techniques for A.2.1)
  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.3 Allow authors to control time limits. (Techniques for A.2.3)
  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. (Techniques for A.2.4)
  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.3.3 Document the authoring interface including all interface accessibility features. (Techniques for A.3.3)
  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).
     
A.4.1 Support interoperability with assistive technologies. (Techniques for A.4.1)
  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.

     
B.1.1 Support content types that enable the creation of Web content that conforms to WCAG. (Techniques for B.1.1)
  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.2.4 Do not automatically generate equivalent alternatives or reuse previously authored alternatives without author confirmation, except when the function is known with certainty. (Techniques for B.2.4)
  1. When the author inserts an unrecognized non-text object, the tool must never insert an automatically generated text equivalent (e.g. a label generated from the file name).
  2. When the author inserts a non-text object for which the tool has a previously authored equivalent alternatives (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 always 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.
     

Priority 2 checkpoints

CheckpointSuccess CriteriaYesNoN/A
A.2.5 Ensure that editing views enable the author to navigate the structure and perform structure-based edits. (Techniques for A.2.5)
  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. (Techniques for A.2.6)
  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. (Techniques for A.2.7)
  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. (Techniques for A.2.8)
  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. (Techniques for A.2.9)
  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.
     
A.3.1 Observe the accessibility conventions of the platform. (Techniques for A.3.1)
  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. (Techniques for A.3.2)
  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.

     
B.1.2 Ensure that the tool preserves all unrecognized markup and accessibility information during transformations and conversions. (Techniques for B.1.2)
  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.2.7 Document in the help system all features of the tool that support the production of accessible content. (Techniques for B.2.7)
  1. All features that play a role in creating accessible content must be documented in the help system.
     
B.3.1 Ensure that the most accessible option for an authoring task is given priority. (Techniques for B.3.1)
  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. (Techniques for B.3.2)
  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. (Techniques for B.3.3)
  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.
     

Priority 3 checkpoints

CheckpointSuccess CriteriaYesNoN/A
A.2.2 Ensure user configurable access to selectable actions. (Techniques for A.2.2)
  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).
     
B.2.5 Provide functionality for managing, editing, and reusing alternative equivalents. (Techniques for B.2.5)
  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. (Techniques for B.2.6)
  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.8 Ensure that accessibility is demonstrated in all documentation and help, including examples. (Techniques for B.2.8)
  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. (Techniques for B.2.9)
  1. A tutorial on the accessible authoring process for the specific authoring tool must be provided.
     
B.3.4 Ensure that accessibility prompting, checking, repair functions and documentation are configurable. (Techniques for B.3.4)
  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
     

"Relative Priority" Checkpoints

CheckpointSuccess CriteriaLevelYesNoN/A
A.0.1 Ensure that browser-accessed functionality conforms to WCAG. (Techniques for A.0.1)
  1. Any component of an authoring tool that is accessed by the author within a Web browser must conform to WCAG.
       
B.1.3 Ensure that when the tool automatically generates content it conforms to WCAG. (Techniques for B.1.3)
  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. (Techniques for B.1.4)
  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.
       
B.2.1 Prompt and assist the author to create content that conforms to WCAG. (Techniques for B.2.1)
  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. (Techniques for B.2.2)
  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. (Techniques for B.2.3)
  1. For each potential accessibility problem identified by the checking function (required in checkpoint B.2.2) provide at least one of the following: