W3C

Authoring Tool Accessibility Guidelines 2.0

Editor's Draft 9 March 2007

This version:
http://www.w3.org/TR/2006/WD-ATAG20-20061207/
Latest version:
http://www.w3.org/TR/ATAG20/
Previous version:
http://www.w3.org/TR/2006/WD-ATAG20-20061207/
Editors:
Jutta Treviranus, Adaptive Technology Resource Centre , University of Toronto
Jan Richards, Adaptive Technology Resource Centre, University of Toronto
Previous Editors:
Matt May (until June 2005 while at W3C)

Abstract

This specification provides guidelines for designing Web content authoring tools that are more accessible for people with disabilities. An authoring tool that conforms to these guidelines will promote accessibility by providing an accessible user interface to authors with disabilities as well as enabling, supporting, and promoting the production of accessible Web content by all authors.

"Authoring Tool Accessibility Guidelines 2.0" (ATAG 2.0) is part of a series of accessibility guidelines published by the W3C Web Accessibility Initiative (WAI).

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 is a Working Draft intended to gather comments on a stabilized version of the Authoring Tool Accessibility Guidelines 2.0 (ATAG 2.0) prior to proceeding to a second Last Call Working Draft. The Working Draft includes an Appendix B: Comparison of ATAG 1.0 checkpoints to ATAG 2.0.

The AUWG encourages feedback about this Working Draft. Please send your comments by 11 January 2007 to w3c-wai-au@w3.org. The archives for this list are publicly available.

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.

The Working Group (AUWG) intends to publish ATAG 2.0 as a W3C Recommendation. Until that time Authoring Tool Accessibility Guidelines 1.0 (ATAG 1.0) [ATAG10] is the stable, referenceable version. This Working Draft does not supersede ATAG 1.0.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

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

Table of Contents


Introduction

This section is informative.

You are reading the Authoring Tool Accessibility Guidelines (ATAG) version 2.0. This document includes recommendations for assisting authoring tool developers to make their tools (and the Web content that the tools generate) more accessible to all people, especially people with disabilities, who may potentially be either authors or end users. These guidelines have been written to address the requirements of many different audiences, including, but not limited to:

An attempt has been made to make this document as readable and usable as possible for that diverse audience, while still retaining the accuracy and clarity needed in a technical specification.

ATAG 2.0 is part of a series of accessibility guidelines published by the Web Accessibility Initiative (WAI). The relationship between these documents is explained in "Essential Components of Web Accessibility" [COMPONENTS].

This ATAG 2.0 document itself consists of:

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.

The following categories are an informative illustration of the range of tools covered by ATAG 2.0. The categories are used primarily in the Techniques document [ATAG20-TECHS] to mark examples that may be of interest to developers of particular types of tools. Note: Many authoring tools include authoring functions from more than one category (e.g., an HTML editor with both code-level and WYSIWYG editing views):

Role of authoring tools in Web accessibility

The guiding principle of ATAG 2.0 is that:

Everyone should have the ability to create and access Web content.

Authoring tools play a crucial role in achieving this principle because the accessibility of the tool's authoring tool user interface determines who can access the tool as a Web content author (see Part A of the guidelines) and the accessibility of the resulting Web content determines who can be an end user of that Web content (see Part B of the guidelines).

The approach taken to the production of accessible content in these guidelines is one of enabling, supporting, and guiding the author. In general, the Working Group does not believe that enforcing particular author behavior through overly restrictive mechanisms is a workable solution.

As an introduction to accessible authoring tool design, consider that the authors and end users of Web content may be using the tool and its output in contexts that are very different from that which may be regarded as typical. For example, authors and end users may

For more information, see "How People with Disabilities Use the Web" [PWD-USE-WEB]. In addition, following the guidelines provides benefits for authors and end users beyond those listed in these various disability-related contexts. For example, a person may have average hearing, but still require captions for audio information due to a noisy workplace. Similarly, a person working in an eyes-busy environment may require an audio alternative to information they cannot view.

Also consider that authors may not be familiar with the specific needs of people with disabilities and will require support from the authoring tool to fill the knowledge gap.

Relationship to the Web Content Accessibility Guidelines (WCAG)

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]. Note that the two versions have somewhat different Conformance Models.

The Web Content Accessibility Guidelines (WCAG) is the W3C-WAI Recommendation that defines requirements for making Web content accessible to a wide range of people with disabilities. ATAG 2.0 includes a Web Content Accessibility "Benchmark" section that refers to WCAG as the guideline for judging the accessibility of Web content (see the term "Accessible Web Content") and any Web-based authoring tool user interface functionality (see the term "Accessible Authoring Tool User Interface").

Note that the references to WCAG are made 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. Consider the following when deciding which WCAG version to use:


Conformance

This section is normative.

Conformance means that the authoring tool satisfies the checkpoint success criteria defined in the guidelines section. This section outlines the conformance scheme used throughout this document.

Each checkpoints is assigned one of three (3) priority levels.

(If a checkpoint success criterion is not applicable to an authoring tool, then that success criterion is treated as met for conformance purposes.)

Web Content Accessibility "Benchmark"

The purpose of the Web Content Accessibility "Benchmark" is to precisely specify the evaluator's interpretation of what "accessible Web content" means with respect to the particular content type(s) that are produced by the authoring tool or are used to implement Web-based user interface functionality of the authoring tool (if applicable). This precise interpretation helps the evaluator to judge the completeness and consistency of accessibility-related authoring tool functions that must interoperate, such as accessibility prompting, evaluation, and repair functions. In addition, because the Benchmark must be made public, it allows claims to be more fully checked for accuracy.

What does a Web Content Accessibility Benchmark include?

A Benchmark document must be publicly published on the Web (the URI will appear in the conformance claim) and must include:

Note on other Accessibility Standards: ATAG 2.0 addresses how authoring tools can be designed to encourage authors to create accessible content. While the Working Group highly recommends the W3C-WAI Web Content Accessibility Guidelines due to the quality of the document and the process under which it was developed, other Recommendations, Standards, and Regulations with the same goal exist in jurisdictions and organizations around the world. @@JR: ???@@

Is a Web Content Accessibility Benchmark normative?

Yes. Although it may be based on informative documents, such as WCAG Techniques, ATAG 2.0 considers that a Benchmark becomes normative for a particular conformance claim when that claim includes a reference to the URI of that Benchmark.

Who can create a Web Content Accessibility Benchmark?

A Benchmark can be created by any any person, company or other organization. However, in the interest of being able to directly compare the evaluations of authoring tools that produce the same content types, the Working Group suggests checking to see if a Benchmark document has already been published, before creating a new one.

What resources are available to help create a Web Content Accessibility Benchmark?

The Working Group suggests the following:

Conformance Levels

Authoring tools may claim full conformance to ATAG 2.0 at one of three conformance levels. The level achieved depends on the priority level of the checkpoints for which the authoring tool has satisfied the success criteria. The full conformance levels are:

  1. ATAG 2.0 Conformance at Level "A"
    The authoring tool has satisfied the success criteria for all of the Priority 1 checkpoints.
  2. ATAG 2.0 Conformance at Level "Double-A" means that t
    The authoring tool has satisfied the success criteria for all of the Priority 1 and Priority 2 checkpoints.
  3. ATAG 2.0 Conformance at Level "Triple-A" means that t
    The authoring tool has satisfied the success criteria for all of the checkpoints.

In addition, a Partial Conformance claim option is available in cases where an authoring tool has satisfied the success criteria in one of the two Parts of the document (i.e. "Part A: Make the authoring tool user interface accessible" and "Part B: Support the production of accessible content") to a higher level than in the other. The partial conformance levels are:

  1. ATAG 2.0 Partial Conformance Level ("A"|"Double-A"|"Triple-A"): Authoring Tool User Interface
    The authoring tool has satisfied all of the relevant success criteria for the checkpoints in Part A.
  2. ATAG 2.0 Partial Conformance Level ("A"|"Double-A"|"Triple-A"): Content Production"
    The authoring tool has satisfied all of the relevant success criteria for the checkpoints in Part B.

Note: The Working Group remains committed to the guiding principle that: Everyone should have the ability to create and access Web content. Therefore, it is recommended that Partial Conformance be claimed as a step towards full conformance.

Conformance Claims

A conformance claim is an assertion by a claimant that an authoring tool has satisfied the requirements of a chosen ATAG 2.0 conformance profile.

Conditions on Conformance Claims

Required Components of an ATAG 2.0 Conformance Claim

  1. The date of the claim.
  2. The guidelines title/version: "Authoring Tool Accessibility Guidelines 2.0"
  3. The name of the authoring tool and sufficient additional information 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").
    • If the authoring tool is a collection of software component (e.g., a markup editor, an image editor, and a validation tool), then information must be provided separately for each component, although the conformance claim will treat them as a whole.
  4. The conformance profile, which must include the following:
    • (a) The ATAG 2.0 conformance level that has been satisfied (choose one of: "A", "Double-A", "Triple-A").
    • (b) A list of the content type(s) produced by the authoring tool that are covered by the claim.
      • The list must include at least one content typefor the conformance claim to be valid.
      • When content types are typically produced together (e.g., HTML and JavaScript), they can be listed separately or together in the list.
      • Each of the content types in this list must include the URI of a Web content accessibility benchmark for that content type.
    • (c) A list of any other content type(s) produced by the authoring tool that are not covered by the claim.
    • (d) The platform(s) upon which all or part (e.g., help system) of the authoring tool was evaluated
      • For user agent platform(s), provide:
        • The name and version information of the user agent(s).
        • The version and URI of the Web Content Accessibility Guidelines document used to evaluate the accessibility of the Web-based functionality.
      • For platforms that are not user agents, provide:
        • The name and version information of the platform(s) (e.g., operating system, Java virtual machine, etc.).
        • The name and version of the accessibility platform architecture(s) employed.
  5. A description of how the normative ATAG 2.0 success criteria were met for each of the checkpoints that are required for the conformance level specified by the conformance profile. In some cases, this includes describing how the Web content accessibility benchmark techniques were implemented.

Optional Components of an ATAG 2.0 Conformance Claim

  1. 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: Code-level authoring functions, WYSIWYG authoring functions, object oriented authoring functions, or indirect authoring functions.
  2. Any additional information about the tool, including progress towards the next conformance level.

"Progress Towards Conformance" Statement

Developers of authoring tools that do not yet conform fully to a particular ATAG 2.0 conformance level are encouraged to publish a statement on progress towards conformance. This statement would be the same as a conformance claim except that this statement would specify an ATAG 2.0 conformance level that is being progressed towards, rather than one already satisfied, and report the progress on success criteria not yet met. The author of a "Progress Towards Conformance" Statement is solely responsible for the accuracy of their statement. Developers are encouraged to provide expected timelines for meeting outstanding success criteria within the Statement.


ATAG 2.0 Guidelines

This section is normative.

How the guidelines are organized

The guidelines are divided into two parts, each reflecting a key aspect of accessible authoring tools. Part A includes guidelines and associated checkpoints related to ensuring accessibility of the authoring tool user interface. Part B contains guidelines and checkpoints related to ensuring support for creation of accessible Web content by the tool. The guidelines in both parts include the following:

Each checkpoint listed under a guideline is intended to be specific enough to be verifiable, while still allowing developers the freedom to meet the checkpoint in a way that is suitable for their own authoring tools. Each checkpoint definition includes the following parts. Some parts are normative (i.e., relate to conformance), while others are informative only:

PART A: Make the authoring tool user interface accessible

The checkpoints in Part A are intended to increase the accessibility of the authoring experience for authors with disabilities. For this reason, the requirements are narrowly focused on the accessibility of the user interface that authors uses to operate the tool. The accessibility of the Web content produced is addressed in Part B.

Note for tools with previews: The requirement in this section apply to all parts of the authoring tool user interface except for the content view of any built-in preview features (see Checkpoint A.2.9 for requirements on previews). In general, the configuration of the preview mode is not defined by the configuration of the editing views.

GUIDELINE A.4: Authoring tool must facilitate access by assistive technologies

Assistive technologies (e.g., screen readers, screen magnifiers, on-screen keyboards, voice recognition systems) can only provide augmented display and control to their users if the relevant information is made available by authoring tools using common protocols.

A.4.1 For the authoring tool user interface, ensure that Web-based functionality is accessible conforms to WCAG. [Priority 1 to ensure a minimum level of Web content accessibility, Priority 2 to ensure an enhanced level of Web content accessibility, Priority 3 to ensure additional Web content accessibility enhancements]

Rationale: In addition to generally improving the accessiblity of the authoring tool user interface, implementing user interfaces using accessible Web content facilitates communication with assistive technologies via user agents. 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 (Web-based functionality)):

  1. All Web-based authoring tool user interface functionality must conform to WCAG.
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, on-screen keyboards, voice recognition systems) rely on the authoring tool to provide data and control via prescribed communication protocols.

Techniques: Implementation Techniques for Checkpoint A.4.1

Success Criteria (non-Web-based functionality):

  1. An accessibility platform architecture relevant to the development platform must be implemeted.
  2. Any deviation from the proper use the implemented accessibility platform architecture(s) (i.e., lack of use, incomplete use, inappropriate use) as defined by the documentation for the architecture must be publicly documented.
  3. If there is any authoring tool user interface functionality that is not supported by the implemented accessibility platform architecture(s), then one of the following must be true:
    • (a) a descrription of the inaccessible functionality in the conformance claim and a separate accessible equivalent for that functionality that is supported by the implemented accessibility platform architecture(s) are provided.
    • (b) an alternative interoperability mechanism (e.g., an extension to the implemented accessibility platform architecture(s)) that enables the functionality to be available to an assistive technology implementing the mechanism is provided and publicly documented.
  4. 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.
  1. 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
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 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, display 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 (for the content display):

  1. All editing views must include an option to display any text alternatives provided for non-text objects in the content being edited. It is permissable for the authoring tool to automatically change editing views to display the text alternatives (e.g., change from a WYSIWYG editing view to a code-level editing view).

Success Criteria (for the user interface "chrome"):

  1. All non-text objects in the user interface "chrome" that are used to convey information (e.g., toolbar icon, graphical depiction of a tag, sound effect) must have text alternatives (e.g., alternative text label, long text description).
  2. All multimedia in the user interface "chrome" that is used to convey information (e.g., tutorial video) must have accessible alternatives to multimedia.

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, display synchronized alternatives for multimedia. [Priority 2]@@JR: it would nice if this were P1 for captions@@

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 (for the content display):

  1. All editing views must include an option to display any synchronized alternatives for multimedia in the content being edited. It is permissable for the authoring tool to automatically change editing views to display the synchronized alternatives (e.g., change from a code-level editing view to a WYSIWYG editing view).

Success Criteria (for the user interface "chrome"):

  1. All multimedia in the user interface "chrome" that is used to convey information (e.g., tutorial video) must have synchronized alternatives (e.g., captions, audio descriptions).

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 that may differ from the presentation the author intends to define for the published content (e.g., providing a high contrast setting to edit content that is not intended to be high contrast).

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 (for the content display):

  1. Authors must be able to configure the visual display settings and audio display settings (as applicable) of the content display by one of the following methods:
    • (a) an option to inherit the platform settings, or
    • (b) content display settings within the authoring tool.
  2. If the content display settings are implemented within the authoring tool (option (b) above), then the authoring tool must provide at least the same configurable properties with at least the same configuration ranges as the platform provides.
  3. For editing views that usually have their display characteristics set by rendering the content being edited (i.e., WYSWYG editing views), the content display settings must override these characteristics without affecting the content (e.g., markup, stylesheets, etc.) being edited.

Success Criteria (for the user interface "chrome"):

  1. Authors must be able to configure the visual display settings and audio display settings (as applicable) of the user interface "chrome" by one of the following methods:
    • (a) an option to inherit the platform settings, or
    • (b) user interface "chrome" display settings within the authoring tool.
  2. If the user interface "chrome" display settings are implemented within the authoring tool (option (b) above), then the authoring tool must provide at least the same configurable properties with at least the same configuration ranges as the platform provides.

 

  1. If the visual display (e.g., fonts, sizes, colors, spacing, positioning, contrast) 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, voice speed, voice emphasis) 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 authors explicitly set different visual or audio display preferences.
  4. Any visual or audio display settings that are set by the authoring tool 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. Authors 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 (general):

  1. Any information that is conveyed by color (e.g., a red underline to indicate spelling errors and a green underline to indicate grammar errors) must meet at least one of the following:
    • (a) be 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 utility that provides the same functionality as a colored underline)

Success Criteria (for non-Web-based content display):

  1. For rendered content displays (e.g., WYSIWYG editing view), all of the following characteristics of the presentation (e.g., color, emphasis, positioning) must be available via an accessibility platform architecture (e.g., if a word appears in red in a WYSIWYG editing view because it is styled that way, only its color needs to be made available): available programmatically.
    • (a) color,
    • (b) emphasis, and
    • (c) position
    • @@JR: (d)???@@
  2. For authoring tool-controlled presentation added to the content display by the authoring tool in editing views, the functional reason for semantic description of the presentation must be available via an accessibility platform architecture available programmatically. (e.g., if a word appears in red in a code-level view because it is misspelled, then that fact that it is a misspelled word must be made available).

Success Criteria (for non-Web-based user interface "chrome"):

  1. For the presentation of controls within the user interface "chrome" (e.g., dialog boxes, menus, button bars, user interface controls in the editing view), the functional reason for semantic description of the presentation (e.g., "paragraph tag" instead of "blue-colored <p>") must be available via an accessibility platform architecture available programmatically.

    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 (general):

  1. Authors 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 user interface "chrome", 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. Authors 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. If the author has the option to modify the keyboard operability settings, any modifications must be saved between authoring sessions.
  4. The current keyboard settings must be available to authors at all times (e.g., central location such as a list, distributed location such as associating shortcuts with menu items).
  5. The authoring tool must not interfere with keyboard accessibility features of the platform (e.g. StickyKeys, SlowKeys, browser link navigation)

Success Criteria (for the content display):

  1. Authors must have the option of single-key navigation forward and backward within the content display (e.g., using "arrow" keys).

Success Criteria (for the user interface "chrome"):

  1. Authors must have the option of single-key navigation of enabled controls in the user interface "chrome" (e.g., using "tab" key).
  2. Authors must have the option of key-plus-modifier-key (or single-key) navigation for both of the following:
    • (a) moving the focus to the previous enabled control (e.g., using "shift-tab" key combination), and
    • (b) navigating between panels or windows (if any) (e.g., using "ctrl-tab" key combination).
  3. If any of the following functionalities is implemented by the authoring tool, the author must have the option to enable key-plus-modifier-key (or single-key) access to them:
    • (a) open help system,
    • (b) open new content,
    • (c) open existing content,
    • (d) save content,
    • (e) close content,
    • (f) cut/copy/paste,
    • (g) undo/redo,
    • (h) open find/replace function, and
    • (i) navigate to the start and end of the content being edited.

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 (for the user interface "chrome"):

  1. Authors must have the option to modify key-plus-modifier-key (or single-key) access for each selectable item.
  2. At least one control container (e.g., toolbar, palette) in which selectable items can be activated by a single action must be provided, where both of the following must be true:
    • (a) authors can select which items are included in the container, from the set of all selectable items, and
    • (b) authors can modify the order that the items appear in the container.
A.2.3 For the authoring tool user interface, maximize author control of 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 (general):

  1. If the authoring tool has no control over a time limit (e.g,. loss of an external connection), but does have advance notice, then the authoring tool must notify the author when the advance notice is received, up to one minute before the time limit expires.
  2. If the authoring tool has some control over a time limit (e.g., the authoring tool is mediating collaborative authoring of the same content), then at least one of the following must be true:
    • (a) Authors are allowed to adjust the time limit over a wide range that is at least ten times the length of the default setting and are warned at least twenty seconds before time expires, or
    • (b) Authors are warned before time expires and are given at least twenty seconds to extend the time limit with a simple action (e.g., "hit any key"), and are allowed to extend the time limit at least ten times.
  3. If the authoring tool has full control over a time limit (e.g. logging an author off after a period of inactivity, presenting options as a slide show, etc.), then at least one of the following must be true:
    • (a) Authors are allowed to deactivate the time limit,
    • (b) Authors are allowed to adjust the time limit over a wide range that is at least ten times the length of the default setting and are warned at least twenty seconds before time expires, or
    • (c) Authors are warned before time expires and are given at least twenty seconds to extend the time limit with a simple action (e.g., "hit any key"), and are allowed to extend the time limit indefinitely.

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, enable 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 (for the content display):

  1. If an editing view is capable of rendering content that might violate the general flash or red flash thresholds (e.g., within a WYSIWYG editing view), then the authoring tool must include both of the following:
    • (a) a simple escape action (e.g. "Escape" key) that allows the author to do one of the following:
    • (b) an option to turn on a reminder to authors of the simple escape action (see (a) above), whenever any content is opened, in case flashing does appear.

Success Criteria (for the user interface "chrome"):

  1. The user interface "chrome" editing interface must not include visual elements that violate the general flash or red flash thresholds.

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 provide navigation and editing via content structure. [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 (for the content display):

  1. If an editing view displays editing content that is a structured element set, authors must always be able with a simple action 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 an editing view displaysIf editing content that is a structured element set, authors must be able with a simple action 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, provide text search of 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 authors 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 (for the content display):

  1. A text search function must be provided that has access to any textual information (including text alternatives for non-text objects, metadata, markup) that is editable in any editing view. It is permissable for the authoring tool to automatically change editing views to display the search results (e.g., change from a code-level editing view to a WYSIWYG editing view). Web-based authoring tools may at least partially rely on the "find" function of the user agent that is recorded in the conformance profile.

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 (for the content display):

  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. If the most recent author action is a reversible action, an undo function must be provided that is able to reverse up to 5 consecutive reversible actions. Web-based authoring tools may rely on the "undo" function of the user agent to undo certain client-side author actions.
  3. Authors must be able to immediately reverse the most recent undos (i.e., a "redo" function). @@JR: if we want redo, let's put it in a new checkpoint@@

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 authors to have multiple sets of keyboard operability and display preferences settings. [Priority 3?]

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 (general):

  1. Authors 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.2.9 For the authoring tool user interface, ensure previews are not less accessible than existing user agents. [Priority 1]@@JR: tool breaks if can't return@@

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 (general):

  1. If a preview feature is provided, then a mechanism for 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., opening the content in a third-party browser or browser component), or
    • (b) the preview meets all of the Priority 1 checkpoints in Part A of these guidelines, or
    • (c) the preview conforms to UAAG 1.0 level "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 (for the content display):

  1. Focus and selection conventions for the current platform (specified in the conformance profile) with respect to content display must be followed.

Success Criteria (for the user interface "chrome"):

  1. Focus and selection conventions for the current platform (specified in the conformance profile) with respect to user interface "chrome" 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 (for the user interface "chrome"):

  1. User interface "chrome" controls that are identified by the same text label or icon must always perform the same function (e.g. if a clipboard icon is used to label a "paste" function, the same or similar icon should not be used to label a "note taking" function).
  2. When the same function (e.g., saving, running a checker or canceling an action) is available in multiple places within the user interface "chrome" (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 (for the user interface "chrome"):

  1. At least one version of the documentation must either:
  2. All features of the user interface "chrome" that are specifically required to meet Part A of these gudielines (e.g. keyboard shortcuts, text search, etc.) must be documented.

PART B: Support the production of accessible content

The checkpoints in Part B are intended to increase the accessibility of the Web content produced by any author to end users with disabilities. While the requirements in this part do not deal with the accessibility of the authoring tool user interface, it should be noted that any of the features (e.g., checker, tutorial) added to meet Part B must also meet the user interface accessibility requirements of Part A.

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 is accessible 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. If the authoring tool chooses a default content type for authors, then that content type must have a Web content accessibility benchmark.
  2. If authors are allowed to choose the content type, then for at least one content type both of the following must be true:
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:
B.1.3 Ensure that authors are 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. An option to notify authors before an automatic process permanently removes content must be provided.
B.1.4 Ensure that automatically generated content is accessible conforms to WCAG. [Priority 1 to ensure a minimum level of Web content accessibility, Priority 2 to ensure an enhanced level of Web content accessibility, Priority 3 to ensure additional Web content accessibility enhancements]

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 authors during the automatic generation process, Checkpoint B.2.1 applies.

Techniques: Implementation Techniques for Checkpoint B.1.4

Success Criteria:

  1. Any content that is generated by the authoring tool must meet the requirements in the Web content accessibility benchmark, unless this results directly from author input to the process (e.g., author adds inaccessible markup directly to a code-level editing view, author chooses poor color combinations, etc.)
    All content that is automatically generated by the authoring tool (i.e., not authored "by hand") must conform to WCAG.
  2. @@JR: should we say something here about complete vs. incomplete content?@@
B.1.5 Ensure that all pre-authored content for the authoring tool is accessible conforms to WCAG. [Priority 1 to ensure a minimum level of Web content accessibility, Priority 2 to ensure an enhanced level of Web content accessibility, Priority 3 to ensure additional Web content accessibility enhancements]

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 authors 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, 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 meet the requirements in the Web content accessibility benchmark when used by the author. @@JR: Maybe this should be changed to make it a bit more clear who needs to be offering the discount@@

GUIDELINE B.2: Support authors 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 authors 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 authors to create accessible content that conforms to WCAG. [Priority 1 to prompt for a minimum level of Web content accessibility, Priority 2 to prompt for an enhanced level of Web content accessibility, Priority 3 to prompt for additional Web content accessibility enhancements]

Rationale: The authoring tool should help to prevent authors 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. An option to notify authors when content is added or updated that requires accessibility information from authors (e.g., via a dialog box) to meet the requirements in the Web content accessibility benchmark must be provided.
  2. If an authoring tool presents authors with content type choices or authoring options that will always lead to the creation of content that does not meet the requirements in the Web content accessibility benchmark (e.g., a strobe effect that will violate the general flash or red flash threshold), then a warning must be displayed so that authors are aware of the consequences prior to making the choice. @@JR: moved from B.3.1@@
  3. Any content authoring instructions provided to the author by the authoring tool must meet one of the following:
    • (a) be accessible, such that content created according to the instructions would meet the requirements in the Web content accessibility benchmark, or
    • (b) be inaccessible, but include a prominent explanation that Web content accessibility problems will result from following the instructions.
B.2.2 Assist authors in checking for and inform the author of accessibility problems. [Priority 1 to check for a minimum level of Web content accessibility, Priority 2 to check for an enhanced level of Web content accessibility, Priority 3 to check for additional Web content accessibility enhancements]

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 Web content accessibility benchmark. A blanket question such as "does the page meet all of the requirements?" is not acceptable .
  2. For checks that are associated with a type of element (e.g., img), each element instance must be individually identified as a potential accessibility problem.
  3. 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 applicable elements must be identified as a potential accessibility problem, up to the entire content if applicable.
  4. For checks that required author judgement to determine if a potential accessibility problem is correctly identified, the message to authors must be tailored to that potential accessibility problem (i.e., to that requirement in the context of that element or span of elements).
  5. Checking must be presented as an option to authors 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. [Priority 1 to repair to a minimum level of Web content accessibility, Priority 2 to repair to an enhanced level of Web content accessibility, Priority 3 to repair additional Web content accessibility enhancements]

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 that might be identified during checking (required in Checkpoint B.2.2), at least one of the following must be provided:
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 text alternatives for non-text objects are offered to authors, then the source of the alternatives for each object must be at least one of the following: (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. Authors must have the opportunity 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 option of storing for future re-use both of the following author-added equivalent alternatives for non-text objects (if applicable) must be provided:
B.2.6 Provide authors with a summary of accessibility status. [Priority 3] @@P2 suggested by reviewers@@

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. An option to view a complete list of all known accessibility problems detected during checking must be provided prior to completion of authoring.
B.2.7 Provide authors 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: Implementation Techniques for Checkpoint B.2.7

Success Criteria:

  1. A tutorial on the accessible authoring process that is specific to the 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 features that support accessible authoring that have been added to meet the other requirements in this document.

Note: In addition to the normative requirements of this guideline, implementers should also consider the integration of features that support accessible authoring with the "look-and-feel" of other features of the authoring tool. This type of integration has the potential to:

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. If authors are presented with two or more authoring options for a given task (e.g., styling page headings) and they differ in the degree to which they meet the requirements in the Web content accessibility benchmark, the option(s) that are more accessible (e.g., using styled header markup) must have prominence that matches or exceeds that of the option(s) that do not (e.g., using presentation rather than header markup).
  2. Any choices of content types or authoring option presented to the author (e.g., in menus, toolbars or dialogs) that will lead to the creation of content that does not conform to WCAG must be marked or labeled so that the author is aware of the consequences prior to making the choice. @@JR: Moved to B.2.1@@
B.3.2. 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 authors 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.2

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 successfully complete the interactive feature.
  2. For read-only Instruction text (e.g., tutorials, reference manuals, design guides) that includes a sequence of steps for authors to follow, the relevant accessibility authoring practices must appear in the step sequence before the first opportunity to successfully complete the sequence.
B.3.3 Ensure that features of the authoring tool that support the production of accessible content are prominent in the user interface. [Priority 2]

Rationale: If the features that support accessible authoring are difficult to find and activate, they are less likely to be used.

Techniques: Implementation Techniques for Checkpoint B.3.3

Success Criteria:

  1. Accessible content support features must have prominence that matches or exceeds that of any corresponding features related to other classes of Web content problems (e.g., markup validity, program code syntax, spelling and grammar).
B.3.4 Ensure that features of the authoring tool that support the production of accessible content are configurable. [Priority 3]@@JR: Reviewer says higher Priority needed@@

Rationale: The accessible content support features will be more adaptable to the work habits of authors if they can be turned on and off easily as authors need them.

Techniques: Implementation Techniques for Checkpoint B.3.4

Success Criteria:

  1. All Aaccessible content support features must be turned on by default.
  2. If authors turn off an accessible content support feature, then the authoring tool must inform them that this may increase the risk of content accessibility problems.
  3. If authors turn off an accessible content support feature, then they must always have the option to turn the feature back on again.
  4. Settings for the accessible content support feature settings must be saved between authoring sessions.
B.3.5 Document features of the authoring tool that support the production of accessible content. [Priority 1]

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

Techniques: Implementation Techniques for Checkpoint B.3.5

Success Criteria:

  1. All Accessible content support features must be documented in the help system.
B.3.6 Ensure that any authoring practices demonstrated in repair instructions and documentation are accessible. [Priority 3]

Rationale: If accessible authoring is integrated into instructions and guidance offered by the tool (e.g., documentation, help, tutorials, examples, and workflow processes), authors are more likely to follow accessible authoring techniques if they are demonstrated as 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.3.6

Success Criteria:

  1. Any examples of markup and screenshots of the authoring tool user interface that appear in the documentation and repair instructions must demonstrate accessible Web content, with the exception of examples specifically intended to show inaccessible practices, which must be avoided.

 


Appendices

Appendix A: Glossary

This glossary is normative. Some definitions may differ from those in other WAI documents. The definitions here serve the goals of this Recommendation.

accessibility platform architecture
Programmatic interface that is specifically engineered to communicate with assistive technologies. Examples include MSAA and IAccessible2 for Windows applications, Gnome Accessibility Toolkit API for Gnome, Java Access for Java applications.@@JR: def'n may need work@@
accessibility problem, authoring tool user interface
An authoring tool user interface accessibility problem is an aspect of an authoring tool user interface that fails to meet one of the checkpoint success criteria in Part A. The severity of a given problem is reflected in the priority of the checkpoint.
accessibility problem, Web content
A Web content accessibility problem is an aspect of Web content that fails to meet some accessibility requirement. In ATAG 2.0, The severity of a given problem is relative and is determined by the Web content accessibility benchmark.
accessible Web content
Web content (e.g., output of an authoring tool) that is free of accessibility problems. Usually this term would be used to refer to a particular level of accessibility (e.g., "meets a minimum level of Web content accessibility").
accessible authoring tool user interface
For Web-based functionality, this is an authoring tool user interface that conforms to Checkpoint A.0.1. For non-Web-based functionality this is an authoring tool user interface that meets the success criteria in Part A. The severity of a given problem is reflected in the priority of the checkpoints.
accessibility information
Accessibility information is the information that is necessary and sufficient for undertaking an accessible authoring practice. For a particular content type, this information may include, but is not limited to, equivalent alternatives.
accessible authoring practice
An accessible authoring practice is any authoring activity (e.g., inserting an element, setting an attribute value), by either authors or the authoring tool, that corrects an existing Web content accessibility problem or does not cause a Web content accessibility problem to be introduced.
accessible content support features
All features of the tool that play a role in satisfying the success criteria for checkpoints B.2.1, B.2.2, B.2.3, B.2.5, B.2.6 and B.2.7.
alert
An alert makes authors aware of events or actions that require a response. The author response is not necessarily required immediately. The events or actions that trigger an alert may have serious consequences if ignored.
audio description
Audio description (also called "Described Video") is an equivalent alternative that provides auditory information about actions, body language, graphics, and scene changes in a video. Audio descriptions are commonly used by people who are blind or have low vision, although they may also be used as a low-bandwidth equivalent on the Web. An audio description is either a pre-recorded human voice or a synthesized voice (recorded or automatically generated in real time). The audio description must be synchronized with the auditory track of a video presentation, usually with descriptions occurring during natural pauses in the auditory track.
author
An author is the term used for the user of an authoring tool. This may include content authors, designers, programmers, publishers, testers, etc.
authored "by hand"
Authoring by hand is a situation in which the author specifies Web content at the level to be interpreted by the user agent (e.g., typing into a text editor, choosing an element by name from a list).
authoring action
An authoring action is any action that the author takes using the authoring tool user interface with the intention of adding or modifying Web content (e.g., typing text, inserting an element, launching a wizard).
authoring tool user interface, non-Web-based
That part of an authoring tool user interface that runs directly on application execution environments such as Windows, MacOS, Java Virtual Machine etc.
authoring tool user interface, Web-based
That part of an authoring tool user interface that is implemented using a content type and rendered on a user agent. Since Web-Based tools may be implemented in many of the same content types they are used to edit, the distinction between content display and user interface "chrome" may be less clear cut than with non-Web-Based tools.
authoring tool user interface
The user interface of the authoring tool is the display and control mechanism that authors use to communicate with and operate the authoring tool software. Authoring tool user interfaces may be non-Web-Based or Web-based (e.g., on-line content management system) or a combination of both (e.g., a stand-alone markup editor with on-line help pages). Authoring tool user interfaces can usefully be considered in two parts:
  1. Content display: The tool's rendering of the content being edited in an editing view or previewed in a preview. Examples include:
    • marked-up content in a code-level editing view,
    • rendered text, images, tables, form controls, etc. in a WYSIWYG editing view,
    • vector graphics with editing "handles" in an object-oriented editing view,
    • text entries and setting values in an indirect editing view,
    • rendered text, images, tables, form controls, etc. in a preview.
  2. User Interface "Chrome": Any parts of the user interface that surround, underly or super-impose upon the content display:
    • controls that surround the content display include menus, button bars, palettes, help windows, cursors, dialog boxes, etc.,
    • controls that underly the content display (i.e. implementing non-rendered part of editing views) include text areas for a code-level editing view, text boxes in an indirect editing view, etc.,
    • controls that are super-imposed upon content displays include context menus on content, underlining problematic content, etc.
authoring tool
See "Definition of authoring tool".
available programmatically
Capable of providing information to other software (including assistive technologies) by following relevant accessibility platform architectures (e.g., MSAA, Java Access) or, if the available accessibility platform architectures are insufficient, following some other published interoperability mechanism (custom-created by the developer, if necessary).
captions
Captions are equivalent alternatives that consist of a text transcript of the auditory track of a movie (or other video presentation) and that is synchronized with the video and auditory tracks. Captions are generally rendered graphically. They benefit people who are deaf or hard-of-hearing, and anyone who cannot hear the audio (for example, someone in a noisy environment).
checking, accessibility
Accessibility checking (or "accessibility evaluation") is the process by which Web content is evaluated for Web content accessibility problems. ATAG 2.0 identifies three types of checking, based on increasing levels of automation: manual checking in which the authoring tool only provides instructions for authors to follow in order to identify problems; semi-automated checking in which the authoring tool is able to identify potential problems, but still requires human judgment by the author to make a final decision on whether an actual problem exists; and automated checking in which the authoring tool is able to check for problems automatically, with no human intervention required. An authoring tool may support any combination of checking types.
collection of software components
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.
completion of authoring
Completion of authoring is the point in time at which an authoring session ends and the author has no opportunity to make further changes. This may be when an author chooses to "save and exit", or "publish", or it may occur automatically at the end of a wizard, etc.
content type
A content type is a data format, programming or markup language that is intended to be retrieved and rendered by a user agent (e.g., HTML, CSS, SVG, PNG, PDF, Flash, JavaScript or combinations). The usage of the term is a subset of WCAG 2.0's [WCAG20] current usage of the term "Technology".
conversion
A conversion is a process that takes as input, content in one content type and produces as output, content in another content type (e.g., "Save as HTML" functions).
display settings, audio
The audio display settings are the characteristcs of audio output of music, sounds and speech and include volume, speech voices, voice speed, and voice emphasis.
display settings, visual
The visual display settings are the characteristcs of the on-screen rendering of text and graphics and include fonts, sizes, colors, spacing, positioning, and contrast.
document
A document is a structure of elements along with any associated content; the elements used are defined by a markup language.
documentation
Documentation refers to any information that supports the use of an authoring tool. This information may be found electronically or otherwise and includes help, manuals, installation instructions, sample workflows, and tutorials, etc.
editing view
An editing view is a view provided by the authoring tool that allows editing of content by the author (e.g., code-level editing view, WYSIWYG editing view).
element
Element is used in the same sense as in HTML [HTML4] and XML, an element refers to a pair of tags and their content, or an "empty" tag - one that requires no closing tag or content.
end user
An end user is a person who interacts with Web content once it has been authored. In some cases, the author and end user is the same person.
equivalent alternative
An equivalent alternative is content that is an acceptable substitute for other content that a person may not be able to access. An equivalent alternative fulfills essentially the same function or purpose as the original content upon presentation. Equivalent alternatives include text alternatives and synchronized alternatives. Text alternatives present a text version of the information conveyed in non-text objects such as graphics and audio clips. The text alternative is considered accessible because it can be rendered in many different ways (e.g., as synthesized speech for individuals who have visual or learning disabilities, as Braille for individuals who are blind, as graphical text for individuals who are deaf or do not have a disability). Accessible alternatives to multimedia present the same information as is conveyed in the multimedia via accessible text, navigation, forms, etc. Synchronized alternatives present essential audio information visually (i.e., captions) and essential video information in an auditory manner (i.e., audio descriptions).
freeform drawing
Drawing actions that use the mouse or stylus in a continuous fashion (e.g., a paintbrush feature). This does not cover moving or resizing object-based graphics (including moving or resizing an object that is a previously authored freeform graphic).
general flash or red flash
General flash threshold (Based on Wisconsin Computer Equivalence Algorithm for Flash Pattern Analysis (FPA)): A sequence of flashes or rapidly changing image sequences where all three of the following occur:
  1. the combined area of flashes occurring concurrently (but not necessarily contiguously) occupies more than one quarter of any 341 x 256 pixel rectangle anywhere on the displayed screen area when the content is viewed at 1024 x 768 pixels;
  2. there are more than three flashes within any one-second period; and
  3. the flashing is below 50 Hz.
(Note: For the general flash threshold, a flash is defined as a pair of opposing changes in brightness of 10% or more of full scale white brightness, where brightness is calculated as 0.2126 * ((R / FS) ^ 2.2) + 0.7152 * ((G / FS) ^ 2.2) + 0.0722 * ((B / FS) ^ 2.2). R, G, and B are the red, green, and blue RGB values of the color; FS is the maximum possible full scale RGB value for R, G, and B (255 for eight bit color channels); and the "^" character is the exponentiation operator. An "opposing change" is an increase followed by a decrease, or a decrease followed by an increase. This applies only when the brightness of the darker image is below .80 of full scale white brightness.
Red flash threshold (Note: Based on Wisconsin Computer Equivalence Algorithm for Flash Pattern Analysis (FPA)): A transition to or from a saturated red where both of the following occur:
  1. The combined area of flashes occurring concurrently occupies more than one quarter of any 341 x 256 pixel rectangle anywhere on the displayed screen area when the content is viewed at 1024 x 768 pixels.
  2. There are more than three flashes within any one-second period.
  3. The flashing is below 50 Hz.
inform
To inform is to make the author aware of an event or situation using methods such as alert, prompt, sound, flash. These methods may be unintrusive (i.e., presented without stopping the author's current activity) or intrusive (i.e., interrupting the author's current activity).
informative
Informative ("non-normative") parts of this document are never required for conformance.
keyboard interface
Interface used by software to obtain keystroke input.
Note 1: Allows users to provide keystroke input to programs even if the native technology does not contain a keyboard (e.g., a touch screen PDA has a keyboard interface built into its operating system as well as a connector for external keyboards. Applications on the PDA can use the interface to obtain keyboard input either from an external keyboard or from other applications that provide simulated keyboard output, such as handwriting interpreters or speech to text applications with "keyboard emulation" functionality).
Note 2: Operation of the application (or parts of the application) through a keyboard operated mouse emulator, such as MouseKeys, does not qualify as operation through a keyboard interface because operation of the program is through its pointing device interface - not through its keyboard interface.
markup
Markup is a set of tags from a markup language that specify the characteristics of a document. Markup can be presentational (i.e., markup that encodes information about the visual layout of the content), structural (i.e., markup that encodes information about the structural role of elements of the content) or semantic (i.e., markup that encodes information about the intended meaning of the content).
markup language
A markup language is a syntax and/or set of rules to manage markup (e.g., HTML [HTML4], SVG [SVG], or MathML [MATHML]).
multimedia
Audio or video synchronized with another type of media and/or with time-based interactive components.
non-text objects
Content objects that are not represented by text character(s) when rendered in a user agent (e.g., images, audio, video).
normative
Normative parts of this document are always required for conformance.
platform
A platform is the software environment within which the authoring tool operates. For functionality that is not Web-based, this will be an operating system (e.g., Windows, MacOS, Linux), virtual machine (e.g., JVM) or a higher level GUI toolkit (e.g., Eclipse). For Web-based functionality, the term applies more generically to user agents in general, although for purposes of evaluating conformance to ATAG 2.0, a specific user agent(s) will be listed in the conformance profile.
plug-in
A plug-in is a program that runs as part of the authoring tool (e.g., a third-party evaluation and repair tool). Users generally choose to include or exclude plug-ins from their authoring tool.
presentation
Presentation is the rendering of the content and structure in a form that can be perceived by the user.
preview
A preview is a non-editable view of the content that is intended to show how it will appear and behave in a user agent.
prominence
The prominence of a control in the authoring tool user interface is a heuristic measure of the degree to which authors are likely to notice a control when operating the authoring tool. In this document, prominence refers to visual as well as keyboard-driven navigation. Some of the factors that contribute to the prominence of a control include: control size (large controls or controls surrounded by extra white space may appear to be conferred higher importance), control order (items that occur early in the "localized" reading order (e.g., left to right and top to bottom; right to left and top to bottom) are conferred higher importance), control grouping (grouping controls together can change the reading order and the related judgments of importance), advanced options (when the properties are explicitly or implicitly grouped into sets of basic and advanced properties, the basic properties may gain apparent importance), and highlighting (controls may be distinguished from others using icons, color, styling).
prompt
In this document "prompt" refers to any authoring tool initiated request for a decision or piece of information. Well designed prompting will urge, suggest, and encourage the author.
repairing, accessibility
Accessibility repairing is the process by which Web content accessibility problems that have been identified within Web content are resolved. ATAG 2.0 identifies three types of repairing, based on increasing levels of automation: Manual repairing in which the authoring tool only provides instructions for authors to follow in order to make the necessary correction; Semi-Automated repairing, in which the authoring tool can provide some automated assistance to the author in performing corrections, but the author's input is still required before the repair can be completed; and Automated repairing, in which the authoring tool is able to make repairs automatically, with no author input or confirmation from the author. An authoring tool may support any combination of repairing types.
reversible actions
Reversible actions are those that, by their nature, can be completely undone so that the system returns to the state it was in before the action. Actions that are not reversible may incude certain save and delete actions as well as actions made in a collaborative environment that another author has begun to work with.
selectable items
Any items that an author may select from within the menus, toolbars, palettes, etc. (e.g., "open", "save", "emphasis", "check spelling")
structured element set
Content organized into lists, maps, hierarchies (e.g., tree views), graphs, etc.
transcript
A transcript is a non-synchronized text alternative for the sounds, narration, and dialogue in an audio clip or the auditory track of a multimedia presentation. For a video, the transcript can also include the description of actions, body language, graphics, and scene changes of the visual track.
transformation
A transformation is a process that takes as input, an object in one content type and produces as output, a different object in the same content type (e.g., a function that transforms tables into lists).
tutorial
A tutorial is a type of documentation which involves the sequential presentation of instructions for performing multi-part tasks.
user agent
A user agent is software that retrieves and renders Web content. This may include Web browsers, media players, plug-ins, and other programs including assistive technologies, that help in retrieving and rendering Web content.
view
A view is a rendering of Web content by an authoring tool. Authoring tool views are usually either editing views or previews.
Web content (or shortened to "content")
Web content is any material in a content type. If the content type is a markup language, then "content" covers the information both within the tags (i.e., the markup) and between them. In this document, "content" is primarily used in the context of the material that is authored and outputted by authoring tools.
Wisconsin Computer Equivalence Algorithm for Flash Pattern Analysis (FPA)
a method developed at the University of Wisconsin, working in conjunction with Dr. Graham Harding and Cambridge Research Associates, for applying the United Kingdom's "Ofcom Guidance Note on Flashing Images and Regular Patterns in Television (Re-issued as Ofcom Notes 25 July 2005)" to content displayed on a computer screen, such as Web pages and other computer content.
Note: The Ofcom Guidance Document [OFCOM] is based on the assumption that the television screen occupies the central ten degrees of vision. This is not accurate for a screen which is located in front of a person. The Wisconsin algorithm basically carries out the same analysis as the Ofcom Guidelines except that is does it on every possible ten degree window for a prototypical computer display.
workflow
A workflow is a customary sequence of steps or tasks that are followed to produce a deliverable.

Appendix B: References

For the latest version of any W3C specification please consult the list of W3C Technical Reports at http://www.w3.org/TR/. Some documents listed below may have been superseded since the publication of this document.

Note: In this document, bracketed labels such as "[HTML4]" link to the corresponding entries in this section. These labels are also identified as references through markup. Normative references are highlighted and identified through markup.

How to refer to this document

There are two recommended ways to refer to the "Authoring Tool Accessibility Guidelines 2.0" (and to W3C documents in general):

  1. References to a specific version of "Authoring Tool Accessibility Guidelines 2.0." For example, use the "this version" URI to refer to the current document: http://www.w3.org/TR/2006/WD-ATAG20-20061207/.
  2. References to the latest version of "Authoring Tool Accessibility Guidelines 2.0." Use the "latest version" URI to refer to the most recently published document in the series: http://www.w3.org/TR/ATAG20/.

In almost all cases, references (either by name or by link) should be to a specific version of the document. W3C will make every effort to make this document indefinitely available at its original address in its original form. The top of this document includes the relevant catalog metadata for specific references (including title, publication date, "this version" URI, editors' names, and copyright information).

An XHTML 1.0 paragraph including a reference to this specific document might be written:

<p>
<cite><a href="http://www.w3.org/TR/2006/REC-ATAG20-????????/">
"Authoring Tool Accessibility Guidelines 2.0,"</a></cite>
J. Treviranus, J. Richards, M. May, eds.,
W3C Recommendation, ?? ???? ????.
The <a href="http://www.w3.org/TR/ATAG20/">latest
version</a> of this document is available at
http://www.w3.org/TR/ATAG20/.</p>

For very general references to this document (where stability of content and anchors is not required), it may be appropriate to refer to the latest version of this document.

Other sections of this document explain how to build a conformance claim.

Normative references

A document appears in this section if at least one reference to the document appears in a checkpoint success criteria.

[WCAG10]
"Web Content Accessibility Guidelines 1.0", W. Chisholm, G. Vanderheiden, and I. Jacobs, eds., 5 May 1999. This WCAG 1.0 Recommendation is http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/.
[WCAG20]
"Web Content Accessibility Guidelines 2.0 (Working Draft)", W. Chisholm, G. Vanderheiden, and J. White, editors. The latest version of the Web Content Accessibility Guidelines 2.0 is available at http://www.w3.org/TR/WCAG20/. Note: This document is still a working draft.

Informative references

[ATAG10]
"Authoring Tool Accessibility Guidelines 1.0", J. Treviranus, C. McCathieNevile, I. Jacobs, and J. Richards, eds., 3 February 2000. This W3C Recommendation is available at http://www.w3.org/TR/2000/REC-ATAG10-20000203/.
 
 
[ATAG20-TECHS]
"Techniques for Authoring Tool Accessibility 2.0", J. Treviranus, J. Richards, C. McCathieNevile, and M. May, eds., 22 November 2004. The latest draft of this W3C note is available at http://www.w3.org/TR/ATAG20-TECHS.
[COMPONENTS]
"Essential Components of Web Accessibility", S. L. Henry, ed. This document is available at http://www.w3.org/WAI/intro/components.
[CSS2-ACCESS]
"Accessibility Features of CSS," I. Jacobs and J. Brewer, eds., 4 August 1999. This W3C Note is available at http://www.w3.org/1999/08/NOTE-CSS-access-19990804. The latest version of Accessibility Features of CSS is available at http://www.w3.org/TR/CSS-access.
[HTML4]
"HTML 4.01 Recommendation", D. Raggett, A. Le Hors, and I. Jacobs, eds., 24 December 1999. This HTML 4.01 Recommendation is http://www.w3.org/TR/1999/REC-html401-19991224. The latest version of HTML 4 is available at http://www.w3.org/TR/html4.
[MATHML]
"Mathematical Markup Language", P. Ion and R. Miner, eds., 7 April 1998, revised 7 July 1999. This MathML 1.0 Recommendation is http://www.w3.org/1999/07/REC-MathML-19990707. The latest version of MathML 1.0 is available at http://www.w3.org/TR/REC-MathML.
[OFCOM]
Guidance Notes, Section 2: Harm and offence Annex 1, "Ofcom Guidance Note on Flashing Images and Regular Patterns in Television (Re-issued as Ofcom Notes 25 July 2005)" available at http://www.ofcom.org.uk/tv/ifi/guidance/bguidance/guidance2.pdf)
[PWD-USE-WEB]
"How People With Disabilities Use the Web", J. Brewer, ed., 4 January 2001. This document is available at http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/.
[SMIL-ACCESS]
"Accessibility Features of SMIL," M.-R. Koivunen and I. Jacobs, eds., 21 September 1999. This W3C Note is available at available at http://www.w3.org/TR/SMIL-access.
[SVG]
"Scalable Vector Graphics (SVG) 1.0 Specification (Working Draft)", J. Ferraiolo, ed. The latest version of the SVG specification is available at http://www.w3.org/TR/SVG.
[SVG-ACCESS]
"Accessibility of Scalable Vector Graphics," C. McCathieNevile, M.-R. Koivunen, eds., 7 August 2000. This W3C Note is available at http://www.w3.org/TR/SVG-access.
[WCAG10-TECHS]
"Techniques for Web Content Accessibility Guidelines 1.0," W. Chisholm, G. Vanderheiden, and I. Jacobs, eds., 6 November 2000. This W3C Note is available at http://www.w3.org/TR/WCAG10-TECHS/.
[WCAG20-TECHS-GENERAL]
"General Techniques for WCAG 2.0," J. Slatin, T. Croucher, eds. Note: This document is still a working draft.
[WCAG20-TECHS-CSS]
"CSS Techniques for WCAG 2.0," W. Chisholm, B. Gibson, eds. Note: This document is still a working draft.
[WCAG20-TECHS-HTML]
"HTML Techniques for WCAG 2.0," M. Cooper, ed. Note: This document is still a working draft.
[WCAG20-TECHS-SCRIPTING]
"Client-side Scripting Techniques for WCAG 2.0," M. May, B. Gibson, eds. Note: This document is still a working draft.
[WCAG20-UNDERSTANDING]
"Understanding WCAG 2.0," B. Caldwell, W. Chisholm, J. Slatin, G. Vanderheiden, eds. Note: This document is still a working draft.
[XAG]
"XML Accessibility Guidelines", D. Dardailler, S. B. Palmer, C. McCathieNevile, eds. 3 October 2002. This is a Working Group Draft.

Appendix C: Acknowledgments

Participants active in the AUWG at the time of publication:

Other previously active WCAG WG participants and other contributors to WCAG 2.0

Kynn Bartlett, Giorgio Brajnik, Judy Brewer, Wendy Chisholm, Daniel Dardailler, Geoff Deering, Katie Haritos-Shea, Kip Harris, Phill Jenkins, Len Kasday, Marjolein Katsma, William Loughborough, Charles McCathieNevile, Matt May, Matthias Müller-Prove, Liddy Nevile, Graham Oliver, Wendy Porch, Bob Regan, Chris Ridpath, Gregory Rosmaita, Heather Swayne, Gregg Vanderheiden, Carlos Velasco, and Jason White.

This document would not have been possible without the work of those who contributed to ATAG 1.0.

This publication has been funded in part with Federal funds from the U.S. Department of Education under contract number ED05CO0039. The content of this publication does not necessarily reflect the views or policies of the U.S. Department of Education, nor does mention of trade names, commercial products, or organizations imply endorsement by the U.S. Government.


Appendix D: Checklist


Appendix E: Comparison of ATAG 1.0 checkpoints to ATAG 2.0


Level Double-A conformance icon, W3C-WAI Web Content Accessibility Guidelines 1.0