[Contents] [Techniques] [Checklist]

W3C

Authoring Tool Accessibility Guidelines 2.0

W3C Working Draft 9 July 2008

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

Editing Styles:

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.

The "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

May be Superseded

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/.

Editor's Draft of ATAG 2.0

This is an Editor's Draft.

Comments on any working draft should be sent to public-atag2-comments@w3.org (Public Archive).

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.

Web Accessibility Initiative

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.

No Endorsement

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.

Patents

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.


Table of Contents


Introduction

This section is informative, except where noted.

This is a Working Draft of the Authoring Tool Accessibility Guidelines (ATAG) version 2.0. This document includes recommendations for assisting developers to make their authoring tools more accessible to a wide range of people with disabilities, including blindness and low vision, deafness and hearing loss, learning disabilities, cognitive limitations, limited movement, speech difficulties, and others. However, even authoring tools that conform to ATAG 2.0 may not be fully accessible to every person with a disability. In order to achieve accessibility authoring tools must address the needs of two (potentially overlapping) user groups:

The guidelines do not include standard usability recommendations except where they have a significantly greater impact on people with disabilities than on other people.

Although some of the accessibility issues of people with cognitive, language, and learning disabilities are addressed by ATAG 2.0, either directly or through assistive technologies, the ATAG 2.0 guidelines do not address many areas of need for people with these disabilities. There is a need for more research and development in this important area.

These guidelines have been written to address the requirements of many different audiences, including, but not limited to:

Definition of authoring tool

This section is normative.

ATAG 2.0 defines an "authoring tool" as any software, or collection of software components, that authors can use to create or modify Web content for use by other people.

This definition can cover components such as :

Note: Synchronous tools (e.g., chats, collaboration tools, whiteboards, etc.), especially those that archive as Web content, are considered authoring tools and can be made more accessible for both participants and users of the stored archives. While not all parts of ATAG 2.0 will usefully apply, some Techniques for Real-Time Content Production are available.

Components of Web Accessibility

Authoring tools are just one aspect of accessibility. For an overview of the different components of accessibility and how they work together see:

Organization of the ATAG 2.0 Document

Two Parts

ATAG 2.0 is divided into two parts, each reflecting a key aspect of accessible authoring tools. Part A includes principles and associated guidelines that are related to ensuring accessibility of the authoring tool user interface to authors with disabilities. Part B contains principles and guidelines related to ensuring support by authoring tools for the creation of accessible Web content by any author (not just those with disabilities) to end users with disabilities.

Part A: Make the authoring tool user interface accessible

The guidelines and success criteria in Part A are organized around the following four principles, adapted from the four principles in WCAG 2.0:

  1. Authoring tool must facilitate access by assistive technology - Assistive technologies can only provide augmented display and control to their users if the relevant information is made available by authoring tools using common protocols.
  2. Authoring tool must be perceivable - Authors with a wide range of abilities must be able to perceive its user interface components.
  3. Authoring tool must be operable - Authors with a wide range of abilities must be able to operate its user interface components.
  4. Authoring tool must be understandable - Authors with a wide range of abilities must be able to understand the user interface components that they can perceive and operate.
Part B: Support the production of accessible content

There are three principles in Part B:

  1. Production of accessible content must be enabled - The creation of accessible content is dependent on the combined actions of the authoring tool and the author. This guideline specifies the responsibilities that rest exclusively with the tool.
  2. Authors must be supported 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.
  3. Accessibility solutions must be promoted and integrated - This guideline includes guidelines that require authoring tools to raise the profile of accessible authoring practices, while at the same time, integrating functions related to accessibility in order to encourage authors to make them common practice. Authoring tools should encourage the discovery of tools, features, or functionality which support accessible authoring practices, while at the same time, integrating functions related to accessibility in order to ensure that authors make them common practice.

Note: While the requirements in Part B 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 success criteria must also meet the user interface accessibility requirements of Part A.

Success Criteria

Under each guideline there are success criteria that describe specifically what must be achieved in order to conform. They are similar to the "checkpoints" in ATAG 1.0. Each success criterion is written as a statement that will be either true or false when a specific authoring tool is tested against it.

All ATAG 2.0 success criteria are written to be testable. While some can be tested by software, others require human testers for part or all of the test.

Each success criterion for a guideline has a link to the Techniques document that provides:

Success Criteria Levels

ATAG 2.0 success criteria are organized into three levels of conformance.

Note: If a guideline success criterion is not applicable to an authoring tool, then that success criterion is treated as satisfied for conformance purposes as long as a rationale is provided.

Levels of Conformance

Authoring tools may claim full conformance to ATAG 2.0 at one of three conformance levels. The level achieved depends on the level of the success criteria that have been satisfied. The full conformance levels are:

  1. Full ATAG 2.0 Conformance at Level "A"
    The authoring tool satisfies all of the Level A success criteria.
  2. Full ATAG 2.0 Conformance at Level "Double-A"
    The authoring tool satisfies all of the Level A and Level AA success criteria.
  3. Full ATAG 2.0 Conformance at Level "Triple-A"
    The authoring tool satisfies all of the success criteria.

In addition, a Partial Conformance claim option is available in cases where an authoring tool has satisfied all of the success criteria at a specified level 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"). The partial conformance levels are:

  1. Partial ATAG 2.0 Conformance Level "A": Authoring Tool User Interface
    The authoring tool satisfies all of the Level A success criteria in Part A. Nothing is claimed about Part B.
  2. Partial ATAG 2.0 Conformance Level "Double-A": Authoring Tool User Interface
    The authoring tool satisfies all of the Level A and Level AA success criteria in Part A. Nothing is claimed about Part B.
  3. Partial ATAG 2.0 Conformance Level "Triple-A": Authoring Tool User Interface
    The authoring tool satisfies all of the success criteria in Part A. Nothing is claimed about Part B.
  4. Partial ATAG 2.0 Conformance Level "A": Content Production"
    The authoring tool satisfies all of the Level A success criteria in Part B. Nothing is claimed about Part A.
  5. Partial ATAG 2.0 Conformance Level "Double-A": Content Production"
    The authoring tool satisfies all of the Level A and Level AA success criteria in Part B. Nothing is claimed about Part A.
  6. Partial ATAG 2.0 Conformance Level "Triple-A": Content Production"
    The authoring tool satisfies all of the success criteria in Part B. Nothing is claimed about Part A.

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.

Relationship to the Web Content Accessibility Guidelines (WCAG)

The ATAG 2.0 conformance model relies upon Web Content Accessibility "Benchmark" documents to precisely specify what an evaluator interprets "Accessible Web Content" to mean for the particular Web content technologies that an authoring tool produces and is implemented using (if applicable).

The recommended reference for the Web Content Accessibility "Benchmark" is the W3C Web Content Accessibility Guidelines (WCAG) due to the quality of the documents and the process under which they were developed (See Note on other Accessibility Standards). 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]. Although a Web Content Accessibility "Benchmark" document may use either version of WCAG, developers should give consideration to the following when deciding which WCAG version to use in a product:


ATAG 2.0 Guidelines

This section is normative.

PART A: Make the authoring tool user interface accessible

Conformance Notes for Part A:

PRINCIPLE A.1: Authoring tools must facilitate access by assistive technologies

Guideline A.1.1 [For the authoring tool user interface] Ensure that Web-based functionality is accessible. [Techniques]

Rationale: In addition to generally improving the accessibility of the authoring tool user interface, implementing Web-based functionality (e.g., editing views, documentation) using accessible Web content facilitates communication with assistive technologies via user agents.

Level A Success Criteria for Guideline A.1.1
Level AA Success Criteria for Guideline A.1.1
Level AAA Success Criteria for Guideline A.1.1

Applicability Note: This guideline does not apply to non-Web-based authoring tool user interfaces.

Guideline A.1.2 [For the authoring tool user interface] Support interoperability with assistive technologies. [Techniques]

Rationale: Assistive technologies that are used by many people 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. These protocols are typically implemented via an accessibility architecture, which provides a means by which content authors and aplication developers can export additional semantic information to assistive technologies in order to effect alternative presentations.

Level A Success Criteria for Guideline A.1.2
Level AA Success Criteria for Guideline A.1.2
  • A.1.2.3 Deviation from Proper Use (user interface "chrome", content display): If any non-Web-based authoring user interface functionality deviates from the proper use of the implemented accessibility platform architecture(s) (i.e., lack of use, incomplete use, inappropriate use) as defined by the documentation for the accessibility platform architecture(s), this is documented with the conformance claim. @@RS concerns@@
Level AAA Success Criteria for Guideline A.1.2
  • A.1.2.4 Additional Information (user interface "chrome", content display): For non-Web-based authoring user interfaces, additional information is published describing the nature of the implementation of the accessibility platform architecture(s) (e.g., that the long description is different from the associated tool tip).

Applicability Note: This guideline does not apply to Web-based authoring tool user interface functionality.

Guideline A.1.3 [For the authoring tool user interface] Follow the accessibility conventions of the platform. [Techniques]

Rationale: Following platform accessibility conventions lessens the need for assistive technologies to make special-purpose accommodations. Also, people who are familiar with the accessibility conventions employed by a specific platform will find applications that adhere to those conventions easier to use. @@RS concerns@@

Level A Success Criteria for Guideline A.1.3
  • A.1.3.1 Follow and Cite Conventions (user interface "chrome", content display): Platform conventions are followed and the convention sources are cited for all of the following: @@RS concerns@@
    • (a) Input: Keyboard, mouse, etc. including non-interference with keyboard accessibility features of the platform (e.g., StickyKeys, SlowKeys, browser link navigation)
    • (b) Focus
    • (c) Selection, and
    • (d) Product installation.
Level AA Success Criteria for Guideline A.1.3
  • A.1.3.2 Follow and Cite Conventions (user interface "chrome", content display): Platform conventions are followed and the convention sources are cited for all of the following:
    • (a) User interface design,
    • (b) Keyboard configuration, and
    • (c) Documentation.
Level AAA Success Criteria for Guideline A.1.3
  • (No level AAA success criteria for Guideline A.1.3)

PRINCIPLE A.2: Authoring tool user interface must be perceivable

Guideline A.2.1 [For the authoring tool user interface] Display text alternatives for non-text objects. [Techniques]

Rationale: People who have difficulty perceiving non-text objects are often able to access text alternatives of the same information because there are a variety of ways to display text (e.g., magnification, enhancement, text-to-speech, Braille output)

Level A Success Criteria for Guideline A.2.1
  • A.2.1.1 Non-text objects displayed in content display (content display): Editing views that render non-text objects contained within the content being edited can display any text alternatives that are identifiable by the authoring tool. It is permissible for the authoring tool to change editing views to display the text alternatives (e.g., from WYSIWYG to instruction level). @@RS mentions "surfacing"@@
  • A.2.1.2 Non-text objects displayed in the "chrome" (user interface "chrome"): Non-text objects in the "chrome" have text alternatives that present equivalent information, except for the situations listed below. [WCAG 2.0]
    • (a) Controls-Input: If a non-text object is a control or accepts user input, then it has a name that describes its purpose. [WCAG 2.0]
    • (b) Time-Based Media: If a non-text object is time-based media, then text alternatives at least provide descriptive identification of the non-text object. (Refer to Guideline A.2.2 for additional requirements for time-based media.) [WCAG 2.0]
    • (c) Test: If a non-text object is a test or exercise that must be presented in non-text format, then text alternatives at least provide descriptive identification of the non-text object. [WCAG 2.0]
    • (d) Sensory: If a non-text object is primarily intended to create a specific sensory experience, then text alternatives at least provide descriptive identification of the non-text object. [WCAG 2.0]
    • (e) CAPTCHA: If the purpose of a non-text object is to confirm that use by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text object are provided, and alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities. [WCAG 2.0]
    • (f) Decoration, Formatting, Invisible: If a non-text object provides no information or functionality, or is used only for visual formatting or is not presented to users, then it is implemented such that it can be ignored by assistive technology. [WCAG 2.0]
Level AA Success Criteria for Guideline A.2.1
  • (No level AA success criteria for Guideline A.2.1)
Level AAA Success Criteria for Guideline A.2.1
  • (No level AAA success criteria for Guideline A.2.1)

Guideline A.2.2 [For the authoring tool user interface] Display synchronized alternatives for time-based synchronized media. [Techniques]

Rationale: People who have difficulty accessing or interpreting time-based media 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. 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.

Level A Success Criteria for Guideline A.2.2
Level AA Success Criteria for Guideline A.2.2
  • Prerecorded synchronized audio and video (user interface "chrome"): Audio descriptions of the video are provided.
  • Live synchronized audio and video (user interface "chrome"): Captions of the audio are provided.
  • A.2.2.4 Audio Description (user interface "chrome"): If prerecorded video is present in the user interface "chrome", then at least one of the following are true: [WCAG 2.0]
    • (a) Audio Track: all of the information in the video track is provided in the audio track, or
    • (b) Audio Descriptions: audio descriptions are provided.
Level AAA Success Criteria for Guideline A.2.2

Guideline A.2.3 [For the authoring tool user interface] Ensure that the interface can be presented in different ways. [Techniques]

Rationale: Authors need to have access to and control over both the functional significance of presentation and also, in the context of authoring, the presentation that will be experienced by the end user. This is especially important for user interface components that do not implement an accessibility platform architecture or leverage existing implementations (e.g. custom user interface components built via JavaScript and CSS).

Level A Success Criteria for Guideline A.2.3
  • A.2.3.1 Name, Role, Value (user interface "chrome"): For all user interface components in the user interface "chrome", all of the following are true: [WCAG 2.0]
    • (a) the name and role are available via the platform,
    • (b) states, properties, and values that can be set by authors are available via the platform, and
    • (c) notification of changes to these items is available via the platform.
  • A.2.3.2 Info and Relationships (user interface "chrome"): In the user interface "chrome", information, structure, and relationships conveyed through presentation is available via the platform or are available in text. [WCAG 2.0]
  • A.2.3.3 Purpose of Added Presentation (content display): If the authoring tool modifies the presentation of the content being edited, then the functional purpose for the modification is made available via the platform (e.g., if misspelled text is underlined, the fact that it is is misspelled is important).
  • A.2.3.4 Access to Some Editable Presentation Being Edited (content displays): If an editing view (e.g., WYSIWYG) renders any of the following text presentation properties and those properties are editable by any editing view (e.g., instruction level), then the properties are made available via the platform:
    • (a) font,
    • (b) style (e.g., italic, bold),
    • (c) color, and
    • (d) size.
  • A.2.3.5 Meaningful Sequence (user interface "chrome"): When the sequence in which user interface "chrome" components are presented affect their meaning, a correct reading sequence (DEFN: any sequence where words and paragraphs are presented in an order that does not change the meaning of the content ) is available via the platform. [WCAG 2.0]
  • A.2.3.6 Sensory Characteristics (user interface "chrome"): Instructions provided for understanding and operating the user interface "chrome" do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation or sound. [WCAG 2.0]
Level AA Success Criteria for Guideline A.2.3
  • (No level AA success criteria for Guideline A.2.3)
Level AAA Success Criteria for Guideline A.2.3
  • A.2.3.7 Access to All Edtiable Text Presentation Being Edited (content displays): Any text presentation properties (text size, positioning, etc.) that are rendered in an editing view (e.g., WYSIWYG editing views ) and editable by any editing view are available via the platform. @@RS concerns@@

Guideline A.2.4 [For the authoring tool user interface] Make it easier to see and hear the interface. [Techniques]

Rationale: Some authors require display settings that differ from the presentation that they intend to define for the published content (e.g., using a high contrast setting during editing content that is not intended to be high contrast).

Level A Success Criteria for Guideline A.2.4
  • A.2.4.1 Independence of Display (content display): Editing views that usually have their display characteristics set by rendering the content being edited (e.g., WYSIWYG editing views) allows the authors' visual and audio display settings to override these characteristics without affecting the content (e.g., markup, stylesheets, etc.) being edited. @@RS concerns@@
  • A.2.4.2 Use of Color (user interface "chrome", content display): Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. [WCAG 2.0]
  • A.2.4.3 Audio Control (user interface "chrome", content display): If any audio plays automatically for more than 3 seconds, at least one of the following is true [WCAG 2.0]:
    • (a) Pause: authors can pause or stop the audio, or
    • (b) Control: authors can set the audio volume to a different level from the system volume level.
  • A.2.4.4 Visual Display (user interface "chrome", content display): If a visual display is provided, authors can configure the visual display settings (i.e., fonts, sizes, colors, spacing, positioning, and contrast) by at least one of the following methods:
    • (a) Platform Settings: an option to inherit the platform settings, or
    • (b) Tool Specific Settings: content display settings specific to the authoring tool.
  • A.2.4.5 Audio Display (user interface "chrome", content display): If an audio display is provided, authors can configure the audio display settings (i.e., volume, speech voices, voice speed, and voice emphasis) by at least one of the following methods:
    • (a) Platform Settings: an option to inherit the platform settings, or
    • (b) Tool Specific Settings: content display settings specific to the authoring tool.
Level AA Success Criteria for Guideline A.2.4
  • A.2.4.6 Visual Configurability (user interface "chrome", content display): If the visual display settings are not inherited from the platform settings, then the authoring tool provides at least comparable configurable properties with at least comparable configuration ranges as the platform provides. @@RS concerns@@
  • A.2.4.7 Audio Configurability (user interface "chrome", content display): If the audio display settings are not inherited from the platform settings, then the authoring tool provides at least comparable configurable properties with at least comparable configuration ranges as the platform provides. @@RS concerns@@
Level AAA Success Criteria for Guideline A.2.4
  • A.2.4.8 Low or No Background Audio (user interface "chrome"): For audio content that (1) is not an audio CAPTCHA and (2) contains speech in the foreground, at least one of the following is true: (a) the audio does not contain background sounds, (b) the background sounds can be turned off, or (3) the background sounds are at least 20 decibels lower than the foreground speech content, with the exception of occasional sound effects. [WCAG 2.0]

Note: While the success criteria for this guideline are based on the capabilities of the platforms (e.g., operating systems, user agents, GUI toolkits) listed in the conformance profile, additional configuration settings may be provided.

PRINCIPLE A.3: Authoring tool user interface must be operable

Guideline A.3.1 [For the authoring tool user interface] Ensure that all functionality is available from a keyboard. [Techniques]

Rationale: Providing alternate keyboard accessibility provides access for people with limited mobility and people with visual disabilities, who cannot rely on hand-eye coordination for navigating the user interface.

Level A Success Criteria for Guideline A.3.1
  • A.3.1.1 Keyboard (user interface "chrome", content display): Authors can, through keyboard input alone, navigate to and operate all of the functions included in 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 where the underlying function requires input that depends on the path of the user's movement and not just the endpoints (e.g., freeform drawing). This applies to at least one mechanism per authoring outcome. This means non-keyboard accessible mechanisms can remain available (e.g., providing resizing with mouse-"handles" and with a properties dialog). [WCAG 2.0, UAAG 2.0]
  • A.3.1.2 No Keyboard Trap (user interface "chrome", content display): If focus can be moved to a component with the keyboard, then at least one of the following is true [WCAG 2.0]:
    • (a) standard keys: focus can be moved away from the component with the keyboard using standard navigation keys (i.e., unmodified arrow or tab keys), or
    • (b) documented non-standard keys: focus can be moved away from the component with non-standard keys and the author is advised of the method.
  • A.3.1.3 Available Keystrokes (user interface "chrome", content display): Authors can always determine the currently available keystrokes (e.g., from a central location such as a list in the help system or a distributed location such as associating shortcuts with menu items). [UAAG 2.0]
  • A.3.1.4 Standard Text Area Conventions (content display): Editing views that allow text entry support the standard text area conventions for the platform including, but not necessarily limited to: character keys, backspace/delete, insert, "arrow" key navigation, page up/page down, navigate to start/end, navigate by paragraph, shift-to-select mechanism, etc.
  • A.3.1.5 "Chrome" Navigation (user interface "chrome"): Authors can use the keyboard to traverse forwards/backwards all of the components, including those in floating toolbars, panels, etc. using conventions of the platform (e.g., via "tab", "shift-tab", "ctrl-tab", "ctrl-shift-tab"). [UAAG 2.0]
Level AA Success Criteria for Guideline A.3.1
  • A.3.1.6 Accelerator Keys (user interface "chrome"): If the authoring tool includes any of the following functions, authors can enable key-plus-modifier-key (or single-key) access to them: @@RS P1?@@
    • (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, and
    • (h) open find/replace function.
  • A.3.1.7 Change Accelerator Keys (user interface "chrome"): Authors can modify key-plus-modifier-key (or single-key) combinations. @@Work being done on this in UAWG@@
Level AAA Success Criteria for Guideline A.3.1
  • A.3.1.8 Inter-group Navigation (user interface "chrome", content display): If logical groups of focusable components (e.g., toolbars, dialogs, labeled groups, panels) are present, authors can use the keyboard to navigate to a focusable component in the next and previous groups. [UAAG 2.0]
  • A.3.1.9 Group Navigation (user interface "chrome", content display): If logical groups of focusable components are present, authors can use the keyboard to navigate to the first, last, next and previous focusable component within the current group. [UAAG 2.0]

Note 1: Web-based authoring tool user interface functionality may rely on the keyboard navigation functions of the user agent listed in the conformance profile to satisfy some of these success criteria.

Note 2: This guideline should not discourage the support of other input methods (such as a mouse) in addition to keyboard operation. Also see Guideline A.3.1 when choosing keystrokes.

Guideline A.3.2 [For the authoring tool user interface] Enable time-independent interaction. [Techniques]

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

Level A Success Criteria for Guideline A.3.2
Level AA Success Criteria for Guideline A.3.2
  • (No level AA success criteria for Guideline A.3.2)
Level AAA Success Criteria for Guideline A.3.2
  • A.3.2.4 No Time Limits: The authoring tool does not impose time limits on authoring sessions.

Guideline A.3.3 [For the authoring tool user interface] Help authors avoid flashing that could cause seizures. [Techniques]

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

Level A Success Criteria for Guideline A.3.3
Level AA Success Criteria for Guideline A.3.3
  • (No level AA success criteria for Guideline A.3.3)
Level AAA Success Criteria for Guideline A.3.3
  • A.3.3.3 Three Flashes (user interface "chrome"): No part of the user interface "chrome" ever flashes more than three times in any one second period. [WCAG 2.0]

Guideline A.3.4 [For the authoring tool user interface] Provide navigation and editing via content structure. [Techniques]

Rationale: People who have difficulty typing or operating the mouse benefit when the structure that may be inherent in certain content can be used to navigate more efficiently within editing views and to perform edits.

Level A Success Criteria for Guideline A.3.4
Level AA Success Criteria for Guideline A.3.4
  • A.3.4.2 Navigate By Element Type (content display): If an editing view displays a structured element set, authors can move the editing focus forward/backward to the next identical or closely related (e.g., in the case of headers) element.
  • A.3.4.3 Navigate Tree Structures (content display): If an editing view displays a structured element set, authors can, with a simple action, move the editing focus from any element to other elements in the set with any of the following relationships (if they exist):
    • (a) Parent: the element immediately above,
    • (b) Child: the first element immediately below,
    • (c) Previous Sibling: the element immediately preceding at the same level, and
    • (d) Next Sibling: the element immediately following at the same level.
Level AAA Success Criteria for Guideline A.3.4
  • (No level AAA success criteria for Guideline A.3.4)

Guideline A.3.5 [For the authoring tool user interface] Provide text search. [Techniques]

Rationale: People who have difficulty typing or operating the mouse benefit from the ability to navigation to arbitrary points within editing views.

Level A Success Criteria for Guideline A.3.5
  • (No level A success criteria for Guideline A.3.5)
Level AA Success Criteria for Guideline A.3.5
  • A.3.5.1 Text Search (content display): A text search function is provided that meets the following conditions:
    • (a) Search All Editable: can search any textual information (including text content, text alternatives for non-text objects, metadata, markup) that is editable using the authoring tool.
    • (b) Bi-Directional: can search backwards and forwards. [UAAG 2.0]
    • (c) Case Sensitive: can search in both case sensitive and case insensitive modes. [UAAG 2.0]
    • (d) May Switch Views: permissible for the authoring tool to switch editing views to display the search results (e.g., from WYSIWYG to instruction level in order to display markup).
Level AAA Success Criteria for Guideline A.3.5
  • (No level AAA success criteria for Guideline A.3.5)

Note: Web-based authoring tool user interface functionality may rely on the "find" function of the user agent listed in the conformance profile to help perform the searches.

Guideline A.3.6 [For the authoring tool user interface] Manage preference settings. [Techniques]

Rationale: Providing the ability to save and reload sets of keyboard and display preference settings benefits people using multi-user tools as well as people who have needs that differ over time (e.g., due to fatigue).

Level A Success Criteria for Guideline A.3.6
  • (No level A success criteria for Guideline A.3.6)
Level AA Success Criteria for Guideline A.3.6
Level AAA Success Criteria for Guideline A.3.6

Guideline A.3.7 [For the authoring tool user interface] Ensure that previews are as accessible as existing user agents. [Techniques]

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. Authors with disabilities need to be able to follow the same workflow.

Level A Success Criteria for Guideline A.3.7
  • A.3.7.1 Return Mechanism (user interface "chrome"): If a preview is provided, then a mechanism for returning from the preview (i.e., moving focus back from, exiting from) is provided that meets the keyboard accessibility requirement (Guideline A.3.1) and is documented in the help system.
  • A.3.7.2 Preview (user interface "chrome", content display): If a preview is provided, then it meets at least one of the following:
    • (a) Existing User Agent: the preview makes use of an existing user agent that is specified in the conformance profile (e.g., opening the content in a third-party browser or browser component),
    • (b) Part A: the preview meets all of the Level A guidelines in Part A of these guidelines, or
    • (c) UAAG: the preview conforms to a version of the User Agent Accessibility Guidelines [UAAG].
Level AA Success Criteria for Guideline A.3.7
  • (No level AA success criteria for Guideline A.3.7)
Level AAA Success Criteria for Guideline A.3.7
  • (No level AAA success criteria for Guideline A.3.7)

Note: Previews are treated differently than editing views because 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 guideline.

PRINCIPLE A.4: Authoring tool user interface must be understandable

Guideline A.4.1 Make text content readable and understandable. [Techniques]

Rationale: Some authors will benefit from support for understanding unusual words or abbreviations

Level A Success Criteria for Guideline A.4.1
  • (No level A success criteria for Guideline A.4.1)
Level AA Success Criteria for Guideline A.4.1
  • (No level AA success criteria for Guideline A.4.1)
Level AAA Success Criteria for Guideline A.4.1
  • A.4.1.1 Unusual Words (user interface "chrome"): A mechanism is provided for identifying specific definitions of words or phrases used in an unusual or restricted way, including idioms and jargon. [WCAG 2.0]
  • A.4.1.2 Abbreviations (user interface "chrome"): A mechanism is provided for finding the expanded form or meaning of abbreviations. [WCAG 2.0]

Guideline A.4.2 [For the authoring tool user interface] Make functionality predictable. [Techniques]

Rationale: People who may become easily disoriented benefit when authoring tool user interfaces are consistent and predictable.

Level A Success Criteria for Guideline A.4.2
  • A.4.2.1 On Focus (user interface "chrome"): When any component receives focus, it does not initiate a change of context. [WCAG 2.0]
  • A.4.2.2 On Input (user interface "chrome"): Changing the setting of any component does not automatically cause a change of context unless authors has been advised of the behavior before using the component. [WCAG 2.0]
  • A.4.2.3 Consistent Identification (user interface "chrome"): Components that have the same functionality within the user interface "chrome" are identified consistently. [WCAG 2.0]
Level AA Success Criteria for Guideline A.4.2
  • A.4.2.4 Consistent Navigation (user interface "chrome"): Navigational mechanisms that are repeated in multiple areas of the user interface "chrome" occur in the same relative order each time they are repeated, unless a change is initiated by the authors. [WCAG 2.0]
Level AAA Success Criteria for Guideline A.4.2
  • A.4.2.5 Change on Request (user interface "chrome", content display): Changes of context are initiated only by authors' request or a mechanism is available to turn off such changes. [WCAG 2.0]

Guideline A.4.3 [For the authoring tool user interface] Help users avoid and correct mistakes. [Techniques]

Rationale: People who have difficulty making fine movements may be prone to making unintended actions.

Level A Success Criteria for Guideline A.4.3
  • A.4.3.1 Undo Content Changes (content display): Authoring actions are either reversible by an "undo" function or include a warning to authors that the action is irreversible. The authoring tool may have certain committing actions (e.g., "save" function) that reset the undo history.
  • A.4.3.2 Undo Setting Changes (user interface "chrome"): Actions that modify authoring tool settings are either reversible or include a warning to the author that the setting modification is irreversible.
  • A.4.3.3 Error Identification: If an input error is detected, the component that is in error is identified and the error is described to authors in text. [WCAG 2.0]
  • A.4.3.4 Labels or Instructions: Labels or instructions are provided when author input is required. [WCAG 2.0]
Level AA Success Criteria for Guideline A.4.3
  • A.4.3.5 Redo (user interface "chrome", content display): Authors are able to immediately reverse the most recent undo(s) (i.e., a "redo" function).
  • A.4.3.6 Error Suggestion: If an input error is detected and suggestions for correction are known, then the suggestions are provided to authors, unless it would jeopardize security. [WCAG 2.0]
Level AAA Success Criteria for Guideline A.4.3

Note 1: Web-based authoring tool user interface functionality may rely on the "undo" function of the user agent listed in the conformance profile to perform the undo function for some editing actions that do not involve server communication (e.g., typing in a text area).

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

Guideline A.4.4 [For the authoring tool user interface] Document the user interface including all accessibility features. [Techniques]

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

Level A Success Criteria for Guideline A.4.4
  • A.4.4.1 Accessible Format (user interface "chrome"): At least one version of the documentation is either:
    • (a) "A" Accessible: Web content and conforms to a minimum level of Web content accessibility (although it is not necessary for the documentation to be delivered on-line), or
    • (b) Accessible Platform Format: not Web content and conforms to a published accessibility benchmark that is identified in the conformance claim (e.g., when platform-specific documentation systems are used).
  • A.4.4.2 Document Accessibility Features (user interface "chrome"): All features (other than documentation) that are specifically required to meet Part A of these guidelines (e.g. keyboard shortcuts, text search, etc.) are documented.
Level AA Success Criteria for Guideline A.4.4
  • (No level AA success criteria for Guideline A.4.4)
Level AAA Success Criteria for Guideline A.4.4
  • (No level AAA success criteria for Guideline A.4.4)

PART B: Support the production of accessible content

Conformance Notes for Part B:

  • Referenced Technologies Only: While the production of accessible content is always recommended, conformance claims are only made in reference to the benchmarked Web content technologies identified in the conformance claim.

PRINCIPLE B.1: Production of accessible content must be enabled

Guideline B.1.1 Support Web content technologies that enable the creation of content that is accessible. [Techniques]

Rationale: Using Web content technologies with published Web content accessibility benchmarks facilitates accessibility evaluation.

Level A Success Criteria for Guideline B.1.1
  • B.1.1.1 Automatic Choice of "A" Technologies: If the authoring tool automatically selects Web content technologies automatically, then the selection is a level "A" benchmarked technology.
  • B.1.1.2 Author Choice of "A" Technologies: If the authoring tool provides authors with technology options, level "A" benchmarked technology options are listed with at least as much prominence as any other options.
Level AA Success Criteria for Guideline B.1.1
  • B.1.1.3 Automatic Choice of "AA" Technologies: If the authoring tool automatically selects Web content technologies automatically, then the selection is a level "AA" benchmarked technology.
  • B.1.1.4 Author Choice of "AA" Technologies: If the authoring tool provides authors with technology options, level "AA" benchmarked technology options are listed with at least as much prominence as any other options.
Level AAA Success Criteria for Guideline B.1.1
  • B.1.1.5 Automatic Choice of "AAA" Technologies: If the authoring tool automatically selects Web content technologies automatically, then the selection is a level "AAA" benchmarked technology.
  • B.1.1.6 Author Choice of "AAA" Technologies: If the authoring tool provides authors with technology options, level "AAA" benchmarked technology options are listed with at least as much prominence as any other options.

Applicability Note: This guideline only applies when benchmarked technologies are available for authoring the particular type of content required (e.g., text, images, synchronized media).

Guideline B.1.2 Ensure that the authoring tool preserves accessibility information. [Techniques]

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

Level A Success Criteria for Guideline B.1.2
  • B.1.2.1 Transformation or Conversion: If the authoring tool performs transformations or conversions, then at least one of the following is true:
    • (a) Preserve in Output: any accessibility information in the pre-transformation/conversion content is preserved and available for end users in the resulting content; or
    • (b) Preserve Input and Notify: a copy of the pre-transformation/conversion content is retained (e.g., as a "comment", by saving a backup copy) and the authors are notified of the location.
Level AA Success Criteria for Guideline B.1.2
  • B.1.2.2 Notification Prior to Deletion: If the authoring tool automatically deletes any author-generated content for any reason, then at least one of the following is true:
    • (a) Not Accessibility Information: the authoring tool can detect that the content is not accessibility information; or
    • (b) Notification Option: authors have the option to receive notification before deletion.
Level AAA Success Criteria for Guideline B.1.2
  • (No level AAA success criteria for Guideline B.1.2)

Guideline B.1.3 Ensure that automatically generated content is accessible. [Techniques]

Rationale: Authoring tools that automatically generate content that is not accessible impose additional repair tasks on authors.

Related: If accessibility information is required from authors during the automatic generation process, see Guideline B.2.1. If templates or other pre-authored content are involved, see Guideline B.2.5.

Level A Success Criteria for Guideline B.1.3
Level AA Success Criteria for Guideline B.1.3
Level AAA Success Criteria for Guideline B.1.3

Applicability Note 1: This guidelines does apply to any accessibility problems that informed authors have specifically allowed (e.g., by setting less strict preferences) (see Guideline B.3.3 for more on informing the author).

Applicability Note 2: This guideline does not apply when authors have caused the accessibility problem(s) (e.g., by ignoring prompts for accessibility information, providing faulty information, etc.).

PRINCIPLE B.2: Authors must be supported in the production of accessible content

Guideline B.2.1 Prompt authors to create accessible content. [Techniques]

Rationale: By guiding the authors from the outset towards the creation and maintenance of accessible content, accessibility problems are mitigated and less repair and retrofit effort is required.

Level A Success Criteria for Guideline B.2.1
Level AA Success Criteria for Guideline B.2.1
  • B.2.1.3 Prompt "AA" Accessible: If authors are prompted for any information as content is being added or updated, then the tool also prominently prompts for accessibility information required for that content to meet the level "AA" Web content accessibility benchmarks.
  • B.2.1.4 Warn "AA" Accessible: If an authoring action or instruction will always lead to the creation of content that cannot be made to meet the level "AA" Web content accessibility benchmarks other than by making an alternative version, then a warning is displayed.
Level AAA Success Criteria for Guideline B.2.1
  • B.2.1.5 Prompt "AAA" Accessible: If authors are prompted for any information as content is being added or updated, then the tool also prominently prompts for accessibility information required for that content to meet the level "AAA" Web content accessibility benchmarks.
  • B.2.1.6 Warn "AAA" Accessible: If an authoring action or instruction will always lead to the creation of content that cannot be made to meet the level "AAA" Web content accessibility benchmarks other than by making an alternative version, then a warning is displayed.

Guideline B.2.2 Assist authors in checking for accessibility problems. [Techniques]

Rationale: Checking as an integrated function of the authoring tool helps make authors aware of accessibility problems during the authoring process, so they can be immediately addressed.

Level A Success Criteria for Guideline B.2.2
  • B.2.2.1 Check "A" Accessibility: An individual check is associated with each level "A" Web content accessibility benchmark. @@RS concerns@@
  • B.2.2.2 Availability: Checking is available to authors prior to the end of the authoring session.
  • B.2.2.3 Identify Range: The appropriate range (e.g., element, group of elements, entire file, etc.) for each potential accessibility problem is identified. Excessively general checks (e.g., "does the page meet all of the requirements?") are not acceptable.
  • B.2.2.4 Help Authors Decide: For any checks that require author judgment to determine whether a potential accessibility problem is correctly identified (i.e., manual checking and semi-automated checking), instructions are provided to help authors to decide.
Level AA Success Criteria for Guideline B.2.2
  • B.2.2.5 Check "AA" Accessibility: An individual check is associated with each level "AA" Web content accessibility benchmark.
  • B.2.2.6 View Status: If the authoring tool records accessibility problems found during checking, then a list of any accessibility problems is available to authors prior to the end of the authoring session.
  • B.2.2.7 Save Status for Repair: If repair assistance is not provided during checking , authors have the option to save the list to facilitate interoperability between checking and repair.
  • B.2.2.8 Metadata for Discovery: If the authoring tool records accessibility status, then authors have the option to associate this status with the content as metadata to facilitate resource discovery by end users.
Level AAA Success Criteria for Guideline B.2.2

Note: While automated checking or more advanced implementations of semi-automated checking may improve the authoring experience, these are not required to meet the success criteria for this guideline.

Applicability Note: This guideline does not apply if the authoring tool controls the authoring process to an extent that it is not possible for authors to introduce accessibility problems.

Guideline B.2.3 Assist authors in repairing accessibility problems. [Techniques]

Rationale: Repair as an integral part of the authoring process greatly enhances the utility of checking and increases the likelihood that accessibility problems will be properly addressed.

Level A Success Criteria for Guideline B.2.3
Level AA Success Criteria for Guideline B.2.3
Level AAA Success Criteria for Guideline B.2.3

Note: While automated repairing or more advanced implementations of semi-automated repairing may improve the authoring experience, these are not required to meet the success criteria for this guideline.

Applicability Note: This guideline does not apply if the authoring tool controls the authoring process to an extent that it is not possible for authors to introduce accessibility problems.

Guideline B.2.4 Assist authors to manage, edit, and reuse equivalent alternatives for non-text objects. [Techniques]

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

Level A Success Criteria for Guideline B.2.4
Level AA Success Criteria for Guideline B.2.4
  • B.2.4.3 Acceptable Sources: Authoring tools only supply equivalent alternatives from the following sources:
    • (a) Author-Entered: equivalent alternatives previously entered by authors for the same non-text object (e.g., by the same author, or another author on a collaborative system),
    • (b) From Object Database: equivalent alternatives stored with the non-text object in an object database (or equivalent), or
    • (c) Null when Appropriate: null equivalent alternatives for non-text objects that the authoring tool can detect are only used for visual formatting.
Level AAA Success Criteria for Guideline B.2.4
  • B.2.4.4 Save for Reuse: Authors can store, for future reuse, both of the following author-assigned equivalent alternatives (as applicable):

Note: Equivalent alternatives should not be automatically generated from unreliable sources (e.g., file names should not be used as text alternatives).

Guideline B.2.5 Assist authors with accessible templates and other pre-authored content. [Techniques]

Rationale: As with automatically-generated content (see Guideline B.1.3), templates and other pre-authored content (e.g., clip art, synchronized media, graphical widgets, etc.) that are not accessible, impose additional repair tasks on authors. @@Several RS concerns@@

Level A Success Criteria for Guideline B.2.5
  • B.2.5.1 Templates "A" Accessible: If the authoring tool automatically selects templates or pre-authored content, then the selection meets the level "A" Web content accessibility benchmarks when used.
  • B.2.5.2 Provide Accessible Templates: If the authoring tool provides templates, then there are accessible template options for the full range of template uses.
  • B.2.5.3 Template Selection Mechanism: If authors are provided with a template selection mechanism, then both of the following are true:
    • (a) Indicate: the selection mechanism indicates the accessibility status of templates,
    • (b) Prominence: any accessible template options have prominence that is comparable with that of other options in the selection mechanism.
  • B.2.5.4 New Templates: If authors can use the authoring tool to create new templates for use by a template selection mechanism, they can record the accessibility status of the new templates.
  • B.2.5.5 Templates in Repository: If the authoring tool provides a repository of templates, then each of the templates has a recorded accessibility status.
Level AA Success Criteria for Guideline B.2.5
  • B.2.5.6 Templates "AA" Accessible: If the authoring tool automatically selects templates or pre-authored content, then the selection meets the level "AA" Web content accessibility benchmarks when used.
  • B.2.5.7 Pre-Authored Content Selection Mechanism: If authors are provided with a selection mechanism for pre-authored content other than templates (e.g., clip art gallery, widget repository, design themes), then both of the following are true:
    • (a) Indicate: the selection mechanism indicates the accessibility status of the pre-authored content ,
    • (b) Prominence: any accessible options have prominence that is comparable with that of other options in the selection mechanism.
  • B.2.5.8 Pre-Authored Content in Repository: If the authoring tool provides a repository of pre-authored content, then each of the content objects has a recorded accessibility status.
Level AAA Success Criteria for Guideline B.2.5

Applicability Note: Templates may be complicated to check for accessibility due to their inherent incompleteness. The accessibility status of templates is instead measured by the accessibility of content created through their proper use.

PRINCIPLE B.3: Accessibility solutions must be promoted and integrated

Important Note on "Look and Feel": In addition to the normative requirements of this principle, implementers should also consider close 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:

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

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

Guideline B.3.1 Ensure that accessible authoring actions are given prominence. [Techniques]

Rationale: Some authors are most likely to use the first and easiest authoring action they encounter in the authoring tool user interface that achieves their intended mainstream rendered outcome.

Level A Success Criteria for Guideline B.3.1
Level AA Success Criteria for Guideline B.3.1
  • (No level AA success criteria for Guideline B.3.1)
Level AAA Success Criteria for Guideline B.3.1
  • B.3.1.2 Higher Prominence: If authors are provided with a choice of authoring actions to achieve the same mainstream rendered outcome, then actions that implement accessible authoring practices are more prominent than the other action(s).

Guideline B.3.2 Ensure that sequential authoring processes integrate accessible authoring practices. [Techniques]

Rationale: When accessibility considerations are a natural part of the workflow, they become a routine part of authoring.

Level A Success Criteria for Guideline B.3.2
  • (No level A success criteria for Guideline B.3.2)
Level AA Success Criteria for Guideline B.3.2
  • B.3.2.1 Sequencing Features: Function that sequences authoring actions (e.g., image insertion dialogs, templates, wizards) provide any accessibility prompts relevant to the content being edited at or before the first opportunity to successfully complete the function. @@RS concern@@
  • B.3.2.2 Sequenced Instructions: Instructions (e.g., tutorials, reference manuals, design guides) that consist of a sequence of steps for authors to follow include the relevant accessibility authoring practices in the sequence before the first opportunity to successfully complete the sequence. @@RS P1?@@
Level AAA Success Criteria for Guideline B.3.2
  • (No level AAA success criteria for Guideline B.3.2)

Guideline B.3.3 Ensure that features of the authoring tool supporting the production of accessible content are available. [Techniques]

Rationale: The accessible content support features will be more likely to be used if they are turned on and are afforded reasonable prominence within the authoring tool user interface.

Level A Success Criteria for Guideline B.3.3
  • B.3.3.1 Active by Default: All accessible content support features are active by default.
  • B.3.3.2 Reactivate Option: If authors deactivate an accessible content support feature, then they can always reactivate the feature.
Level AA Success Criteria for Guideline B.3.3
  • B.3.3.3 Deactivation Warning: If authors deactivate an accessible content support feature, then the authoring tool informs them that this may increase the risk of content accessibility problems.
  • B.3.3.4 At Least as Prominent: Accessible content support features are at least as prominent as any corresponding features related to other types of Web content problems (e.g., invalid markup, syntax errors, spelling and grammar errors).
Level AAA Success Criteria for Guideline B.3.3
  • (No level AAA success criteria for Guideline B.3.3)

Guideline B.3.4 Ensure that features of the authoring tool supporting the production of accessible content are documented. [Techniques]

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

Level A Success Criteria for Guideline B.3.4
Level AA Success Criteria for Guideline B.3.4
  • (No level AA success criteria for Guideline B.3.4)
Level AAA Success Criteria for Guideline B.3.4
  • B.3.4.2 Accessible Authoring Tutorial: A tutorial on the accessible authoring process that is specific to the authoring tool is provided.

Guideline B.3.5 Ensure that any authoring practices demonstrated in documentation are accessible. [Techniques]

Rationale: Demonstrating accessible authoring as routine practice will encourage its acceptance by some authors.

Level A Success Criteria for Guideline B.3.5
  • (No level A success criteria for Guideline B.3.5)
Level AA Success Criteria for Guideline B.3.5
Level AAA Success Criteria for Guideline B.3.5
  • B.3.5.2 Model "AA" Accessible Practice: Any examples of authoring practices in documentation demonstrate level "AA" accessible authoring practices.

Applicability Note: An exception to these success criteria is allowed for examples that are specifically intended to demonstrate inaccessible practices to be avoided.


Conformance

This section is normative.

Conformance means that the authoring tool satisfies the success criteria defined in the guidelines section. This conformance section describes conformance, lists the conformance requirements, and explains the important role of accessibility "benchmark" documents.

Web Content Accessibility "Benchmark" Document

The purpose of the Web Content Accessibility "Benchmark" document is to precisely specify the evaluator's interpretation of what "accessible Web content" means with respect to the particular Web content technology or technologies 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 features that must interoperate, such as accessibility prompting, evaluation, and repair features. In addition, because the Benchmark document must be made public, it allows claims to be more fully checked for accuracy.

What does a Web Content Accessibility Benchmark document include?

A Benchmark document must be published on a public website (the URI will appear in the conformance claim) under a license that permits it to be copied (so that it can be included in other conformance claims), although not necessarily modified. The Benchmark document must include:

  1. The name and version of the Web content technology or technologies covered by the Benchmark document (e.g., "HTML 4.01" or "SVG 1.0 and PNG images") and optionally the URI of the specification(s). The version may be a defined range.
  2. The version and URI of the Web content accessibility standard that is being used as a basis for the Benchmark document (e.g., "WCAG 2.0 Working Draft, http://www.w3.org/TR/WCAG20/") (See Note on other Accessibility Standards).
  3. The target level of the Benchmark. This is the level that would be met by Web content that implements all of the benchmarks in the Benchmark document. There are three (3) possible levels:
  4. Any assumptions about user agents available to authors or end users (related to the "user agent supported" concept in WCAG 2.0).
  5. The benchmarks: For each normative requirement of the accessibility standard at the target level, one of the following must be provided:
    • at least one benchmark technique for meeting the normative requirement using the Web content technology or technologies (e.g., HTML 4.01 benchmark techniques for each WCAG 2.0 Level A success criteria), or
    • an explanation of why that normative requirement is not applicable to the Web content technology or technologies in question (e.g., for a text-only format, normative requirements related to images would be considered not applicable)

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.

Is a Web Content Accessibility Benchmark document normative?

A Web Content Accessibility Benchmark document may be based on informative documents, such as WCAG Techniques, and should not therefore be considered "normative". Instead, the document serves as a "relied upon" reference for a particular conformance claim when it is included in that claim. The reference 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.

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 Web content technologies, 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 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 ATAG 2.0 version, publishing date and status (e.g., "Authoring Tool Accessibility Guidelines 2.0, 27 April 2007, Editor's Draft ")
  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 be a range (e.g., "this claim refers to version 6.x").
    • If the authoring tool is a collection of software components (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 "benchmarked" Web content technologies produced by the authoring tool. These are the only technologies covered by the conformance claim.
      • The list must include at least one Web content technology for the conformance claim to be valid.
      • When Web content technologies are typically produced together (e.g., HTML 4.01 and JavaScript), they can be listed separately or together in the list.
      • Each Web content technology must include a Web content accessibility benchmark document.
    • (c) A list of any other Web content technologies 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) used to evaluate Web-Based user interface functionality, 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 non-user agent platforms, 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.

Optional Components of an ATAG 2.0 Conformance Claim

  1. A description of the authoring tool that identifies the types of editing views that it includes.
  2. A description of how the normative ATAG 2.0 success criteria were met where this may not be obvious.

"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.

Disclaimer

Neither W3C, WAI, nor WAI-AUWG take any responsibility for any aspect or result of any ATAG 2.0 conformance claim or Web Content Accessibility Benchmark document that has not been published under the authority of the W3C, WAI, or WAI-AUWG.


Appendix A: Glossary

This section is normative.

abbreviation [WCAG 2.0]
Shortened form of a word, phrase, or name where the abbreviation has not become part of the language. Includes:
  1. initialism: shortened forms of a name or phrase made from the initial letters of words or syllables contained in that name or phrase (e.g., ESP is an initialism for extrasensory perception).
  2. acronym: abbreviated forms made from the initial letters or parts of other words (in a name or phrase) which may be pronounced as a word (e.g., WAI is an acronym made from the initial letters of the Web Accessibility Initiative).
accessibility platform architecture
A programmatic interface that is specifically engineered to enhance communication between mainstream software applications and assistive technologies (e.g., MSAA and IAccessible2 for Windows applications, Gnome Accessibility Toolkit API for Gnome applications, Java Access for Java applications). On some platforms it may be conventional to enhance communication further via implementing a DOM.
accessibility problem
ATAG 2.0 refers to two types of accessibility problems:
  1. authoring tool user interface accessibility problem: An aspect of an authoring tool user interface that does not to meet one of the guideline success criteria in Part A of this document. The severity of a given problem is reflected in the level of the failed success criteria.
  2. Web content accessibility problem: An aspect of Web content that does not meet some accessibility requirement. The severity of a given problem is relative and is determined by the accessibility standard referenced by the Web content accessibility benchmark.
accessibility information
Any information that is necessary for undertaking an accessible authoring practice (e.g., equivalent alternatives, role and state information, relationships within complex tables).
accessible content support features
Any features of an authoring tool that directly support authors in increasing the accessibility of the content being authored. Specifically, this will include any functionality that is used to meet the success criteria for B.2.1, B.2.2, B.2.3, B.2.4, and B.2.5.
ASCII art [WCAG 2.0]
Picture created by a spatial arrangement of characters or glyphs (typically from the 95 printable characters defined by ASCII).
assistive technology [WCAG 2.0, UAAG 1.0]
Software and/or hardware that provides services to meet the requirements of users with disabilities that go beyond direct accessibility features offered by mainstream software applications and hardware. Such services include alternative presentations (e.g., as synthesized speech or magnified content), alternative input methods (e.g., voice), additional navigation or orientation mechanisms, and content transformations (e.g., to make tables more accessible). Examples of assistive technologies that are important in the context of this document include the following:
  • screen magnifiers, and other visual reading assistants, which are used by people with visual, perceptual and physical print disabilities to change text font, size, spacing, color, synchronization with speech, etc in order improve the visual readability of rendered text and images;
  • screen readers, which are used by people who are blind to read textual information through synthesized speech or braille;
  • text-to-speech software, which is used by some people with cognitive, language, and learning disabilities to convert text into synthetic speech;
  • voice recognition software, which may be used by people who have some physical disabilities;
  • alternative keyboards, which are used by people with certain physical disabilities to simulate the keyboard;
  • alternative pointing devices, which are used by people with certain physical disabilities to simulate mouse pointing and button activations.
Mainstream software applications and hardware may also provide services directly that meet the requirements of users with disabilities.
audio description - also called described video, video description and descriptive narration [WCAG 2.0]
An equivalent alternative that takes the form of narration added to the soundtrack to describe important visual details that cannot be understood from the main soundtrack alone. Audio description of video provides information about actions, characters, scene changes, on-screen text, and other visual content. In standard audio description, narration is added during existing pauses in dialogue. In extended audio description, the video is paused so that there is time to add additional description.
authoring action
Any action that authors take using the authoring tool user interface with the intention of editing content (e.g., typing text, deleting, inserting an element, applying a template). Most authoring tool user interfaces also enable actions that do not edit content (e.g., setting preferences for the tool, searching the help system).
authoring outcome
A characteristic of content that results from one or more authoring actions being applied. Authoring outcomes exist at different levels (e.g., making a paragraph bold vs. deploying a site-wide navigation system) and are cumulative (e.g., text is entered, styled, made into a link, given title). Mainstream rendered (authoring) outcomes are only the subset of content characteristics that are apparent to end-users of mainstream user agents (e.g., text that is bold, a seamless patchwork of images; but not commented code or table relationships). Often, multiple authoring practices exist that will result in the same mainstream rendered authoring outcome, but the outcomes may differ with respect to accessibility (e.g., styled text may appear identical to an image of text on the screen, but will appear differently in audio output).
authoring practice
A technique that guides authors or the authoring tool in selecting authoring actions to apply to content in order to achieve particular authoring outcomes. (e.g., controlling presentation with style sheets, commenting code, testing on multiple browsers). An accessible authoring practice is one that seeks to avoid or correct one or more Web content accessibility problems. Accessible authoring practices sometimes require accessibility information.
authoring session
A state of the authoring tool during which content can be edited by the author. The end of an authoring session is the point in time at which a session ends and the author has no further opportunity to make changes without starting another session. This may be under the control of the author (e.g., closing a document, publishing) or it may be controlled by the authoring tool (e.g., when the authoring tool transfers editing permission to another author on a collaborative system).
authoring tool user interface (non-Web-based)
Any components of an authoring tool user interface that is not implemented as Web content and instead runs directly on a non-user agent platform such as Windows, MacOS, Java Virtual Machine, etc.
authoring tool user interface (Web-based)
Any components of an authoring tool user interface, including editing views, documentation, etc., that is implemented using Web content technologies and is rendered by a user agent. Since Web-based tools may be implemented in the same Web content technologies that they are used to edit, the distinction between the tool's content display and its user interface "chrome" may be less clear than with non-Web-based tools.
authoring tool user interface
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 or a combination (e.g., a stand-alone markup editor with on-line help pages). Authoring tool user interfaces can be considered in two parts: @@RS concern@@
  1. "chrome": Any parts of the user interface that do not represent the content being edited. This includes:
    • user interface elements that surround, underlie, or super-impose upon editing views (e.g., text areas, menus bars, rulers, pop-up context menus)
    • user interface elements that are separate from the editing view (e.g. documentation)
  2. content display: Any parts of a view that represent the content being edited. This includes:
An accessible authoring tool user interface is one that meets the success criteria in Part A (i.e., does not include any authoring tool user interface accessibility problems). The level of accessibility is determined by the levels of the satisfied success criteria.
authoring tool
ATAG 2.0 defines an "authoring tool" as any software, or collection of software components, that authors can use to create or modify Web content for use by other people. Also see "Definition of authoring tool" section.
authors
The users of authoring tools. This may include content authors, designers, programmers, publishers, testers, etc. working either alone or collaboratively.
benchmarked Web content technologies
See "Web Content Accessibility Benchmark Document".
blink [WCAG 2.0]
Switch back and forth between two visual states in a way that is meant to draw attention. It is possible for something to be large enough and blink brightly enough at the right frequency to be also classified as a flash.
captions [WCAG 2.0]
An equivalent alternative that takes the form of text presented and synchronized with synchronized media to provide not only the speech, but also non-speech information conveyed through sound, including meaningful sound effects and identification of speakers. In some countries, the term "subtitle" is used to refer to dialogue only and "captions" is used as the term for dialogue plus sounds and speaker identification. In other countries, "subtitle" (or its translation) is used to refer to both.
change of context [WCAG 2.0]
Change of view or focus. Content that changes the function or meaning of an interface. A change of content is not always a change of context. Small changes in content, such as an expanding outline or dynamic menu, do not change the context.
checking (accessibility) - also called accessibility evaluation [EARL 1.0]
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 of the tests:
  1. manual checking: where the tests are carried out by authors. This includes the case where the authors are aided by instructions or guidance provided by the authoring tool, but where authors must carry out the actual test procedure;
  2. semi-automated checking: where the tests are partially carried out by the authoring tool, but where authors' input or judgment is still required to decide or help decide the outcome of the tests; and
  3. automated checking: where the tests are carried out automatically by the authoring tool without any intervention by the authors.
An authoring tool may support any combination of checking types.
collection of software components
Any software programs that are used either 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 programs.
content generation
ATAG 2.0 refers to two broad categories of content generation:
  1. author-generated content: When authors specify content (e.g., typing markup into a text editor, choosing an element by name from a list, entering information into a dialog box).
  2. automatically-generated content: When the authoring tool specifies content (e.g., applying a template, automatically correcting markup errors, dynamically generated content).
content (Web) - or shortened to content [WCAG 2.0]
Information and sensory experience to be communicated to the user by means of a user agent, including code or markup that defines the content's structure, presentation, and interactions. In ATAG 2.0, "content" is primarily used in the context of the output that is produced by the authoring tool. This includes Web applications, including those that, in turn, act as Web-based authoring tools. Accessible Web content is Web content that does not contain accessibility problems. Usually this refers to a particular level of accessibility (e.g., Web content that meets Level "A" Web content accessibility). Accessible Web content is shorthand for content that meets a given set of accessibility criteria. This does not not necessarily mean that it will be accessible to every person with a disability.
conversion
A process that takes as input, content in one Web content technology (or non-Web content technology, such as a word processing format) and produces as output, content in a different Web content technology (e.g., "Save as HTML" functions).
direct accessibility
Features of mainstream software applications and hardware that augment accessibility by people with disabilities (e.g., keyboard navigation, zoom functions, text-to-speech).
display settings
ATAG 2.0 refers to two types of display settings:
  1. display settings (audio): the characteristics of audio output of music, sounds and speech and include volume, speech voices, voice speed, and voice emphasis.
  2. display settings (visual): the characteristics of the on-screen rendering of text and graphics and include fonts, sizes, colors, spacing, positioning, and contrast.
documentation
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.
element
A pair of tags and their content, or an "empty" tag - one that requires no closing tag or content (used in the same sense as in HTML and XML)
end user
A person who interacts with Web content once it has been authored.
equivalent alternative
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:
  1. text alternative [WCAG 2.0]: text that is available via the platform that is used in place of non-text content.
  2. full text alternative for synchronized media including any interaction [WCAG 2.0]: document including correctly sequenced text descriptions of all visual settings, actions, speakers, and non-speech sounds, and transcript of all dialogue combined with a means of achieving any outcomes that are achieved using interaction (if any) during the synchronized media.
  3. synchronized alternatives: present essential audio information visually (i.e., captions) and essential video information in an auditory manner (i.e., audio descriptions).
flash [WCAG 2.0]
A pair of opposing changes in relative luminance that can cause seizures in some people if it is large enough and in the right frequency range. See general flash threshold and red flash threshold for information about types of flash that are not allowed. See also blink.
general flash and red flash thresholds [WCAG 2.0]
A sequence of flashes or rapidly changing image sequences where all three of the following occur:
  1. there are more than three flashes within any one-second period,
  2. the flashing is below 50 Hz, and
  3. the combined area of flashes occurring concurrently and contiguously occupies more than a total of .006 steradians (25% of any 10 degree visual field on the screen).
Notes: For the general flash threshold, a flash is defined as a pair of opposing changes in relative luminance of 10% or more and the relative luminance of the darker image is below 0.80. An "opposing change" is an increase followed by a decrease, or a decrease followed by an increase. For the red flash threshold, a flash is defined as any transition to or from a saturated red. For general Web content, using a 341 x 256 pixel rectangle anywhere on the displayed screen area when the content is viewed at 1024 x 768 pixels will provide a good estimate of a 10 degree visual field for standard screen sizes and viewing distances.
human language
Language that is spoken, written or signed (through visual or tactile means ) to communicate with humans.
inform
To provide authors with information via the authoring tool user interface. Informing mechanisms range from unobtrusive (i.e., information presented without stopping the authors' current activity) to intrusive (i.e., interrupting the author's current activity). Information may be provided as part of a prompt.
informative [WCAG 2.0]
For information purposes and not required for conformance.
label [WCAG 2.0]
Text or other component with a text alternative that is presented to authors to identify a component. A label is presented to all authors whereas the name may be hidden and only exposed by assistive technology. In many (but not all) cases the name and the label are the same.
mainstream applications and hardware - also called mainstream technology
Software applications and hardware for which augmenting accessibility is secondary to some other purpose (as opposed to assistive technology where it is the primary purpose). Mainstream technologies may include direct accessibility features.
markup
A set of tags from a markup language. 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). A markup language is a syntax and/or set of rules to manage markup (e.g., HTML, SVG, MathML).
name [WCAG 2.0]
Text by which software can identify a component to the user. The name may be hidden and only exposed by assistive technology, whereas a label is presented to all users. In many (but not all) cases, the label and the name are the same.
non-text content [WCAG 2.0]
Any content that is not a sequence of characters that can be made available via the platform or where the sequence is not expressing something in human language. This includes ASCII Art (which is a pattern of characters), emoticons, leetspeak (which is character substitution), and images representing text.
normative [WCAG 2.0, UAAG 2.0]
Required for conformance. One may conform in a variety of well-defined ways to this document. Content identified as "informative" or "non-normative" is never required for conformance.
platform
The software environment within which the authoring tool operates. For non-Web-based authoring user interface functionality 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 authoring user interface functionality, "platform" 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. Available via the platform: For non-Web-based authoring user interface functionality this means via an implemented accessibility platform architecture. For Web-based authoring user interface functionality this means following relevant Web content accessibility design guidelines so that the user agent can pass on the information.
plug-in [UAAG 2.0]
A program that runs as part of the authoring tool (e.g., a third-party evaluation and repair tool) and that is not part of content being edited. Authors generally choose to include or exclude plug-ins from their authoring tool.
presentation [WCAG 2.0]
Rendering of the content in a form to be perceived by authors.
prominence
A heuristic measure of the degree to which authors are likely to notice components in the authoring tool user interface 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 component include:
  1. component size (large items or items surrounded by extra white space may appear to be conferred higher importance),
  2. components 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),
  3. components grouping (grouping items together can change the reading order and the related judgments of importance),
  4. 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
  5. highlighting (items may be distinguished from others using icons, color, styling).
prompt [UAAG 2.0]
Any authoring tool initiated request for a decision or piece of information from authors. Well designed prompting will urge, suggest, and encourage authors.
publishing
Making Web content available to end users (e.g., uploading a Web page, committing a change in a wiki).
relationships [WCAG 2.0]
Meaningful associations between distinct pieces of content.
relative luminance [WCAG 2.0]
The relative perceived brightness of any point, normalized to 0 for darkest black and 1 for lightest white.
Note 1: The relative luminance of an sRGB color is defined as L = 0.2126 * R + 0.7152 * G + 0.0722 * B where R, G and B are defined as:
  • if RsRGB <= 0.03928 then R = RsRGB/12.92 else R = ((RsRGB+0.055)/1.055) ^ 2.4
  • GsRGB <= 0.03928 then G = GsRGB/12.92 else G = ((GsRGB+0.055)/1.055) ^ 2.4
  • if BsRGB <= 0.03928 then B = BsRGB/12.92 else B = ((BsRGB+0.055)/1.055) ^ 2.4
and RsRGB, GsRGB, and BsRGB are defined as:
  • RsRGB = R8bit/255
  • GsRGB = G8bit/255
  • BsRGB = B8bit/255
The "^" character is the exponentiation operator. (Formula taken from [sRGB] and [IEC-4WD]).
Note 2: Almost all systems used today to view Web content assume sRGB encoding. Unless it is known that another color space will be used to process and display the content, authors should evaluate using sRGB colorspace.
Note 3: For dithered colors, use average values of the colors used (average R, average G, and average B).
Note 4: Tools are available that automatically do the calculations when testing contrast and flash.
repairing (accessibility) [EARL 1.0]
The process by which Web content accessibility problems that have been identified within content are resolved. ATAG 2.0 identifies three types of repairing, based on increasing levels of automation:
  1. manual: where the repairs are carried out by authors. This includes the case where the authors are aided by instructions or guidance provided by the authoring tool, but where authors carry out the actual repair procedure;
  2. semi-automated: where the repairs are partially carried out by the authoring tool, but where authors' input or judgment is still required to complete the repair; and
  3. automated: where the repairs are carried out automatically by the authoring tool without any intervention by the authors.
reversible actions
Authoring actions 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 include certain save and delete actions as well as actions made in a collaborative environment that another author has begun to work with.
role [WCAG 2.0]
Text or a number by which software can identify the function of a component within Web content (e.g., a number that indicates whether an image functions as a hyperlink, command button, or check box).
structured element set
Content that consists of organized elements (e.g., lists, maps, hierarchies, graphs).
synchronized media [WCAG 2.0]
Audio or video synchronized with another format for presenting information and/or with time-based interactive components.
technology (Web content) - or shortened to technology [WCAG 2.0, UAAG 2.0]
A mechanism for encoding instructions to be rendered, played or executed by user agents. Web Content technologies may include markup languages, data formats, or programming languages that authors may use alone or in combination to create end-user experiences that range from static Web pages to multimedia presentations to dynamic Web applications. Some common examples of Web content technologies include HTML, CSS, SVG, PNG, PDF, Flash, and JavaScript. A benchmarked Web content technology is one that is listed in the ATAG 2.0 conformance profile and accompanied by a Web Content Accessibility Benchmark document. The level of accessibility listed in the benchmark document should also be referenced (e.g., level "AA" benchmarked technology).
template
A content pattern that is filled in by authors or the authoring tool to produce content for end users (e.g., document templates, content management templates, presentation themes). Often templates will pre-specify at least some authoring decisions.
template selection mechanism
A function that allows authors to select templates to use as the basis for new content or to apply to existing content.
transformation
A process that takes content in one Web content technology as input and outputs different content in the same technology (e.g., a function that transforms tables into lists).
tutorial
A type of documentation that involves the sequential presentation of instructions for performing multi-part tasks.
user agent [WCAG 2.0, UAAG 2.0]
Any software that retrieves and presents Web content for end users. Examples include Web browsers, media players, plug-ins, and other programs including assistive technologies, that help in retrieving, rendering and interacting with Web content.
user interface component [WCAG 2.0]
A part of the user interface "chrome" or content display (including renderings) that is perceived by authors as a single control for a distinct function. In ATAG 2.0, the term is used to denote any part of the user interface of the authoring tool involved with display or control.
video [WCAG 2.0]
The technology of moving pictures or images. Video can be made up of animated or photographic images, or both.
view
User interface functionality that authors use to interact with the content being edited. Authoring tools often have two types of views:
  1. editing view: Views that both present the content being edited to authors and allow authors to make modifications to the content. There are several broad approaches to presenting content for editing, which may be combined:
    • (a) instruction level: Authors work with non-rendered instructions for the content being edited (e.g., HTML markup). Examples include plain text editing views as well as form-based editing views that provide direct access to the instructions (e.g., selecting attribute values).
    • (b) content rendering: Authors work with content that is fully or partially rendered, played, or executed. Partial renderings occur when only some aspects of the content are rendered, played, or executed. For example, a frame-by-frame video editor may render the graphical aspects, but not the temporal aspect of a video. Some renderings are WYSIWYG because they closely resemble the appearance and behavior that a user agent would produce (e.g., an HTML editor that displays rich text, images, tables, etc.), while others are non-WYSIWYG because they differ from those produced by user agents (e.g., a graphical wavefront editing view of an audio file).
    • (c) meta-content: Authors work with higher-level or abstract information that the authoring tool interprets to generate the resulting content. For example, a content management system that allows authors very limited control (e.g., toggling on/off, setting colors) over it's built-in content modules (e.g. stock ticker, calendar).
  2. preview: A non-editable view in which the content being edited is rendered, played, or executed as it would in a user agent.
workflow
A customary sequence of steps or tasks authors follow to produce a deliverable.

Appendix B: How to refer to ATAG 2.0 from other documents

This section is informative.

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/2007/@@@@.
  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/2008/@@@@/.

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/2007/@@@@/">
"Authoring Tool Accessibility Guidelines 2.0,"</a></cite>
J. Treviranus, J. Richards, eds.,
W3C Recommendation, @@@@.
The <a href="http://www.w3.org/TR/2008/@@@@/">latest version</a> of this document is available at http://www.w3.org/TR/2008/@@@@/.</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.


Appendix C: References

This section is informative.

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 "[WCAG20]" link to the corresponding entries in this section. These labels are also identified as references through markup.

[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/.
[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.
 
[IEC-4WD]
IEC/4WD 61966-2-1: Colour Measurement and Management in Multimedia Systems and Equipment - Part 2.1: Default Colour Space - sRGB. May 5, 1998.
[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.
[sRGB]
"A Standard Default Color Space for the Internet - sRGB," M. Stokes, M. Anderson, S. Chandrasekar, R. Motta, eds., Version 1.10, November 5, 1996. A copy of this paper is available at http://www.w3.org/Graphics/Color/sRGB.html.
[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.
[UAAG]
"User Agent Accessibility Guidelines 1.0," I. Jacobs, J. Gunderson, E. Hansen, eds.17 December 2002. This W3C Recommendation is available at http://www.w3.org/TR/2002/REC-UAAG10-20021217/.
[WCAG10]
"Web Content Accessibility Guidelines 1.0", W. Chisholm, G. Vanderheiden, and I. Jacobs, eds., 5 May 1999. This WCAG 1.0 Recommendation is available at http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/.
[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]
"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.
[WCAG20-TECHS]
"Techniques for WCAG 2.0," B. Caldwell, M. Cooper, L. Guarino Reid, G. Vanderheiden, eds. Note: This document is still a working draft.
[WCAG20-UNDERSTANDING]
"Understanding (WCAG 2.0)," B. Caldwell, M. Cooper, L. Guarino Reid, 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 D: Acknowledgments

Appendix Editors:

Participants active in the AUWG at the time of publication:

Other previously active AUWG participants and other contributors to ATAG 2.0:

Kynn Bartlett, Giorgio Brajnik, Judy Brewer, Wendy Chisholm, Daniel Dardailler, Geoff Deering, Barry A. Feigenbaum, Katie Haritos-Shea, Kip Harris, Phill Jenkins, Len Kasday, Marjolein Katsma, William Loughborough, Karen Mardahl, 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 E: Checklist


Appendix F: Comparison of ATAG 1.0 guidelines to ATAG 2.0


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


[Contents] [Techniques] [Checklist]