Appendix A. Checklist

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

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

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.

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. Instructions provided to the author by the authoring tool must meet (if followed) meet one of the following:
   • (a) lead to the creation of Web content that conforms to WCAG, or
   • (b) inform the author that following the instructions would lead to Web content accessibility problems.

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.

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

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 success criteria 1 of this checkpoint.

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.

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.

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

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.

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 both of the following functionalities:
   • (a) move content focus to the next enabled control in user interface (e.g. using "tab" key), and
   • (b) 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 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.

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.

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.

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.

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 tool user 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).

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.

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.

1. 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 the target format such that the accessibility information is still available to end users of the rendered content, or
   • (c) be removed only after the author has been notified and the content has been preserved in its original format.

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) alternatives previously entered by authors for the non-text object (e.g. by the same author, or another author on a collaborative system),
   • (b) alternatives stored with the non-text object in an image database, or
   • (c) null alternatives for non-text objects that are only used only for visual formatting
   (Text alternatives from other sources, such as generated from the non-text object file name, are not acceptable)
2. The tool must allow the author to accept, modify, or reject equivalent alternatives.

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):
   • (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. For any structured element set, the author must always be able to select content and perform editing functions (e.g. cut, copy, paste, presentation) on any element along with any content, including sub-elements.

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.

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.

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.

1. If a preview feature is provided, then a method of returning from the preview must be provided that meets all of the checkpoints in Part A.
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 control), or
   • (b) the preview meets all of the checkpoints in Part A.

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.

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.

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

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

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.

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.

1. All accessible content support features must match or exceed the prominence of any corresponding features related to other classes of Web content problems (e.g. markup validity, program code syntax, spelling and grammar).

1. All accessible content support features must be documented in the help system.

1. There must be an option to set (and later modify) key-plus-modifier-key (or single-key) access for each selectable action.
2. There must be at least one authoring tool user interface area containing selectable actions available by a single selection (e.g. toolbar), where both of the following are true:
   • (a) the order of the actions is customizable, and
   • (b) the available actions are customizable (from the set of all selectable actions).

1. The authoring tool must 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.

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.

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

1. All accessible content support features must be turned on by default.
2. If the author does turn off an accessible content support feature, then the authoring tool must inform the author that this may increase the risk of content accessibility problems.
3. If the author does turn off an accessible content support feature, then the author must always have the option to turn the feature back on again.