Authoring Tool Accessibility Guidelines 2.0

Abstract

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

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

Status of this document

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

This is an internal Editor's Draft.

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

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

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

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

Introduction

This section is informative, except where noted.

You are reading 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 content that completely conforms to WCAG may not be fully accessible to every person with a disability.

In order to acheive accessibility authoring tools must address the needs of two (potentially overlapping) user groups:

• authors of Web content, whose needs are met by ensuring the authoring tool user interface itself is accessible (see Part A of the guidelines), and
• end users of Web content, whose needs are met by ensuring that all authors are enabled, supported, and guided towards producing accessible Web content, with the assumption that many authors will not be familiar with the specific needs of end users people with disabilities.

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:

• authoring tool developers,
• authoring tool users (authors),
• authoring tool purchasers, and
• policy makers.

ATAG 2.0 is part of a series of accessibility guidelines published by the Web Accessibility Initiative (WAI). The relationship between these documents is explained in "Essential Components of Web Accessibility" [COMPONENTS]. For more information on the topic of accessibility, see "How People with Disabilities Use the Web" [PWD-USE-WEB].

This ATAG 2.0 document itself consists of:

• This introduction
• The guidelines with normative success criteria
• Links to a separate non-normative document, entitled "Techniques for Authoring Tool Accessibility Guidelines 2.0" [ATAG20-TECHS] (the "Techniques document" from here on), that provide sufficient and advisory techniques for how each success criteria might be satisfied, (Note: These techniques are informative examples only, and other strategies may be used or required to satisfy the success criteria)
• Information about conformance
• Appendices containing references, a glossary, a checklist and a document comparing the guidelines in ATAG 1.0 to those in this document (ATAG 2.0).

Relationship to the Web Content Accessibility Guidelines (WCAG)

At the time of publication, version 1.0 of WCAG is a W3C Recommendation [WCAG10], and a second version of the guidelines is under development [WCAG20]. Note that the two versions have somewhat different Conformance Models.

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

The developer of an authoring tool select whichever version of WCAG is most appropriate for the circumstances of a given product, as long as the choice is recorded in the conformance profile. However, consideration should be given to the following when deciding which WCAG version to use:

• The latest version of WCAG will be the most accurate with respect to state-of-the-art technologies and accessibility best practices. Older versions of WCAG may include requirements that are no longer necessary, due to advances in user agent technology.
• The versions of WCAG differ with respect to the formats for which there are published WCAG technique documents. This is important because the techniques documents may be useful when constructing Web Content Accessibility "Benchmark" documents as required by ATAG 2.0.
• The versions of WCAG differ in the degree to which they match the legislation and policies that drive author requirements. Many authors will be seeking to use authoring tools to create Web content that meets legislation, corporate policies, etc. It is likely that as WCAG progresses, so too will legislation and policies, albeit at an uneven pace. Authoring tool developers may, therefore, consider supporting both versions of WCAG in the interim.

ATAG 2.0 Guidelines

This section is normative.

How the guidelines are organized

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

• The principle number.
• The principle title.
• An explanation of the principle.
• A list of guidelines for the principle.

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

• The guideline number. (informative)
• The guideline title. (informative)
• A rationale for the guideline. (informative)
• Note(s) related to the guideline. (informative)
• A pointer to implementation techniques for the guideline. (informative)
• Success criteria for testing whether the guideline has been satisfied. (normative)

Conformance

This section is normative.

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

Conformance Levels

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

Success Criteria

Each success criteria is assigned one of three (3) levels.

• Level A:
  • For success criteria in Part A:
    • These success criteria achieve accessibility by supporting assistive technology while putting the fewest possible limits on tool design. Thus people with a wide range of disabilities using a wide range of assistive technologies, from voice input and eye-tracking devices to screen readers and screen magnifiers, are able to access tools in different ways.
  • For success criteria in Part B:
    • A basic level of support to all authors in creating Web content
    • The content accessibility target is Level "A" Web content accessibility.
• Level AA:
  • For success criteria in Part A:
    • These success criteria provide additional support for assistive technology. At the same time, they also support more direct access to content by the many people who use authoring tools without assistive technology. In general, Level AA success criteria place more limits on tool design than Level A success criteria in Level.
  • For success criteria in Part B:
    • An intermediate level of support to all authors in creating Web content
    • The content accessibility target is raised to Level "AA" Web content accessibility.
• Level AAA:
  • For success criteria in Part A:
    • These success criteria increase both direct access and access through assistive technology. They place even tighter limits on tool design.
  • For success criteria in Part B:
    • An advanced level of support to all authors in creating accessible Web content.
    • The content accessibility target is raised to Level "AAA" Web content accessibility.

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

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 content type(s) that are produced by the authoring tool or are used to implement Web-based user interface functionality of the authoring tool (if applicable). This precise interpretation helps the evaluator to judge the completeness and consistency of accessibility-related authoring tool functions that must interoperate, such as accessibility prompting, evaluation, and repair functions. In addition, because the Benchmark must be made public, it allows claims to be more fully checked for accuracy.

What does a Web Content Accessibility Benchmark document include?

A Benchmark document must be publicly published on the Web (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 content type(s) 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:
   • Level "A" Web content accessibility: Content conforming to WCAG 2.0 Level "A" or a similar accessibility standard.
   • Level "AA" Web content accessibility: Content conforming to WCAG 2.0 Level "AA" or a similar accessibility standard.
   • Level "AAA" Web content accessibility: Content conforming to WCAG 2.0 Level "AAA" or a similar accessibility standard.
4. Any assumptions about user agents available to authors or end users.
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 content type (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 content type(s) 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 content types, the Working Group suggests checking to see if a Benchmark document has already been published, before creating a new one.

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

The Working Group suggests the following:

• WCAG Guideline documents:
  • WCAG 1.0 Recommendation [WCAG10]
  • WCAG 2.0 Working Draft [WCAG20]
• WCAG Technique documents:
  • Techniques for WCAG 1.0 [WCAG10-TECHS]
  • Techniques for WCAG 2.0 [WCAG20-TECHS-GENERAL]
• Understanding WCAG documents:
  • Understanding WCAG 2.0 [WCAG20-UNDERSTANDING]
• W3C Access Note series:
  • CSS 2.0 [CSS2-ACCESS]
  • SVG [SVG-ACCESS]
  • SMIL [SMIL-ACCESS]
• Content type specifications

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

• At least one version of the conformance claim must be published on the Web as a document meeting level "A" of Web content accessibility. A suggested metadata description for this document is "ATAG 2.0 Conformance Claim".
• Whenever the claimed conformance level is published (e.g., in marketing materials), the URI for the on-line published version of the conformance claim must be included.
• The existence of a conformance claim does not imply that the W3C has reviewed the claim or assured its validity.
• Claimants may be anyone (e.g., developers, journalists, other third parties).
• Claimants are solely responsible for the accuracy of their claims and keeping claims up to date.
• Claimants are encouraged to claim conformance to the most recent version of the Authoring Tool Accessibility Guidelines Recommendation that is available.

Required Components of an ATAG 2.0 Conformance Claim

1. The date of the claim.
2. The guidelines title, 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 content type(s) produced by the authoring tool that are covered by the claim.
     • The list must include at least one content type for the conformance claim to be valid.
     • When content types are typically produced together (e.g., HTML and JavaScript), they can be listed separately or together in the list.
     • Each of the content types in this list must include a Web content accessibility benchmark document for that content type.
   • (c) A list of any other content type(s) produced by the authoring tool that are not covered by the claim.
   • (d) The platform(s) upon which all or part (e.g., help system) of the authoring tool was evaluated:
     • For user agent platform(s) 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 platforms that are not user agents, provide:
       • The name and version information of the platform(s) (e.g., operating system, Java virtual machine, etc.).
       • The name and version of the accessibility platform architecture(s) employed.

Optional Components of an ATAG 2.0 Conformance Claim

1. A description of the authoring tool that identifies the types of authoring tool functions that are present in the tool. Choose one or more of: Code-level authoring functions, WYSIWYG authoring functions, object oriented authoring functions, or indirect authoring functions.
2. Any additional information about the tool, including progress towards the next conformance level.
3. 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 Accesssibility Benchmark document.

Appendix A: Glossary

This section is normative.

accessibility platform architecture

A programmatic interface that is specifically engineered to communicate with assistive technologies. Examples include MSAA and IAccessible2 for Windows applications, Gnome Accessibility Toolkit API for Gnome, Java Access for Java applications.

accessibility problem, authoring tool user interface

An aspect of an authoring tool user interface that fails to meet one of the guideline success criteria in Part A. The severity of a given problem is reflected in the level of the failed success criteria.

accessibility problem, Web content

An aspect of Web content that fails to meet some accessibility requirement. In ATAG 2.0, the severity of a given problem is relative and is determined by the accessibility standard referenced by the Web content accessibility benchmark.

accessible Web content

Web content (e.g., output of an authoring tool) that is free of accessibility problems. Usually this refers to a particular level of accessibility (e.g., Web content that meets Level "A" Web content accessibility).

accessible authoring tool user interface

An authoring tool user interface that meets the success criteria in Part A. The level of accessibility is determined by the level of the satisfied success criteria.

accessibility information

Any information that is necessary for undertaking an accessible authoring practice. This information differs according to content type and may include, but is not always limited to, equivalent alternatives.

accessible authoring practice

A technique for creating Web content that avoids or corrects a Web content accessibility problem. Accessible authoring practices may be undertaken by either authors or the authoring tool and may or may not require accessibility information.

accessible content support features

All of the features of an authoring tool that play a role in satisfying the success criteria for guidelines B.2.1, B.2.2, B.2.3, B.2.4, B.2.5 and B.2.6.

alert

A user interface mechanism that makes authors aware of something that may require a response. The author response is not necessarily immediately required.

audio description (also called "Described Video", "Video Description" and "Descriptive Narration" )

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. (See also extended audio description.)

audio description, extended

Audio description that is added to an audiovisual presentation by pausing the video so that there is time to add additional description.

author

The user of an authoring tool. This may include content authors, designers, programmers, publishers, testers, etc. working alone or collaboratively.

authoring action

Any action that authors take using the authoring tool user interface with the intention of editing Web content (e.g., typing text, inserting an element, launching a "wizard").

authoring outcome

A state of the Web content being authored (e.g., bold text, resized image) that can be achieved by applying one or more authoring practices. There may be several alternative authoring practices that are able to satisfy the same authoring outcome.

authoring session

A state of the authoring tool in which content can be edited by the author. The end of an authoring session may occur for several reasons.

authoring session, end of

The point in time at which an authoring session ends and the author has no opportunity to make further changes. This may be under the control of the author (e.g., closing a document, publishing, etc.) 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 part of an authoring tool user interface that is not implemented as Web content and as a result runs directly on a platform such as Windows, MacOS, Java Virtual Machine, etc..

authoring tool user interface, Web-based

Any part of an authoring tool user interface, including editing views, documentation, etc., that is implemented using a content type and is rendered by a user agent. Since Web-based tools may be implemented in many of the same content types that they are used to edit, the distinction between content display and 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 (e.g., an on-line content management system) or a combination of both (e.g., a stand-alone markup editor with on-line help pages). Authoring tool user interfaces can usefully be considered in two parts:

1. Content display: The authoring tool's rendering of the content being edited in an editing view or previewed in a preview. Examples include:
   • marked-up content in a code-level editing view,
   • rendered text, images, tables, form controls, etc. in a WYSIWYG editing view,
   • vector graphics with editing "handles" in an object-oriented editing view,
   • text entries and setting values in an indirect editing view,
   • rendered text, images, tables, form controls, etc. in a preview.
2. User interface "chrome": The parts of the user interface that surround, underlie or super-impose upon the content display. Examples include:
   • controls that surround the content display including menus, button bars, palettes, help windows, cursors, dialog boxes, etc.,
   • controls that underlie the content display (i.e. implementing non-rendered part of editing views) including text areas for a code-level editing view, text boxes in an indirect editing view, etc.,
   • controls that are super-imposed upon content displays including context menus on content, underlining problematic content, etc.

authoring tool

See "Definition of authoring tool".

captions

An equivalent alternative that takes the form of text presented and synchronized with multimedia to provide not only the speech, but also non-speech information conveyed through sound, including meaningful sound effects and identification of speakers. Note: 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.

checking, accessibility (also called "accessibility evaluation")

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:

1. manual checking in which the authoring tool only provides instructions for authors to follow in order to identify problems;
2. semi-automated checking in which the authoring tool is able to identify potential problems, but still requires human judgment by the author to make decisions that determine, or help to determine, whether actual problems exist; and
3. automated checking in which the authoring tool is able to check for problems automatically, with no human intervention required.

An authoring tool may support any combination of checking types.

collection of software components

Any software products used together (e.g., base tool and plug-in) or separately (e.g., markup editor, image editor, and validation tool), regardless of whether there has been any formal collaboration between the developers of the products.

content type

A data format, programming or markup language that is intended to be retrieved and rendered by a user agent (e.g., HTML, CSS, SVG, PNG, PDF, Flash, JavaScript or combinations).

content, author generated

When the author specifies Web content at the level to be interpreted by the user agent (e.g., typing text content, typing markup into a text editor, choosing an element by name from a list).

content, automatically generated

When the authoring tool specifies Web content. The implementation for this often involves applying a template of some kind.

content, Web (or shortened to "content")

Any material in a content type. If the content type is a markup language, then "content" covers the information both within the tags (i.e., the markup) and between them. In this document, "content" is primarily used in the context of the material that is outputted by authoring tools. This includes Web applications, including those that, in turn, act as Web-based authoring tools.

conversion

A process that takes as input, content in one content type and produces as output, content in another content type (e.g., "Save as HTML" functions).

display settings, audio

The characteristics of audio output of music, sounds and speech and include volume, speech voices, voice speed, and voice emphasis.

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.

editing view

A view provided by the authoring tool that allows editing of content by authors. The authoring tool may include more than one type of editing view (e.g., an HTML editor with both code-level and WYSIWYG editing views. Types of editing views include:

1. Code-level editing views: Authors have full control over all aspects of the resulting Web content. Includes plain text editors as well as editors that allow manipulation of symbolic representations that are sufficiently fine-grained to allow authors the same freedom of control as plain text editing (e.g., plain text editors enhanced with graphical tag placeholders). Examples: text editors, text editors enhanced with graphical tags, some wikis, etc.
2. WYSIWYG ("What-you-see-is-what-you-get") editing views: 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.
3. Object-oriented editing views: 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 (e.g., menu widgets) etc.
4. Guided editing views: Authors only have control over relatively high-level parameters that are used by the authoring tool to automatically generate the resulting Web content. This allows the author to create and organize Web content without having to author or even understand the underlying markup, structure, or programming implementation. Often the user interface is a form that the author fills out. Examples: content management systems, site building wizards, site management tools, courseware, blogging tools, content aggregators, conversion tools, model-based authoring tools, 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 [HTML4] and XML)

end user

A person who interacts with Web content once it has been authored. The author usually has the option to be the end user of the content they create, however some authoring tools increase the frequency of this switch (@@e.g., wikis).

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. Equivalent alternatives include text alternatives and synchronized alternatives.

1. Text alternatives present a text version of the information conveyed in non-text objects such as graphics and audio clips. The text alternative is considered accessible because it can be rendered in many different ways (e.g., as synthesized speech for individuals who have visual or learning disabilities, as Braille for individuals who are blind, as graphical text for individuals who are deaf or do not have a disability).
2. Accessible alternatives to multimedia present the same information as is conveyed in the multimedia via accessible text, navigation, forms, etc.
3. Synchronized alternatives present essential audio information visually (i.e., captions) and essential video information in an auditory manner (i.e., audio descriptions).

freeform drawing

Drawing actions that use the mouse or stylus in a continuous fashion (e.g., a paintbrush feature). This does not cover moving or resizing object-based graphics (including moving or resizing an object that is a previously authored freeform graphic).

general flash or red flash

Note: The general rule "flashes more than three times per second" can be substituted for the general and red flash thresholds below.

General flash threshold (Based on Wisconsin Computer Equivalence Algorithm for Flash Pattern Analysis (FPA)): A sequence of flashes or rapidly changing image sequences where all three of the following occur:

1. the combined area of flashes occurring concurrently (but not necessarily contiguously) occupies more than one quarter of any 341 x 256 pixel rectangle anywhere on the displayed screen area when the content is viewed at 1024 x 768 pixels;
2. there are more than three flashes within any one-second period; and
3. the flashing is below 50 Hz.

(Note: For the general flash threshold, a flash is defined as a pair of opposing changes in brightness of 10% or more of full scale white brightness, where brightness is calculated as 0.2126 * ((R / FS) ^ 2.2) + 0.7152 * ((G / FS) ^ 2.2) + 0.0722 * ((B / FS) ^ 2.2). R, G, and B are the red, green, and blue RGB values of the color; FS is the maximum possible full scale RGB value for R, G, and B (255 for eight bit color channels); and the "^" character is the exponentiation operator. An "opposing change" is an increase followed by a decrease, or a decrease followed by an increase. This applies only when the brightness of the darker image is below .80 of full scale white brightness.

Red flash threshold (Note: Based on Wisconsin Computer Equivalence Algorithm for Flash Pattern Analysis (FPA)): A transition to or from a saturated red where both of the following occur:

1. The combined area of flashes occurring concurrently occupies more than one quarter of any 341 x 256 pixel rectangle anywhere on the displayed screen area when the content is viewed at 1024 x 768 pixels.
2. There are more than three flashes within any one-second period.
3. The flashing is below 50 Hz.

inform

To make the author aware of something using methods such as an alert, prompt, sound, or flash. These methods may be unobtrusive (i.e., presented without stopping the authors' current activity) or intrusive (i.e., interrupting the author's current activity).

informative

"Non-normative" parts of this document that are never required for conformance.

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

markup language

A syntax and/or set of rules to manage markup (e.g., HTML [HTML4], SVG [SVG], or MathML [MATHML]).

multimedia

Audio or video synchronized with another type of media and/or with time-based interactive components.

non-text objects

Content objects that are not represented by text character(s) when rendered in a user agent (e.g., images, audio, video).

normative

Parts of this document that are always required for conformance.

platform

The software environment within which the authoring tool operates. For functionality that is not Web-based, this will be an operating system (e.g., Windows, MacOS, Linux), virtual machine (e.g., JVM) or a higher level GUI toolkit (e.g., Eclipse). For Web-based functionality, the term applies more generically to user agents in general, although for purposes of evaluating conformance to ATAG 2.0, a specific user agent(s) will be listed in the conformance profile.

plug-in

A program that runs as part of the authoring tool (e.g., a third-party evaluation and repair tool). Users generally choose to include or exclude plug-ins from their authoring tool.

presentation

The rendering of the content and structure in a form that can be perceived by the user.

preview

A non-editable view of the Web content that is intended to show how it will appear and behave in a user agent.

prominence

A heuristic measure of the degree to which authors are likely to notice controls 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 control include:

1. Control size (large controls or controls surrounded by extra white space may appear to be conferred higher importance),
2. Control order (items that occur early in the "localized" reading order (e.g., left to right and top to bottom; right to left and top to bottom) are conferred higher importance),
3. 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
4. Highlighting (controls may be distinguished from others using icons, color, styling).

prompt

In this document "prompt" refers to any authoring tool initiated request for a decision or piece of information 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, commiting a change in a wiki, etc.).

repairing, accessibility

The process by which Web content accessibility problems that have been identified within Web content are resolved. ATAG 2.0 identifies three types of repairing, based on increasing levels of automation:

1. Manual repairing in which the authoring tool only provides instructions for authors to follow in order to make the necessary correction;
2. Semi-Automated repairing, in which the authoring tool can provide some automated assistance to the author in performing corrections, but the author's input is still required before the repair can be completed; and
3. Automated repairing, in which the authoring tool is able to make repairs automatically, with no author input or confirmation from the author. An authoring tool may support any combination of repairing types.

reversible actions

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.

selectable items

Any items that an author may select from within the menus, toolbars, palettes, etc. (e.g., "open", "save", "emphasis", "check spelling")

structured element set

Content organized into lists, maps, hierarchies (e.g., tree views), graphs, etc.

transcript

A non-synchronized text alternative for the sounds, narration, and dialogue in an audio clip or the auditory track of a multimedia presentation. For a video, the transcript can also include the description of actions, body language, graphics, and scene changes of the visual track.

template selection mechanism

An authoring tool 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 as input, an object in one content type and produces as output, a different object in the same content type (e.g., a function that transforms tables into lists).

tutorial

A type of documentation that involves the sequential presentation of instructions for performing multi-part tasks.

user agent

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 rendering of Web content by an authoring tool. Authoring tool views are usually either editing views or previews.

Wisconsin Computer Equivalence Algorithm for Flash Pattern Analysis (FPA)

A method developed at the University of Wisconsin, working in conjunction with Dr. Graham Harding and Cambridge Research Associates, for applying the United Kingdom's "Ofcom Guidance Note on Flashing Images and Regular Patterns in Television (Re-issued as Ofcom Notes 25 July 2005)" to content displayed on a computer screen, such as Web pages and other computer content.
Note: The Ofcom Guidance Document [OFCOM] is based on the assumption that the television screen occupies the central ten degrees of vision. This is not accurate for a screen which is located in front of a person. The Wisconsin algorithm basically carries out the same analysis as the Ofcom Guidelines except that is does it on every possible ten degree window for a prototypical computer display.

workflow

A customary sequence of steps or tasks that are followed 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/WD-ATAG20-20070430/.
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).

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 "[HTML4]" 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/.

[ATAG20-TECHS]

"Techniques for Authoring Tool Accessibility 2.0", J. Treviranus, J. Richards, C. McCathieNevile, and M. May, eds., 22 November 2004. The latest draft of this W3C note is available at http://www.w3.org/TR/ATAG20-TECHS.

[COMPONENTS]

"Essential Components of Web Accessibility", S. L. Henry, ed. This document is available at http://www.w3.org/WAI/intro/components.

[CSS2-ACCESS]

"Accessibility Features of CSS," I. Jacobs and J. Brewer, eds., 4 August 1999. This W3C Note is available at http://www.w3.org/1999/08/NOTE-CSS-access-19990804. The latest version of Accessibility Features of CSS is available at http://www.w3.org/TR/CSS-access.

[HTML4]

"HTML 4.01 Recommendation", D. Raggett, A. Le Hors, and I. Jacobs, eds., 24 December 1999. This HTML 4.01 Recommendation is http://www.w3.org/TR/1999/REC-html401-19991224. The latest version of HTML 4 is available at http://www.w3.org/TR/html4.

[MATHML]

"Mathematical Markup Language", P. Ion and R. Miner, eds., 7 April 1998, revised 7 July 1999. This MathML 1.0 Recommendation is http://www.w3.org/1999/07/REC-MathML-19990707. The latest version of MathML 1.0 is available at http://www.w3.org/TR/REC-MathML.

[OFCOM]

Guidance Notes, Section 2: Harm and offence Annex 1, "Ofcom Guidance Note on Flashing Images and Regular Patterns in Television (Re-issued as Ofcom Notes 25 July 2005)" available at http://www.ofcom.org.uk/tv/ifi/guidance/bguidance/guidance2.pdf)

[PWD-USE-WEB]

"How People With Disabilities Use the Web", J. Brewer, ed., 4 January 2001. This document is available at http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/.

[SMIL-ACCESS]

"Accessibility Features of SMIL," M.-R. Koivunen and I. Jacobs, eds., 21 September 1999. This W3C Note is available at available at http://www.w3.org/TR/SMIL-access.

[SVG]

"Scalable Vector Graphics (SVG) 1.0 Specification (Working Draft)", J. Ferraiolo, ed. The latest version of the SVG specification is available at http://www.w3.org/TR/SVG.

[SVG-ACCESS]

"Accessibility of Scalable Vector Graphics," C. McCathieNevile, M.-R. Koivunen, eds., 7 August 2000. This W3C Note is available at http://www.w3.org/TR/SVG-access.

[WCAG10]

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

[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-GENERAL]

"General Techniques for WCAG 2.0," J. Slatin, T. Croucher, eds. Note: This document is still a working draft.

[WCAG20-TECHS-CSS]

"CSS Techniques for WCAG 2.0," W. Chisholm, B. Gibson, eds. Note: This document is still a working draft.

[WCAG20-TECHS-HTML]

"HTML Techniques for WCAG 2.0," M. Cooper, ed. Note: This document is still a working draft.

[UAAG]

"User Agent Accessibility Guidelines 1.0", I. Jacobs, J. Gunderson, E. Hansen, editors, 17 December 2002. This is a W3C Recommendation.

[WCAG20-TECHS-SCRIPTING]

"Client-side Scripting Techniques for WCAG 2.0," M. May, B. Gibson, eds. Note: This document is still a working draft.

[WCAG20-UNDERSTANDING]

"Understanding WCAG 2.0," B. Caldwell, W. Chisholm, J. Slatin, G. Vanderheiden, eds. Note: This document is still a working draft.

[XAG]

"XML Accessibility Guidelines", D. Dardailler, S. B. Palmer, C. McCathieNevile, eds. 3 October 2002. This is a Working Group Draft.

Appendix D: Acknowledgments

Participants active in the AUWG at the time of publication:

• Tim Boland (National Institute for Standards and Technology)
• Barry A. Feigenbaum (IBM)
• Greg Pisocky (Adobe)
• Jan Richards (Adaptive Technology Resource Centre, University of Toronto)
• Roberto Scano (IWA/HWG)
• Jutta Treviranus (WG Chair; Adaptive Technology Resource Centre, University of Toronto)

Other previously active AUWG participants and other contributors to WCAG 2.0

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