W3C

Authoring Tool Accessibility Guidelines 2.0

Editor's Draft 5 October 2005

This version:
http://www.w3.org/WAI/AU/2005/WD-ATAG20-20051005/WD-ATAG20-20051005.html
Latest version:
http://www.w3.org/TR/ATAG20/
Previous version:
http://www.w3.org/TR/2004/WD-ATAG20-20041122/
Editors:
Jutta Treviranus - ATRC, University of Toronto
Charles McCathieNevile
Jan Richards - University of Toronto
Matt May - W3C

Abstract

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

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

Status of this document

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

This is a W3C Working Draft of a specification which will supersede the W3C Recommendation "Authoring Tool Accessibility Guidelines 1.0" [ATAG10]. It follows a W3C Last Call Working Draft.

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

The AUWG also plans to provide additional resources to support this document such as Frequently Asked Questions (FAQ) about ATAG 2.0, issues, implementation reports, and test suites. Please consult the AUWG home page for more information.

This document was produced under the 24 January 2002 CPP as amended by the W3C Patent Policy Transition Procedure. Patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page in conformance with W3C policy. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification should disclose the information in accordance with section 6 of the W3C Patent Policy.

This draft refers non-normatively to the Techniques for Authoring Tool Accessibility Guidelines 2.0 [ATAG20-TECHS].

This draft refers normatively to ATAG 2.0 References to various versions of the Web Content Accessibility Guidelines (WCAG). This is explained in Section 1.5.

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

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

Please note that this document may contain areas that still under discussion by the working group. These are generally marked by "@@".

Please send comments about this document to the public mailing list: w3c-wai-au@w3.org (public archives).

Table of contents


1. Introduction

This document specifies requirements that, if satisfied by authoring tool developers, will lower barriers to accessibility. This document includes the following:

1.1 Scope

These guidelines cover a wide range of recommendations for assisting authoring tool software developers in making authoring tools, as well as the content that the authoring tools generate, more accessible to all potential Web content users and authors, especially people with disabilities .

These guidelines have been written to address the requirements of many different audiences, including, but not limited to: policy makers, technical administrators, and those who develop/manage content. Every attempt has been made to make this document as readable and usable as possible while still retaining the accuracy and clarity needed in a technical specification.

1.2 Definition of authoring tool

@@[PROPOSED] ATAG 2.0 defines an "authoring tool" as: any software, or collection of software components, that authors use to create or modify Web content for publication. A collection of software components are any software products used together (e.g. base tool and plug-in) or separately (e.g. markup editor, image editor, and validation tool), regardless of whether there has been any formal collaboration between the developers of the products. @@

@@to be removed: ATAG 2.0 defines an "authoring tool" as: any software or service that authors may use to create or modify Web content for publication.@@

To illustrate the range of this term as it is used in these guidelines, an authoring function categorization scheme has been developed. The scheme is used primarily within the Techniques document [ATAG20-TECHS] to call out examples that may be of interest to developers of particular types of tools. It is important to note that many authoring tools will include authoring functions that fall into one or more of the categories (e.g. many HTML editors have both code-level and WYSIWYG authoring functions):

Code-level Authoring Functions: Authors have full control over all aspects of the resulting Web content that have bearing on the final outcome. This covers, but is not limited to plain text editing, as this category also covers the manipulation of symbolic representations that are sufficiently fine-grained to allow the author the same freedom of control as plain text editing (e.g. graphical tag placeholders).
Examples: text editors, text editors enhanced with graphical tags, etc.

WYSIWYG ("What-you-see-is-what-you-get") Authoring Functions: Authors have control over entities that closely resemble the final appearance and behavior of the resulting Web content.
Examples: rendered document editors, bitmap graphics editors, etc.

Object Oriented Authoring Functions: Authors have control over functional abstractions of the low level aspects of the resulting Web content.
Examples: timelines, waveforms, vector-based graphic editors, objects which represent web implementations for graphical widgets (menus, etc.) etc.

Indirect Authoring Functions: Authors have control over only high-level parameters related to the automated production of the resulting Web content. This may include interfaces that assist the author to create and organize Web content without the author having control over the markup, structure, or programming implementation.
Examples: content management systems, site building wizards, site management tools, courseware, weblogging tools, content aggregators, conversion tools, model-based authoring tools, etc.

1.3 Role of authoring tools in Web accessibility

The guiding principle of ATAG 2.0 is that:

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

Authoring tools play a crucial role in achieving this principle because the design of the tool's authoring tool user interface determines who can access the tool as a Web content author and the accessibility of the resulting Web content determines who can be an end-user of that Web content.

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

For more information, see "How People with Disabilities Use the Web" [PWD-USE-WEB].

Designing authoring tools for accessibility will have benefits for authors and end-users beyond those listed in these various disability-related contexts. For example, a person may have average hearing, but still require an equivalent alternative for audio information due to a noisy workplace. Similarly, a person working in an eyes-busy environment may require an audio alternative to information they cannot view.

1.4 How the guidelines are organized

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

Each checkpoint listed under a guideline is intended to be sufficiently specific to be verifiable, while being sufficiently general to allow developers the freedom to use the most appropriate strategies to satisfy it. Each checkpoint definition includes the following parts. Some parts are normative (i.e., relate to conformance); others are informative only:

1.5 Relationship with other guidelines and standards

ATAG 2.0 is part of a series of accessibility guidelines published by the Web Accessibility Initiative (WAI). The documents in this series reflect an accessibility model in which format designers, Web content authors, and software developers have roles in ensuring that users with disabilities have access to the Web. The accessibility-related interests of these stakeholders intersect and complement each other as follows:

1.5.1 Relationship to "Web Content Accessibility Guidelines (WCAG)"

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

At the time of publication, version 1.0 of WCAG is a W3C Recommendation [WCAG10], and a second version of the guidelines is under development [WCAG20]. @@revisit this@@

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


2. Conformance

2.1 Conformance Scheme

ATAG 2.0 allows authoring tools to claim conformance to one of three conformance levels. The level achieved depends on the priority of the checkpoints that the authoring tool has satisfied.

2.1.1 Conformance Levels

Level "A"
The authoring tool has satisfied all Priority 1 "regular priority" checkpoints and has also satisfied all of the "relative priority" checkpoints to at least Level 1.
Level "Double-A"
The authoring tool has satisfied all Priority 1 and Priority 2 "regular priority" checkpoints and has also satisfied all of the "relative priority checkpoints" to at least Level 2.
Level "Triple-A"
The authoring tool has satisfied all Priority 1, Priority 2, and Priority 3 "regular priority" checkpoints and has also satisfied all of the "relative priority checkpoints" to at least Level 3.
Figure 1: A graphical view of the requirements of the ATAG 2.0 Conformance Levels (described above).
A graphic that illustrates the levels of conformance as they are explained in the text above.
Description: A graphic that illustrates the levels of conformance as they are explained in the text of the conformance level section. The graphic is a table with four rows and three columns. The header row labels are "Ladder of ATAG 2.0 Conformance Levels", "Regular Priority Checkpoints" and "Relative Priority Checkpoints". The data rows are labeled "Level 'Triple-A' (highest) ", "Level 'Double-A'", and "Level 'A' (lowest) ". Bars superimposed across the rows demonstrate that in order to meet each higher level, additional regular priority checkpoints must be met as well as increasing levels of relative priority checkpoints.

2.1.2 Checkpoint Priorities

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

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

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

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

2.2 Claiming Conformance:

A conformance claim (with or without an accompanying ATAG 2.0 conformance icon) is an assertion by a claimant that an authoring tool has satisfied the requirements of a chosen ATAG 2.0 conformance profile. The claim must be supported by a listing of conformance details.

2.2.1 Conditions

2.2.2 Conformance Claims @@NEW@@

  1. Required: The date of the conformance claim.
  2. Required: Information about the authoring tool. If the authoring tool is comprised of components (e.g. markup editor, image editor, and validation tool), information should be provided separately for each component:
    • Name and version information for the component. Version information must be sufficient to identify the tool (e.g., vendor name, version number, minor release number, required patches or updates, natural language of the user interface or documentation). The version information may refer to a range of tools (e.g., "this claim refers to version 6.x").
  3. Optional: A description of the authoring tool that identifies the types of authoring tool functions that are present in the tool. Choose one or more of: (a) Code-level authoring functions, (b) WYSIWYG ("What-you-see-is-what-you-get") authoring functions, (c) object oriented authoring functions, and (d) indirect authoring functions.
  4. Required: A Conformance Profile.
  5. Required: A description of how the authoring tool meets each of the normative success criteria for each of the checkpoints that are required for the conformance level that has been specified by the conformance profile.
    • For relative priority checkpoints this means describing how the requirements of the Technology-Specific WCAG Benchmark are satisfied.

2.2.3 Conformance Profiles

An authoring tool conforms to this document by satisfying the requirements identified by a conformance profile. A conformance profile includes the following assertions:

  1. The version and URI of the Authoring Tool Accessibility Guidelines 2.0 document that was used for the evaluation.
  2. The ATAG conformance level satisfied (choose one of: "A", "Double-A", or "Triple-A")
  3. The version and URI of the Web Content Accessibility Guidelines document that is the basis for any of the content type-specific WCAG benchmarks used for this evaluation. ( e.g. "Web Content Accessibility Guidelines 2.0 Working Draft, http://www.w3.org/TR/WCAG20/")
  4. The technologies produced by the authoring tool that are covered by the evaluation. For each technology included, the URI of a technology-specific WCAG benchmark document must be provided. (e.g. "HTML4.01, http://www.sample.org/html401_wcag20_benchmark.html")
  5. for authoring tools with Web-based user interface components: The version and URI of the Web Content Accessibility Guidelines document that the user interface was evaluated against ( e.g. "Web Content Accessibility Guidelines 2.0 Working Draft, http://www.w3.org/TR/WCAG20/").
  6. for authoring tools with Web-based user interface components: The name and version number of the user agent(s) on which the components were evaluated for conformance.
  7. for authoring tools with user interface components that are not Web-based: The name and version number of the operating system platform(s) on which the authoring tool was evaluated for conformance.
  8. for authoring tools with preview features: The name and version number of the user agent(s) which the preview feature is intended to emulate (or comes closest to emulating).

2.2.4 Content Type-Specific WCAG Benchmark

ATAG 2.0 requires Content Type-Specific WCAG Benchmark documents to be specified in the conformance profile for each content type covered by the conformance claim. Each benchmark document must meet the following conditions:

  1. a benchmark document must specify the version of WCAG used.
  2. a benchmark document can specify one or more content types used together (e.g. plain HTML or HTML + CSS or SVG + PNG images, etc.)
  3. the benchmark document becomes normative for a particular evaluation by the act of the evaluator including a reference to the benchmark URI in the ATAG 2.0 conformance profile.
  4. the benchmark document can be created by any person or organization (although the AUWG does suggest checking to see if a benchmark document has already been published by the W3C or other provider, before creating a new one).
  5. the benchmark document specifies a target WCAG conformance level (e.g. single-"A", double-"A", or triple-"A") that the creator of the benchmark is claiming the Web content would conform with if all of the benchmark requirements are met. If the tool allows the author to choose between different WCAG levels, then each level needs its own benchmark document.
  6. for each success criteria in WCAG that is required by the target WCAG conformance level set in (5), the benchmark document must provide either at least one requirement for meeting the success criteria or an explanation of why that success criteria is not applicable to the content type in question. The AUWG suggests the following documents are relevant when creating a benchmark: WCAG guidelines, "WCAG General techniques" document, "WCAG technology-specific techniques" document (if one exists for the technology in question). @@[also: Wendy C. say WCAG-GL might create a doc on how to write WCAG Techniques, which would also be relevant here]@@
  7. the benchmark document must be publicly published (the URI will appear in the conformance profile) where it will be open to public and market scrutiny.

2.2.5 Conformance Icons

There are currently no conformance icons available for this draft specification. If it becomes a Recommendation, it is expected that there will be conformance icons like those available for ATAG 1.0.


3. The Authoring Tool Accessibility Guidelines

PART A: Make the user interface accessible

Note: The requirement in this section apply to all parts of the authoring tool interface except for the content view of built-in preview features (see checkpoint A.2.9 for more information).

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

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

Note: For non-Web-based authoring tools, this is a relatively straightforward requirement, likely covering only a few areas of the interface (i.e. Web-based help features, etc.). However, for most Web-based authoring tools the requirement will cover the majority of functionality in the tool and overlap most of the other requirements in Part A of the guidelines.

Techniques: Implementation Techniques for Checkpoint A.0.1

Success Criteria:

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

GUIDELINE A.1 Authoring Interface must be Perceivable:

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

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

Note: For all Web-based interface components, meeting checkpoint A.0.1 will serve to meet this checkpoint.

Techniques: Implementation Techniques for Checkpoint A.1.1

Success Criteria:

  1. All non-text objects in the authoring tool user interface used to convey information (e.g., toolbar icon, graphical depiction of a tag, sound effect, etc.) must have a text alternative.
  2. All editing views must always include an option to display any available text alternatives for non-text objects in the content.
A.1.2 Provide synchronized alternatives for multimedia. [Priority 1]

Rationale: People who have difficulty accessing or interpreting multimedia-supported information in the authoring interface can have the information made available to them by other means. For example, people who are deaf or have a hearing loss can access auditory information through captions, and people who are blind or have low vision, as well as those with cognitive disabilities, who have difficulty interpreting visually what is happening, can receive audio descriptions of visual information.

Note: For all Web-based interface components, meeting checkpoint A.0.1 will serve to meet this checkpoint.

Techniques: Implementation Techniques for Checkpoint A.1.2

Success Criteria:

  1. All multimedia in the authoring tool user interface used to convey information (e.g., progress indicators, etc.) must have synchronized alternatives.
  2. All editing views must always include an option to display any available synchronized alternatives for multimedia in the content.
A.1.3 Ensure that all displays are configurable. [Priority 1]

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

Note 1: For all Web-based interface components, meeting checkpoint A.0.1 will serve to meet this checkpoint.

Note 2: The success criteria for this checkpoint are based on the capabilities of platforms (e.g. operating systems, browsers, GUI toolkits, etc.), however developers are free to provide additional configuration.

Techniques: Implementation Techniques for Checkpoint A.1.3

Success Criteria:

  1. If the visual display (fonts, sizes, colors, spacing, positioning, etc.) is controlled by the authoring tool rather than by the platform, then the authoring tool must provide at least the same configurable properties with at least the same configuration ranges as the platform.
  2. If the audio display (volume, speech voices, etc.) is controlled by the authoring tool rather than by the platform, then the authoring tool must provide at least the same configurable properties with at least the same configuration ranges as the platform.
  3. @@Tactile, reading level, cognitive? @@
A.1.4 Allow the display preferences for the editing view to be changed without affecting the document markup. [Priority 1].

Rationale: Authors may require a set of display preferences to view and control the document that is different from the display styles that they want to define for the published document (e.g. a particular text-background combination that differs from the published version).

Techniques: Implementation Techniques for Checkpoint A.1.4

Success Criteria:

  1. The author must be able to configure the presentation settings of editing views without affecting the Web content being edited.
ATAG Checkpoint A.1.?: Ensure that information, functionality, and structure can be separated from presentation. [Priority ?]@@this is still a proposed checkpoint@@

Rationale: Separating content and structure from presentation allows user interfaces of authoring tools to be presented differently to meet the needs and constraints of different authors without losing any of the information or structure. For example, information can be presented via speech or braille (text) that was originally intended to be presented visually. It can also facilitate automatic emphasis of structure or more efficient navigation. All of these can benefit authors with cognitive, physical, hearing, and visual disabilities.

Success Criteria:

  1. If information is conveyed by variations in the presentation of text (e.g. by the spatial location of text), then the information must also either be conveyed in text or be made available programmatically.
  2. If information is conveyed by color, then the information must also be:
    • be conveyed in text or be made available programmatically, and
    • conveyed in a way that is visually evident when color is not available (e.g. by shape)
  3. If content is structured (e.g. form controls grouped), then that structure must be made available programmatically.
  4. If the sequence of content affects its meaning, then the sequencing information must be made available programmatically.

GUIDELINE A.2: Authoring Interface must be Operable

A.2.1 Ensure that all functionality is operable via a keyboard or a keyboard interface. [Priority 1]

Rationale: Some individuals have difficulty manipulating graphical input devices such as a mouse or trackball. Providing alternate means of navigating the user interface that does not rely on such devices provides an accommodation for individuals with limited mobility or those with visual disabilities who cannot rely on hand eye coordination for navigating the user interface.

Note 1: For all Web-based interface components, meeting checkpoint A.0.1 will serve to meet this checkpoint.

Techniques: Implementation Techniques for Checkpoint A.2.1

Success Criteria:

  1. The author must be able, through keyboard input alone, to perform any authoring task (e.g. navigating, selecting, and editing content within editing views, operating the authoring tool user interface, installing and configuring the authoring tool, and accessing documentation) that is available through the user interface. (Note: an authoring task may have multiple user mechanisms, e.g. a menu item and a button bar item, at least one of which must satisfy this success criteria)
  2. There must be an option that ensures that selection is separate from activation (e.g. navigating through the items in a dropdown menu without activating any of the items).
  3. Single-key access must be provided to the following functionalities:
  4. Key-plus-modifier-key (or single-key) access must be provided to the following functionalities in the user interface (if present):
    • move content focus to the previous enabled control
    • navigate between panels or windows
    • open help system
    • open new content
    • open existing content
    • save content
    • close content
    • cut/copy/paste
    • undo/redo
    • open find/replace function
    • navigate to the start and end
A.2.2 Ensure user configurable access to selectable actions. [Priority 3]

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

Techniques: Implementation Techniques for Checkpoint A.2.2

Success Criteria:

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

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

Note 1: Some time limits may be imposed by external systems. This checkpoint only applies to time limits within the control of the authoring tool.

Note 2: For all Web-based interface components, meeting checkpoint A.0.1 will serve to meet this checkpoint.

Techniques: Implementation Techniques for Checkpoint A.2.3

Success Criteria:

  1. All user interface time limits must be author configurable unless they are controlled by time-sensitive external processes (e.g. time-outs of systems outside of the authoring tool).
  2. If a time limit is under the control of the authoring tool, it must not be less than 20 seconds and must be extendible with a single input action.
A.2.4 Allow users to avoid content that could cause seizures due to photosensitivity. [Priority 1]

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

Note: For all Web-based interface components, meeting checkpoint A.0.1 will serve to meet this checkpoint.

Techniques: Implementation Techniques for Checkpoint A.2.4

Success Criteria:

  1. Authors must be able to turn off flashing in the user interface that violates international health and safety standards for general flash or red flash.
A.2.5 Ensure that editing views enable the author to navigate the structure and perform structure-based edits. [Priority 2]

Rationale: It is often more efficient to navigate and edit via the structure in Web content.

Techniques: Implementation Techniques for Checkpoint A.2.5

Success Criteria:

  1. In any structured element set, the author must always be able to move the editing focus from any element to any other element with the following relationship (if they exist): the element immediately above (i.e. parent), the first element immediately below (i.e. child), the element immediately preceding at the same level (i.e. previous sibling), and the element immediately following at the same level (i.e. next sibling).
  2. In any structured element set, the author must always be able to select content and perform editing functions on any element along with any content, including sub-elements.
A.2.6 Allow the author to search content and markup within the editing views. [Priority 2]

Rationale: Search functions within the editing views facilitate author navigation of content as it is being authored by allowing the author to move focus quickly to arbitrary points in the content. Including the capability to search within text equivalents of rendered non-text content increases the efficiency of the search function.

Techniques: Implementation Techniques for Checkpoint A.2.6

Success Criteria:

  1. The author must be able to perform text searches of all content that is editable by the author.
  2. The author must be able to perform text searches of all markup that is editable by the author.
A.2.7 Provide an undo function. [Priority 2]

Rationale: Authors who have difficulty making fine movements may be prone to making unintended actions. All authors benefit from the ability to easily recover from mistakes.

Note: For all Web-based interface components, meeting checkpoint A.0.1 will serve to meet this checkpoint. @@discuss reliance on browser undo functions@@.

Techniques: Implementation Techniques for Checkpoint A.2.7

Success Criteria:

  1. Actions that modify content must be either reversible with an undo function or include a warning to the author that the action is irreversible.
  2. The author must be able to perform multiple undo's.
  3. The author must be able to undo any series of undo's
A.2.8 Provide personalized configuration. [Priority 2]

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

Techniques: Implementation Techniques for Checkpoint A.2.8

Success Criteria:

  1. The authoring tool must provide the ability to save and reload all configuration settings related to visual or auditory output and keyboard operability.
  2. The author must be able to select, within the application, from multiple configuration sets.
A.2.9 Ensure previews emulate the accessible rendering features of target browsers [Priority 2]

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

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

Note 2: In addition, it is expected that the operation of the preview accessibility features will be constrained by the accessibility and/or completeness of the content.

Techniques: Implementation Techniques for Checkpoint A.2.9

Success Criteria:

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

GUIDELINE A.3 : Authoring Interface must be Understandable

A.3.1 Observe the accessibility conventions of the platform. [Priority 2]

Rationale: Authors are often familiar with accessibility conventions employed by the other applications built on a platform. Departures from those conventions have the tendency to disorient authors by creating an unfamiliar environment.

Note: For all Web-based interface components, meeting checkpoint A.0.1 will serve to meet this checkpoint.

Techniques: Implementation Techniques for Checkpoint A.3.1

Success Criteria:

  1. Focus and selection conventions for the current platform (specified in the conformance profile) must be followed.
  2. Keyboard accessibility configuration conventions (e.g. default accelerator key bindings) for the current platform (specified in the conformance profile) must be followed.@@
A.3.2 Maintain consistency within the authoring tool user interface. [Priority 2]

Rationale: Authors who may become disoriented easily will have less difficulty when consistent and predictable responses to author actions are provided. In general, consistent interfaces will benefit all authors to some degree.

Note: For all Web-based interface components, meeting checkpoint A.0.1 will serve to meet this checkpoint.

Techniques: Implementation Techniques for Checkpoint A.3.2

Success Criteria:

  1. User interface controls with the same text label or icon must perform the same function.
  2. Any text label or icon must not have more than one function.
  3. When the same function (e.g. saving, running a checker or canceling an action) is available in multiple areas of an authoring tool user interface, at least one method of controlling the function must be implemented for each area using identical user interface elements.
A.3.3 Document the authoring interface including all interface accessibility features. [Priority 1]

Rationale: While intuitive authoring interface design is valuable to many users, some users may still not be able to understand or be able to operate the authoring interface without thorough documentation. For instance, a user who is blind may not find a graphical authoring interface intuitive without supporting documentation.

Techniques: Implementation Techniques for Checkpoint A.3.3

Success Criteria:

  1. At least one version of the documentation must conform to WCAG (whether delivered on the Web, CD-ROM, etc.).
  2. All features that benefit the accessibility of the authoring interface must be documented in the help system (e.g., keyboard shortcuts).
  3. The current configuration of selectable actions must be displayed in either a centralized fashion (e.g., a list of keyboard shortcuts) or a distributed fashion (e.g., by listing keyboard shortcuts in the user interface menus).

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

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

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

Note: For all Web-based interface components, meeting checkpoint A.0.1 will serve to meet this checkpoint.

Techniques: Implementation Techniques for Checkpoint A.4.1

Success Criteria:

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

PART B: Support the production of accessible content

GUIDELINE B.1: Enable the production of accessible content

The creation of accessible content is dependent on the actions of the tool and the author. This guideline delineates the responsibilities that rest exclusively with the tool.

The first responsibility is to support formats that enable accessible content (Checkpoint 2.1). Web content produced by an authoring tool is most likely to be accessible, if the content is created in accordance with the requirements of WCAG and preserved in that state throughout the authoring process. The checkpoint requirements that support this include preserving accessible or unknown content (Checkpoint 2.2), automatically generating accessible content (Checkpoint 2.3), and including accessible pre-authored content (Checkpoint 2.4).

B.1.1 Support content types that enable the creation of Web content that conforms to WCAG. [Priority 1]

Rationale: Content types with published content type-specific WCAG benchmark documents facilitate the creation of Web content that can be assessed for accessibility with WCAG.

Techniques: Implementation Techniques for Checkpoint B.1.1

Success Criteria:

  1. Any authoring tool that chooses the content type used for publication on the Web for the author must always choose content types for which a published content type-specific WCAG benchmark exists.
  2. Any authoring tool that allows authors to choose the content type used for publication on the Web must always support at least one content type for which a published content type-specific WCAG benchmark exists and always give prominence to those content types.
B.1.2 Ensure that the tool preserves all unrecognized markup and accessibility information during transformations and conversions. [Priority 2]

Rationale: Unrecognized markup may include recent technologies that have been added to enhance accessibility and should be preserved during conversions or transformations. Accessibility information should also be preserved.

Techniques: Implementation Techniques for Checkpoint B.1.2

Success Criteria:

  1. All transformations and conversions supported by the authoring tool must always meet both of the following conditions:
    • (a) The author is notified before any unrecognized markup is permanently removed.
    • (b) All accessibility information is handled according to at least one of the following:
      • (i) Be preserved in the target format such that the information can be "round-tripped" (i.e. converted or transformed back into its original form) by the same authoring tool.
      • (ii) Be preserved in some other way in the target format.
      • (iii) Be removed only after the author has been notified and the content has been preserved in its original format
B.1.3 Ensure that when the tool automatically generates content it conforms to WCAG. [Web Content Checkpoints Relative to WCAG]

Rationale: Authoring tools that automatically generate content that does not conform to WCAG are a source of accessibility problems.

Note: WCAG includes a markup validity requirement.

Techniques: Implementation Techniques for Checkpoint B.1.3

Success Criteria:

  1. All markup and content that is automatically generated by the authoring tool (i.e. not authored "by hand") must always conform to WCAG.
B.1.4 Ensure that all pre-authored content for the tool conforms to WCAG. [Web Content Checkpoints Relative to WCAG]

Rationale: Pre-authored content, such as templates, images, and videos, is often included with authoring tools for use by the author. When this content conforms to WCAG, it is more convenient for authors and more easily reused.

Techniques: Implementation Techniques for Checkpoint B.1.4

Success Criteria:

  1. Any Web content (e.g., templates, clip art, example pages, etc.) that is bundled with the authoring tool or preferentially licensed to the users of the authoring tool (i.e. provided for free or sold at a discount), must conform to WCAG when inserted.

GUIDELINE B.2: Support the author in the production of accessible content

Actions may be taken at the author's initiative that may result in accessibility problems. The authoring tool should include features that provide support and guidance to the author in these situations, so that accessible authoring practices can be followed and accessible web content can be produced.

This support includes prompting and assisting the author to create accessible web content (Checkpoint 3.1), especially for information that cannot be generated automatically, checking for accessibility problems (Checkpoint 3.2), and assisting in the repair of accessibility problems (Checkpoint 3.3). In performing these functions, the authoring tool must avoid including automatically generated equivalent alternatives or previously authored equivalent alternatives without author consent (Checkpoint 3.4). The authoring tool may also provide automated means for managing equivalent alternatives (Checkpoint 3.5) and provide accessibility status summaries (Checkpoint 3.6).

Accessibility-related documentation provides support and guidance to the author. The documentation must accommodate the various levels of author familiarity with web content accessibility issues. The checkpoint requirements include documenting accessible content promoting features (Checkpoint 3.7) and ensuring that documentation demonstrates accessible authoring practices (Checkpoint 3.8) and provides instruction in creating accessible content (Checkpoint 3.9).

B.2.1 Prompt and assist the author to create content that conforms to WCAG. [Web Content Checkpoints Relative to WCAG]

Rationale: The authoring tool should help to prevent the author from making decisions or omissions that cause accessibility problems. If accessibility problems are prevented, less effort is required to create content that conforms to WCAG. Different tool developers will accomplish this goal in ways that are appropriate to their products, processes, and authors.

Techniques: Implementation Techniques for Checkpoint B.2.1

Success Criteria:

  1. Every time that content that requires accessibility information from the author in order to conform to WCAG is added or updated, then the authoring tool must inform the author that this additional information is required (e.g. via input dialogs, interactive feedback, etc.).
  2. Whenever the tool provides instructions to the author, either the instructions (if followed) must lead to the creation of Web content that conforms to WCAG, or the author must be informed that following the instructions would lead to Web content accessibility problems.
B.2.2 Check for and inform the author of accessibility problems. [Priority RP]

Rationale: Authors may not notice or be able to check for accessibility problems without assistance from the authoring tool.

Note 1: This checkpoint does not apply to authoring tools that constrain authoring choice to such a degree that it is not possible to create Web content that does not conform to WCAG.

Note 2: While automated and semi-automated checking may improve the authoring experience, identifying potential problems is sufficient to meet the success criteria for this checkpoint.

Techniques: Implementation Techniques for Checkpoint B.2.2

Success Criteria:

  1. An individual check must be associated with each requirement in the content type benchmark document (i.e. not blanket statements such as "does the content meet all the requirements").
  2. For checks that are associated with a type of element (e.g. img), each element instance must be individually identified as potential accessibility problems. For checks that are relevant across multiple elements (e.g. consistent navigation, etc.) or apply to most or all elements (e.g. background color contrast, reading level, etc.), the entire span of elements must be identified as potential accessibility problems, up to the entire content if applicable.
  3. If the authoring tool relies on author judgment to determine if a potential accessibility problem is correctly identified, then the message to the author must be tailored to that potential accessibility problem (i.e. to that requirement in the context of that element or span of elements).
  4. The authoring tool must present checking as an option to the author at or before the completion of authoring.
B.2.3 Assist authors in repairing accessibility problems. [Priority RP]

Rationale: Assistance by the authoring tool may simplify the task of repairing accessibility problems for some authors, and make it possible for others.

Note: While automated and semi-automated repair improves the authoring experience, providing repair instructions is sufficient to meet this checkpoint.

Techniques: Implementation Techniques for Checkpoint B.2.3

Success Criteria:

  1. For each potential accessibility problem identified by the checking function (required in Checkpoint B.2.2) provide at least one of the following:
    • repair instructions, for the author to follow, that are specific to the accessibility problem
    • an automated or semi-automated repair mechanism
B.2.4 Do not automatically generate equivalent alternatives or reuse previously authored alternatives without author confirmation, except when the function is known with certainty. [Priority 1]

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

Techniques: Implementation Techniques for Checkpoint B.2.4

Success Criteria:

  1. When the author inserts an unrecognized non-text object, the tool must never insert an automatically generated text equivalent (e.g. label generated from the file name).
  2. When the author inserts a non-text object for which the tool has a previously authored equivalent alternatives (i.e. created by the author, tool designer, pre-authored content developer, etc.), but the function of the object is not known with certainty, the tool must always prompt the author to confirm insertion of the equivalent. However, where the function of the non-text object is known with certainty (e.g. "home button" on a navigation bar, etc.), the tool may automatically insert the equivalent.
B.2.5 Provide functionality for managing, editing, and reusing alternative equivalents. [Priority 3]

Rationale: Simplifying the initial production and later reuse of alternative equivalents will encourage authors to use them more frequently. In addition, such an alternative equivalent management system will facilitate meeting the requirements of Checkpoints B.2.1, B.2.2, B.2.3 and B.2.4.

Techniques: Implementation Techniques for Checkpoint B.2.5

Success Criteria:

  1. The authoring tool must always keep a record of alternative equivalents that the author inserts for particular non-text objects in a way that allows the text equivalent to be offered back to the author for modification and re-use if the same non-text object is reused.
B.2.6 Provide the author with a summary of accessibility status. [Priority 3]

Rationale: This summary will help the author to improve the accessibility status of their work, keep track of problems, and monitor progress.

Techniques: Implementation Techniques for Checkpoint B.2.6

Success Criteria:

  1. The authoring tool must provide an option to view a list of all known accessibility problems (i.e. detected by automated checking or identified by the author) prior to completion of authoring.
B.2.7 Document in the help system all features of the tool that support the production of accessible content. [Priority 2]

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

Techniques: Implementation Techniques for Checkpoint B.2.7

Success Criteria:

  1. All features that play a role in creating accessible content must be documented in the help system.
B.2.8 Ensure that accessibility is demonstrated in all documentation and help, including examples. [Priority 3]

Rationale: If accessible authoring is integrated into instruction and guidance offered by the tool (e.g. documentation, help, tutorials, examples, and workflow processes), authors are more likely to follow accessible authoring as a common practice. This can also facilitate a better understanding of the reasoning behind and the consequences of authoring accessible content.

Techniques: Implementation Techniques for Checkpoint B.2.8

Success Criteria:

  1. All examples of markup and screenshots of the authoring interface that appear in the documentation and help must demonstrate accessible Web content.
B.2.9 Provide a tutorial on the process of accessible authoring. [Priority 3]

Rationale: Authors are more likely to use features that promote accessibility if they understand when and how to use them.

Techniques: Implementation Techniques for Checkpoint B.2.9

Success Criteria:

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

GUIDELINE B.3: Promote and integrate accessibility solutions

This guideline requires that authoring tools must promote accessible authoring practices within the tool as well as smoothly integrate any functions added to meet the other requirements in this document. The checkpoint requirements for this section include ensuring that accessibility practices and features are given authoring interface priority (Checkpoint 4.1), clear availability (Checkpoint 4.2), workflow integration (Checkpoint 4.3), and sufficient configurability (Checkpoint 4.4).

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

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. Moreover, the effectiveness of the solutions are perhaps better judged by the marketplace than by a set of stringent requirements.

B.3.1 Ensure that the most accessible option for an authoring task is given priority. [Priority 2]

Rationale: Authors are most likely to use the first and easiest option for a given authoring task.

Techniques: Implementation Techniques for Checkpoint B.3.1

Success Criteria:

  1. When the author has more than one markup implementation to choose from (e.g. the color of text can be changed with presentation markup or style sheets), those markup implementations that conform to WCAG must have equal or higher prominence than those markup implementations that do not meet the WCAG requirements.
  2. Any choices of content types or authoring practices presented to the author (e.g., in menus, toolbars or dialogs) that will lead to the creation of content that does not conform to WCAG must be marked or labeled so that the author is aware of the consequences prior to making the choice.
B.3.2 Ensure that accessibility prompting, checking, repair functions, and documentation are always clearly available to the author. [Priority 2]

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

Techniques: Implementation Techniques for Checkpoint B.3.2

Success Criteria:

  1. All accessibility prompting, checking, repair functions and documentation must meet the following conditions:
    • (a) If they are continuously active, then they must always be enabled by default and if the author disables them (e.g. from a preferences screen), then the tool must inform the author that this may increase the risk of accessibility problems.
    • (b) They must have at least the same prominence as prompting, checking, repair and documentation for other potential problems (e.g. markup validity, program code syntax, spelling and grammar).
B.3.3. Ensure that sequential authoring processes integrate accessible authoring practices. [Priority 2]

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

Techniques: Implementation Techniques for Checkpoint B.3.3

Success Criteria:

  1. Any feature that helps to sequence author actions (such as object insertion dialogs, design guides, templates, wizards, tutorials, or instruction text) must integrate relevant accessibility prompts. These prompts should occur at or before the author is required to make the authoring decision related to the prompt.
B.3.4 Ensure that accessibility prompting, checking, repair functions and documentation are configurable. [Priority 3]

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

Techniques: Implementation Techniques for Checkpoint B.3.4

Success Criteria:

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

4. Glossary

This glossary is normative. However, some terms (or parts of explanations of terms) may not have an impact on conformance.

a b c d e f g h i j k l m n o p q r s t u v w x y z

Accessibility Problem, Authoring Interface
An authoring interface accessibility problem is an aspect of an authoring interface that fails to meet one of the checkpoint success criteria in Part A.
Accessibility Problem, Web Content
A Web content accessibility problem is an aspect of Web content that fails to meet some requirement of WCAG. The severity of the problem is relative and is determined by reference to WCAG.
Accessible Web Content
Accessible Web content is Web content (e.g. output of an authoring tool) that is sufficiently free of Web content accessibility problems to be usable by end-users regardless of disability.
Accessible Authoring Interface
An accessible authoring interface is an authoring interface, Web-based or not, for an authoring tool that is sufficiently free of authoring interface accessibility problems to be usable by authors regardless of disability.
Accessibility Information
Accessibility information is any information that is necessary and sufficient for undertaking an accessible authoring practice. This information may include, but is not limited to, equivalent alternatives.
Accessible Authoring Practice
An accessible authoring practice is any authoring activity by the author or the authoring tool that leads to accessible Web content.
Alert
An alert makes the author aware of events or actions that require a response or reaction, but not necessarily immediately. The event or actions that trigger an alert may have serious consequences if ignored.
Attribute
An attribute, as used in the document, has the same sense as in SGML and XML [XML]. Some attributes are integral to the accessibility of content (e.g., the "alt", "title", and "longdesc" attributes in HTML).
Audio Description
Audio description (also called "Described Video") is an equivalent alternative that provides aural information about actions, body language, graphics, and scene changes in a video. Audio descriptions are commonly used by people who are blind or have low vision, although they may also be used as a low-bandwidth equivalent on the Web. An audio description is either a pre-recorded human voice or a synthesized voice (recorded or automatically generated in real time). The audio description must be synchronized with the auditory track of a video presentation, usually during natural pauses in the auditory track.
Author
An author is a user of an authoring tool. This may include content authors, designers, programmers, publishers, testers, etc.
Authored "By Hand"
Authoring by hand is a situation in which the author specifies Web content at the lowest level (e.g. typing into a text editor).
Authoring Action
An authoring action is any action that the author takes using the authoring interface with the intention of adding or modifying Web content.
Authoring Tool User Interface
An authoring tool user interface is the display and control mechanism available to an author to communicate with and operate the authoring tool software. Authoring tool interfaces may be Web-Based (i.e. tools that are implemented using Web content and run within a user agent) or non-Web-Based (i.e. tools that run directly on a operating system such as Windows or Mac OS) or a combination (e.g. a tool that runs most of its functionality directly on an operating system, but that includes Web-based documentation that the author accesses using a browser).
Authoring Interface, Full-Featured
A full-featured authoring interface is one that includes editing methods for all of the properties that are editable by an authoring tool.
Authoring Tool
See "Definition of authoring tool".
Browser
???.
Captions
Captions are equivalent alternatives for movie audio. Captions consist of a text transcript of the auditory track of the movie (or other video presentation) that is synchronized with the video and auditory tracks. Captions are generally rendered graphically and benefit people who can see but are deaf, hard-of-hearing, or cannot hear the audio.
Checking, Accessibility
Accessibility checking (or "accessibility evaluation") is the process by which Web content is evaluated for Web content accessibility problems. ATAG 2.0 identifies three categories of checking: Automated (i.e. the authoring tool is able to check for problems automatically, with no human intervention required), Semi-Automated (i.e. the authoring tool is able to identify potential problems, but still requires human judgment by the author to make a final decision on whether an actual problem exists) and Manual (i.e. the authoring tool provides the author with instructions for detecting a problem, but does not automate the task of detecting the problem in any meaningful way).
Completion of Authoring
Completion of authoring is the point in time at which an authoring session ends and the author has no opportunity to make further changes. This may be when an author chooses to "save and exit", or "publish", or it may occur automatically at the end of a wizard, etc.
Configurability
Configurability refers to the adjustment of authoring tool settings, such as layout, rendering style, or other parameters that may affect the author's ability to use the authoring interface or editing methods. The author must then be able to store these adjustments, or author preferences, so they can be used in all future sessions with the authoring tool.
Continuously Active
Continuously active features of an authoring tool are those that constantly examine an author's actions (e.g. a "check-spelling-as-you-type" feature). These contrast with features that must be activated and then operate only for a discrete period (e.g. a print feature)
Conversion
A conversion is a process that takes, as input, Web content in one format and produces, as output, Web content in another format (e.g.,"Save as HTML" functions).
Device-Independent Action
A device-independent action is not bound to only one type of input device.
Directly Linked
Two interface features are directly linked if there is a single author action on one of the features that causes the other to appear.
Display
Display refers to the presentation of information to the author, either visually or through a device such as a screen reader.
Document
A document is a structure of elements along with any associated content; the elements used are defined by a markup language.
Documentation
Documentation refers to any information that supports the use of an authoring tool. This information may be found electronically or otherwise and includes manuals, installation instructions, help mechanisms, sample workflows, and tutorials, etc.
Editable
A property is editable when the authoring tool allows its value to be changed. It is possible for a Web content property to be editable by one authoring tool, but not by another.
Editing Method
An editing method is a means by which an author is able to change the value of an editable property. Examples of editing methods include direct text entry, selection from a list, etc.
Editing View
An editing view is a view provided by the authoring tool that allows editing by the author.
Element
An element is any identifiable item within a document: for example, a character, word, image, paragraph, or spreadsheet cell. In [HTML4] and [XML], an element refers to a pair of tags and their content, or an "empty" tag - one that requires no closing tag or content.
End-User
An end-user is a person who interacts with Web content once it has been authored. In some cases, the author and end-user is the same person.
Equivalent Alternative
An equivalent alternative is content that is an acceptable substitute for other content that an end-user may not be able to access. An equivalent alternative fulfills essentially the same function or purpose as the original content upon presentation to the end-user. Equivalent alternatives include text alternatives, which present a text version of the information conveyed in non-text content such as graphics and audio clips. The text alternative is considered accessible because it can be rendered in many different ways (e.g. as synthesized speech for individuals who have visual or learning disabilities, as Braille for individuals who are blind, as graphical text for individuals who are deaf or do not have a disability). Equivalent alternatives also include "media alternatives", which present essential audio information visually (captions) and essential video information auditorily (audio descriptions).
 
International health and safety standards for general flash or red flash
A recommended standard for general flash and red flash are the "Computer adapted ITC general flash threshold" and the "Computer adapted ITC red flash threshold" of the Wisconsin Computer Equivalence Algorithm. This is a method for applying the United Kingdom's "ITC Guidance Note for Licensees on Flashing Images and Regular Patterns in Television (Revised and re-issued July 2001)" to computer screens, which typically occupy a greater area of the user's visusal field. The algorithms are as follows:
Computer adapted ITC general flash threshold: A sequence of flashes or rapidly changing image sequences is not permitted when both the following occur:
  1. the combined area of flashes occurring concurrently (but not necessarily contiguously) occupies more than one quarter of any 335 x 268 pixel rectangle anywhere on the displayed screen area when the content is viewed at 1024 by 768 pixels and
  2. there are more than three flashes within any one-second period.
Note: For the general flash threshold, a flash is defined as a pair of opposing changes in luminance (i.e., an increase in luminance followed by a decrease, or a decrease followed by an increase) of _@@_ per rectangle meter (cd.m-2) or more and where the screen luminance of the darker image is below _@@_.
Computer adapted ITC red flash threshold: A transition to or from a saturated red at any luminance level is not permitted when both of the following occur:
  1. the combined area of flashes occurring concurrently occupies more than one quarter of any 335 x 268 pixel rectangle anywhere on the displayed screen area when the content is viewed at 1024 by 768 pixels and
  2. there are more than three flashes within any one-second period.
Note: For the red flash threshold, a flash is defined as any pair of opposing transitions to or from a saturated red exceeding @@_ % of _@@_. (See note below)
Inform
To inform is to make the author aware of an event or situation using methods such as alert, prompt, sound, flash. These methods may be unintrusive (that is, presented without stopping the author's current activity), or intrusive (that is, interrupting the author's current activity).
Information Icon
An information icon is a graphic within the authoring interface that an author can select to receive additional information.
Informative
Informative ("non-normative") parts of this document are never required for conformance
Markup
Markup is a set of tags from a markup language that specify the characteristics of a document. Markup can be presentational (i.e., markup that encodes information about the visual layout of the content), structural (i.e., markup that encodes information about the structural role of elements of the content) or semantic (i.e., markup that encodes information about the intended meaning of the content).
Markup Language
A markup language is a syntax and/or set of rules used to manage markup (e.g. HTML [HTML4], SVG [SVG], or MathML [MATHML]).
Markup, Unrecognized
Unrecognized markup are elements, attributes, etc. that fall outside the DTD that an authoring tool is using to process author input.
Normative
Normative parts of this document are always required for conformance.
Object
An object is one or more elements that together are perceived as one entity.
Preview
A view of the content that is intended to show how it will appear and behave in a browser. Content within a preview is not editable.
Prominence
The prominence of a control in the authoring interface is a heuristic measure of the degree to which authors are likely to notice a control when operating the authoring tool. In this document, prominence refers to visual as well as keyboard-driven navigation. Some of the factors that contribute to the prominence of a control include: control size (large controls or controls surrounded by extra white space may appear to be conferred higher importance), control order (items that occur early in the "localized" reading order (e.g. left to right and top to bottom; right to left and top to bottom, etc.) are conferred higher importance), control grouping (grouping controls together can change the reading order and the related judgments of importance), advanced options (when the properties are explicitly or implicitly grouped into sets of basic and advanced properties, the basic properties may gain apparent importance), and highlighting (controls may be distinguished from others using icons, color, styling, etc.).
Prompt
In this document "prompt" is used as a mechanism initiated by the authoring tool designed to urge, suggest, and encourage.
Property
A property is a characteristic of an object, for example structural information (e.g., first class heading, list item) or presentation information (e.g., bold font, 14pt font).
Repairing, Accessibility
Accessibility repairing is the process by which Web content accessibility problems that have been identified within Web content are resolved. ATAG 2.0 identifies three categories of repair: Automated (i.e. the authoring tool is able to make repairs automatically, with no author input required), Semi-Automated (i.e. the authoring tool can provide some automated assistance to the author in performing corrections, but the author's input is still required before the repair can be complete) and Manual (i.e. the authoring tool provides the author with instructions for making the necessary correction, but does not automate the task in any substantial way).
Selectable Actions
Any items that are designed to be activated from within a menu, toolbar, palette, etc.
Transcript
Transcripts are equivalent alternatives for the sounds in an audio clip or an auditory track of a multimedia presentation. A "collated text transcript" for a video combines (collates) caption text with text descriptions of video information (descriptions of the actions, body language, graphics, and scene changes of the visual track).
Techniques
Techniques are informative suggestions and examples for ways in which the success criteria of a checkpoint might be satisfied.
Technologies
A technology is a: markup or programming language, application Programming Interface (API), or communication protocol. [@@the group intends this to cover what we used to call formats, PDF etc.@@]
Transformation
A transformation is a process that takes, as input, an object of Web content in one format and produces, as output, a different object of Web content in the same format (e.g., a function that transforms tables into lists).
Typical Author
A person who possesses levels of authoring knowledge, authoring tool proficiency, and experience with accessibility authoring practices that are average for users of a particular authoring tool.
User Agent
A user agent is software that retrieves and renders Web content. This may include Web browsers, media players, plug-ins, and other programs - including assistive technologies - that help in retrieving and rendering Web content.
View
A view is a rendering of Web content by an authoring tool.
Web Content
Content published on the Web. @@clean up def'n to include HTML, PDF, Flash, Word docs, etc.@@
Workflow
A workflow is a customary sequence of steps or tasks that are followed to produce a deliverable.

5. References

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

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

5.1 How to refer to this document

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

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

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

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

<p>
<cite><a href="http://www.w3.org/TR/2004/WD-ATAG20-20041122">
"Authoring Tool Accessibility Guidelines 1.0",</a></cite>
J. Treviranus, C. McCathieNevile, J. Richards, M. May, eds.,
W3C Recommendation, 16 November 2004.
The <a href="http://www.w3.org/TR/2004/WD-ATAG20-20041122/">latest
version</a> of this document is available at
http://www.w3.org/TR/2004/WD-ATAG20-20041122/.
</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.

5.2 Normative references

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

[ISO-TS-16071]
ISO TS 16071:2003 - Ergonomics of human-system interaction - Guidance on accessibility for human-computer interfaces. ISO's Web site is http://www.iso.ch.
[WCAG10]
"Web Content Accessibility Guidelines 1.0", W. Chisholm, G. Vanderheiden, and I. Jacobs, eds., 5 May 1999. This WCAG 1.0 Recommendation is http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/.
[WCAG20]
"Web Content Accessibility Guidelines 2.0 (Working Draft)", W. Chisholm, G. Vanderheiden, and J. White, editors. The latest version of the Web Content Accessibility Guidelines 2.0 is available at http://www.w3.org/TR/WCAG20/. Note: This document is still a working draft.

5.3 Informative references

[ATAG10]
"Authoring Tool Accessibility Guidelines 1.0", J. Treviranus, C. McCathieNevile, I. Jacobs, and J. Richards, eds., 3 February 2000. This W3C Recommendation is http://www.w3.org/TR/2000/REC-ATAG10-20000203/.
[ATAG10-TECHS]
"Techniques for Authoring Tool Accessibility", J. Treviranus, J. Richards, I. Jacobs, and C. McCathieNevile editors. The latest version is available at http://www.w3.org/TR/ATAG10-TECHS.
[ATAG20-TECHS]
"Techniques for Authoring Tool Accessibility 2.0", J. Treviranus, J. Richards, C. McCathieNevile, and M. May, editors. The latest version is available at http://www.w3.org/TR/ATAG20-TECHS.
[CSS1]
"CSS, level 1 Recommendation", B. Bos and H. Wium Lie, editors., 17 December 1996, revised 11 January 1999. This CSS1 Recommendation is http://www.w3.org/TR/1999/REC-CSS1-19990111. The latest version of CSS1 is available at http://www.w3.org/TR/REC-CSS1. Note: CSS1 has been superseded by CSS2. Tools should implement the CSS2 cascade in particular.
[CSS2]
"CSS, level 2 Recommendation", B. Bos, H. Wium Lie, C. Lilley, and I. Jacobs, editors., 12 May 1998. This CSS2 Recommendation is http://www.w3.org/TR/1998/REC-CSS2-19980512. The latest version of CSS2 is available at http://www.w3.org/TR/REC-CSS2.
[HTML4]
"HTML 4.01 Recommendation", D. Raggett, A. Le Hors, and I. Jacobs, editors., 24 December 1999. This HTML 4.01 Recommendation is http://www.w3.org/TR/1999/REC-html401-19991224. The latest version of HTML 4 is available at http://www.w3.org/TR/html4.
[MATHML]
"Mathematical Markup Language", P. Ion and R. Miner, editors., 7 April 1998, revised 7 July 1999. This MathML 1.0 Recommendation is http://www.w3.org/1999/07/REC-MathML-19990707. The latest version of MathML 1.0 is available at http://www.w3.org/TR/REC-MathML.
[PWD-USE-WEB]
"How People With Disabilities Use the Web", J. Brewer, editor, 4 January 2001. The latest version of How People with Disabilities Use the Web is available at http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/.
[RDF10]
"Resource Description Framework (RDF) Model and Syntax Specification", O. Lassila, R. Swick, editors. The 22 February 1999 Recommendation is http://www.w3.org/TR/1999/REC-rdf-syntax-19990222. The latest version of RDF 1.0 is available at http://www.w3.org/TR/REC-rdf-syntax.
[SVG]
"Scalable Vector Graphics (SVG) 1.0 Specification (Working Draft)", J. Ferraiolo, editor. The latest version of the SVG specification is available at http://www.w3.org/TR/SVG.
[UAAG10]
"User Agent Accessibility Guidelines 1.0", I. Jacobs, J. Gunderson, E. Hansen, editors, 17 December 2002. This is a W3C Recommendation.
[UAAG10-TECHS]
"Techniques for User Agent Accessibility Guidelines 1.0", J. Gunderson and I. Jacobs, editors. The latest version of Techniques for User Agent Accessibility Guidelines 1.0 is available at http://www.w3.org/TR/UAAG10-TECHS/.
[XAG]
"XML Accessibility Guidelines", D. Dardailler, S. B. Palmer, C. McCathieNevile, editors, 3 October 2002. This is a Working Group Draft.
[XHTML10]
" XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition)", S. Pemberton, et al., authors., 26 January 2000, revised 1 August 2002. This XHTML 1.0 Recommendation is http://www.w3.org/TR/2002/REC-xhtml1-20020801/. The latest version of XHTML 1.0 is available at http://www.w3.org/TR/xhtml1.
[XML]
"The Extensible Markup Language (XML) 1.0", T. Bray, J. Paoli, C. M. Sperberg-McQueen, editors., 10 February 1998. This XML 1.0 Recommendation is http://www.w3.org/TR/1998/REC-xml-19980210. The latest version of the XML specification is available at http://www.w3.org/TR/REC-xml.

6. Acknowledgments

The active participants of the Authoring Tool Accessibility Guidelines Working Group who authored this document were: Tim Boland (National Institute for Standards and Technology), Barry A. Feigenbaum (IBM), Karen Mardahl (STC), Matt May (Team Contact, W3C), Greg Pisocky (Adobe), Jan Richards (Adaptive Technology Resource Centre, University of Toronto), Roberto Scano (IWA/HWG), and Jutta Treviranus (Chair of the working group, Adaptive Technology Resource Centre, University of Toronto)

Many thanks to the following people who have contributed to the AUWG through review and comment: Kynn Bartlett, Giorgio Brajnik, Judy Brewer, Wendy Chisholm, Daniel Dardailler, Geoff Deering, Katie Haritos-Shea, Kip Harris, Phill Jenkins, Len Kasday, Marjolein Katsma, William Loughborough, Charles McCathieNevile, 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.

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