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 W3CWeb
Accessibility Initiative (WAI).

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

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.

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

authoring tool developers,

authoring tool users (authors),

authoring tool purchasers, and

policy makers.

technical administrators,

and those who develop or manage content.

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

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

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 checkpoints),

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

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 authors the same freedom of control as plain
text editing (e.g., graphical tag placeholders). Examples: text
editors, text editors enhanced with graphical tags, some wikis, 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 authors having control over the markup,
structure, or programming implementation. Examples: content
management systems, site building wizards, site management tools, courseware,
blogging tools, content aggregators, conversion tools, model-based
authoring tools, etc. @@JR: what if we changed
this to "Dialog-level" editing? Guided?@@

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

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

not be able to see, hear, move, or be able to process some types of information
easily or at all;

have difficulty reading or comprehending text;

not have or be able to use a keyboard or mouse;

have a text-only display, or a small screen.

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

Also consider that authors may not be familiar with the specific needs of
people with disabilities and will require support from the authoring tool
to fill the knowledge gap. @@work this in a bit
better@@

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.

Note that the references to WCAG are made without an associated
version number. This has been done to allow developers to select,
and record in the conformance profile, whichever
version of WCAG is most appropriate for the circumstances of a given authoring
tool. Consider the following when deciding which
WCAG version to use:

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 ATAG 2.0 requires published Web Content
Accessibility "Benchmark" documents, which may be based on
WCAG technique documents, if they are available.

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

How the guidelines
are organized

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

The guideline number.

The guideline title.

An explanation of the guideline.

A list of checkpoints for the guideline.

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

A pointer to implementation techniques for the checkpoint. (informative)

Success criteria for testing whether the checkpoint has been satisfied.
(normative)

PART A:
Make the authoring tool user interface accessible

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

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

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

Rationale:In
addition to generally improving the accessiblity of the authoring
tool user interface, implementing user interfaces using
accessible Web content facilitates communication with assistive
technologies via user agents. Authors
must be able to have access to Web-based authoring tool user interface
functionality just as they do to other Web content.

Note: For
non-Web-based authoring tools, this is a relatively straightforward
requirement, likely covering only a few areas of the interface (e.g.,
Web-based help features). However, for most Web-based authoring tools
the requirement will cover the majority of functionality in the tool
and overlap many of the other requirements in Part A of the guidelines.
When this is the case, a note entitled "For Web-based authoring
tool user interface functionality" will appear below the success
criteria to provide more information.

Any deviation from the proper use the implemented accessibility
platform architecture(s) (i.e., lack of use, incomplete
use, inappropriate use) as defined by the documentation for
the architecture must be publicly documented.

(a) a separate accessible
equivalent for that functionality that is supported by the
implemented accessibility
platform architecture(s) is provided and a description
of the inaccessible functionality appears in the conformance
claim.

(b) an alternative interoperability mechanism
(e.g., an extension to the implemented accessibility
platform architecture(s)) that enables the functionality
to be available to an assistive technology that used the
mechanism is implemented and publicly documented.

All of the following information must be
published about the implementation of the accessibility platform
architecture(s):

Rationale: People
who have difficulty perceiving non-text objects are often able to
access text alternatives of the same information, since text is more
easily transformed between various display methods (e.g., magnification
and enhancement, text-to-speech, Braille output)

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

A.1.3
For the authoring tool user interface, ensure that all display
preferences are configurable. [Priority 1]

Rationale: Some
authors require alternative display configurations to use the authoring
tool user interface that may differ from the
presentation the author intends to define for the published content
(e.g., providing a high contrast setting to edit content that is
not intended to be high contrast).

Note: The
success criteria for this checkpoint are based on the capabilities
of platforms (e.g.,
operating systems, user agents, GUI toolkits) as defined in the conformance
profile, however developers are free to provide additional configuration.

If the content display settings
are implemented within the authoring tool (option (b) above),
then the authoring tool must provide at least the
same configurable properties with at least the same configuration
ranges as the platform provides.

For editing
views that usually have their display characteristics set
by rendering the content being
edited (i.e., WYSWYGediting
views), the content display settings must override these
characteristics without affecting the content (e.g.,
markup, stylesheets, etc.) being edited.

If the user
interface "chrome" display settings are
implemented within the authoring tool (option (b) above),
then the authoring tool must provide at least the
same configurable properties with at least the same configuration
ranges as the platform provides.

If the visual display (e.g., fonts, sizes,
colors, spacing, positioning, contrast) is controlled by the
authoring tool rather than by the platform,
then the authoring tool must provide at least the same
configurable properties with at least the same configuration
ranges as the platform.

If the audio display (e.g., volume, speech
voices, voice speed, voice emphasis) is controlled by the authoring
tool rather than by the platform,
then the authoring tool must provide at least the same
configurable properties with at least the same configuration
ranges as the platform.

Editing
views that have their display characteristics set by rendering
the content being
edited (e.g., WYSWYGediting
views) must override these characteristics, if authors explicitly
set different visual or audio display preferences.

Any visual or audio display settings that
are set by the authoring tool must be saved between
authoring sessions.

A.1.4
For the authoring tool user interface, ensure changes to the display
settings of editing
views do not affect the content being
edited. [Priority 1]

Rationale: Authors
may require settings to render and control the content during editing
that differ from the presentation defined for the published content
(e.g., providing a high contrast setting to edit content that is
not intended to be high contrast).

A.1.5
For the authoring tool user interface, ensure that information, functionality,
and structure can be separated from presentation. [Priority
1]

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

GUIDELINE
A.2: Authoring Tool User Interface must be Operable

In order for an authoring tool to be accessible, authors with a wide
range of abilities must be able to operate its user interface controls.

A.2.1
For the authoring tool user interface, ensure that all functionality
is operable via a keyboard or a keyboard
interface. [Priority 1]

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

Note
1: This does not preclude and should not discourage the
support of other input methods (such as a mouse) in addition to
keyboard operation.

Authorsmust be
able, through keyboard input alone, to perform any authoring
task that is available through the authoring
tool user interface (e.g., navigating, selecting, and editing content within editing
views, operating the user interface "chrome", installing
and configuring the tool, and accessing documentation),
except freeform
drawing. This applies to at least one mechanism per task,
allowing non-keyboard accessible mechanisms to remain available
(e.g., inserting an image with an "insert image" menu
item vs. drag-and-dropping the image file's icon into the document).

Authorsmust have
the option to ensure that selection is separate from activation
(e.g., navigating through the items in a dropdown menu without
activating any of the items).

If the author has the option to modify
the keyboard operability settings,
any modifications must be saved between authoring sessions.

The current keyboard settings must be available
to authors at all times (e.g., central location such as a list,
distributed location such as associating shortcuts with menu
items).

The authoring tool must not interfere
with keyboard accessibility features of the platform (e.g.
StickyKeys, SlowKeys, browser link navigation)

If the authoring tool has no control over
a time limit (e.g,. loss of an external connection), but does
have advance notice, then the authoring tool must notify
the author when the advance notice is received, up to one minute
before the time limit expires.

If the authoring tool has some control over
a time limit (e.g., the authoring tool is mediating collaborative
authoring of the same content), then at least one of
the following must be true:

(a) Authors are
allowed to adjust the time limit over a wide range that is
at least ten times the length of the default setting and are
warned at least twenty seconds before time expires, or

(b) Authors are
warned before time expires and are given at least twenty seconds
to extend the time limit with a simple action (e.g., "hit
any key"), and are allowed to extend the time limit at
least ten times.

If the authoring tool has full control
over a time limit (e.g. logging an author off after a period
of inactivity, presenting options as a slide show, etc.), then at
least one of the following must be true:

(b) Authors are allowed to
adjust the time limit over a wide range that is at least
ten times the length of the default setting and
are warned at least twenty seconds before time expires,
or

(c) Authors are
warned before time expires and are given at least twenty
seconds to extend the time limit with a simple action (e.g., "hit
any key"), and are allowed to extend the time limit
indefinitely.

Rationale: It
is often efficient to make use of the structure that may be inherent
within certain content in order to navigate editing views and perform
edits. This is particularly important for people who are using a
slow interface such as a small Braille device, speech output, or
a single switch input device. It is equivalent to the ability provided
by a mouse interface to move rapidly around the document.

A.2.6 For
the authoring tool user interface, provide
text search of content,
including markup, within the editing
views. [Priority 2]

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

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

Author actions
that modify contentmust be
either reversible by an "undo" function or include
a warning to the author that the action is irreversible. An authoring
tool may have certain committing actions (e.g., "save" function)
that reset the undo history.

If the most recent author action is a reversible
action, an undo function must be provided that
is able to reverse up to 5 consecutive reversible actions.
Web-based authoring tools may rely on the "undo" function
of the user
agent to undo certain client-side author actions.

Authorsmust be
able to immediately reverse the most recent undos (i.e., a "redo" function). @@JR:
if we want redo, let's put it in a new checkpoint@@

Rationale: Providing
the ability to save and reload sets of keyboard and display preference
settings is a benefit to authors using tools intended to be used
by multiple authors as well as authors who have keyboard and display
preference settings preferences that differ with fatigue, etc..

Rationale: Preview features
are provided in many authoring tools because the workflow of
authors often includes periodically checking how content will appear
to end users in
a user agent. In order to enable authors with disabilities to follow
the same workflow as other authors, they must have access to any
preview features that exist.

Note
1: Authors, including those with disabilities, will not
be well-served if preview features
diverge too much from the actual functionality of available user
agents. Therefore, preview features are exempted from necessarily
having to meet all of the other requirements in Part A of this
guidelines document, if they meet this checkpoint.

Note
2: It is understood that the accessibility of the content
display of a preview will
be negatively affected if the content being rendered is inaccessible
or incomplete. For example, a missing image label will result in
an inaccessible image, which is useful information to the author.

If a previewfeature is
provided, then a mechanism for returning
from the preview (i.e., moving focus back from, exiting from) must be
provided that meets Checkpoint
A.2.1 and is documented in the help system.

If a preview is
provided, then it must meet at
least one of the following:

(a) the preview makes
use of an existing user
agent (e.g., opening the content
in a third-party browser or browser component), or

(b) the preview meets
all of the Priority 1 checkpoints
in Part A of these guidelines,
or

GUIDELINE
A.3: Authoring Tool User Interface must be Understandable

In order for an authoring tool to be accessible, authors with a wide
range of abilities must be able to understand the user interface controls
that they can perceive and operate.

A.3.1
For the authoring tool user interface, observe the accessibility conventions
of the platform. [Priority
2]

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

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.

User
interface "chrome" controls that are identified
by the same text label or icon mustalways perform
the same function (e.g. if a clipboard
icon is used to label a "paste" function, the same
or similar icon should not be used to label a "note taking" function).

When the same function (e.g., saving, running a checker or
canceling an action) is available in multiple places within the user
interface "chrome" (e.g., on multiple windows),
at least one method of controlling the function must be
available in each place using the same text label or icon.

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

All features of the user interface "chrome" that
are specifically required to meet Part
Aof these gudielines (e.g.
keyboard shortcuts, text search, etc.) must be documented.

PART
B: Support the production of accessible content

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

GUIDELINE
B.1: Enable the production of accessible content

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

(b) if the accessibility
information cannot be preserved, notify authors and
keep a copy in the original form (e.g., by commenting out
a table converted into a list, by saving a document prior
to converting it into a different format).

B.1.3
Ensure that authors are
notified before content is
automatically removed. [Priority 2]

Rationale: Automatically
removing markup can cause the unintentional loss of structural information.
Even unrecognized markup may have accessibility value, since it may
include recent technologies that have been added to enhance accessibility.

Any content that
is generated by the authoring tool must meet the requirements
in the Web content accessibility
benchmark, unless this results directly from author input
to the process (e.g., author adds inaccessible markup directly
to a code-level editing view, author chooses poor color combinations,
etc.)All content that
is automatically generated by the authoring tool (i.e., not authored "by
hand") must conform to WCAG.

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.

Any content (e.g., templates,
clip art, graphical widgets) that is bundled with the
authoring tool or preferentially licensed to the users of the
authoring tool (i.e., provided for free or sold at a discount) mustmeet
the requirements in the Web content
accessibility benchmark when used by the author. @@JR:
Maybe this should be changed to make it a bit more clear who
needs to be offering the discount@@

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

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

An individual check must be associated with each requirement
in the Web content
accessibility benchmark. A
blanket question such as "does the page meet all of the
requirements?" is not acceptable .

For checks that are associated with a type of element (e.g., img),
each element instance must be individually identified
as a potential accessibility
problem.

For checks that are relevant
across multiple elements (e.g., consistent navigation) or apply
to most or all elements (e.g., background color contrast, reading
level), the entire span of applicable elements must be
identified as a potential accessibility problem,
up to the entire content if
applicable.

For checks that required author judgement to
determine if a potential accessibility
problem is correctly identified, the message to authorsmust be
tailored to that potential accessibility problem (i.e., to that
requirement in the context of that element or
span of elements).

(Text
alternatives should not be generated from unreliable sources.
File names are generally not acceptable, although in some cases
they will be (e.g., if they store alternatives previously entered
by authors).)

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

A tutorial on
the accessible authoring process that is specific to the tool must be
provided.

GUIDELINE
B.3: Promote and integrate accessibility solutions

This guideline includes checkpoints that require
authoring tools to raise the profile of accessible authoring, while
at the same time, integrating functions related to accessibility in
order to encourage authors to make them common practice. The
checkpoints address the visibility of accessible
authoring practices within the tool as well as smoothly integrate features
that support accessible authoring that have been added to meet
the other requirements in this document.

Note: In addition to the normative requirements of
this guideline, implementers should also consider close
integration of features
that support accessible authoringwith 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.

If the authoring tool provides more than
one authoring
action that achieves the same authoring
outcome (e.g., styling page headings), then any of these
actions that utilize accessible
authoring practices (e.g.,
using styled header markup) must be at least as prominent as
any of these action(s) that do not (e.g., using presentation
rather than header markup).

Any choices of content
types or authoring option presented to the author (e.g.,
in menus, toolbars or dialogs) that will lead to the creation
of content that
does not conform to WCAGmust be
marked or labeled so that the author is aware of the consequences
prior to making the choice.@@JR:
Moved to B.2.1@@

Interactive features that sequence author actions (e.g., object
insertion dialogs, templates, wizards) must provide
any accessibility prompts relevant
to the content being
authored at or before the first opportunity to successfully complete
the interactive feature.

Instruction
text (e.g., tutorials, reference
manuals, design guides) that includes a sequence of steps for authors to
follow must include the relevant accessibility
authoring practicesin the step sequence
before the first opportunity to successfully complete
the sequence.

Accessible
content support featuresmusthave prominence that
matches or exceeds that of any corresponding features
related to other types of
Web content problems (e.g., invalid
markup, syntax errors, spelling and grammar errors).

B.3.6
Ensure that any authoring practices demonstrated in repair instructions
and documentation are accessible. [Priority
3]

Rationale:Demonstrating
accessible authoring as
common practice will encourage its acceptance by some authors. It
can also facilitate a better understanding of the reasoning behind
and the benefits of authoring
accessible content.

Any examples of authoring practices
in repair instructions or documentation (e.g.,
markup for code-level editing views, screenshots for WYSIWYG
editing views) must demonstrate accessible
authoring practices. An exception is allowed
for examples that are specifically
intended to show inaccessible practices to be
avoided.

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

Web
Content Accessibility "Benchmark"

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

What does a Web Content Accessibility Benchmark include?

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

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.

The version and URI of the Web Content Accessibility
Guidelines that is being used as a basis for the Benchmark (e.g., "WCAG
2.0 Working Draft, http://www.w3.org/TR/WCAG20/") (See Note
on other Accessibility Standards).

The target level of the Benchmark. This is
the WCAG conformance level that would be met by Web content that implemented
all of the techniques in the Benchmark. There are three (3) possible levels:

The Benchmark techniques:
For each normative requirement of WCAG at the target level, one of the
following must be provided:

at least one technique for meeting the normative requirement (e.g.,
for a minimum level Benchmark, a technique for each Level 1 WCAG 2.0
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. @@JR:
???@@

Is a Web Content Accessibility Benchmark normative?

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

Who can create a Web Content Accessibility Benchmark?

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

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

Conformance Levels

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

ATAG 2.0 Conformance at Level "A"
The authoring tool has satisfied the success criteria for all of
the Priority 1 checkpoints.

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

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

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

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

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

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

Conformance
Claims

Conditions on Conformance
Claims

At least one version of the conformance claim must be published on the
Web as a document meeting a minimumum
level 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

The name of the authoring tool and sufficient additional information
to specify the version (e.g., vendor name, version number, minor release
number, required patches or updates, natural language of the user interface
or documentation).

The version information may refer to a range of tools (e.g., "this
claim refers to version 6.x").

If the authoring tool is a collection
of software component (e.g., a markup editor, an image editor,
and a validation tool), then information must be provided separately
for each component, although the conformance claim will treat them
as a whole.

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.

A description of how the normative ATAG 2.0 success criteria were met
for each of the checkpoints that are required for the conformance level
specified by the conformance profile. In
some cases, this includes describing how the Web
content accessibility benchmark techniques were implemented.

Any additional information about the tool, including progress towards
the next conformance level.

"Progress
Towards Conformance" Statement

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

Appendices

Appendix A: Glossary

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

A user interface mechanism that makes authors aware
of events or actions that require a response. The author response is not
necessarily required immediately. The events or actions that trigger an
alert may have serious consequences if ignored.

Anequivalent
alternative that provides auditory information about actions, body
language, graphics, and scene changes in a video. Audio descriptions
are commonly used by people who are blind or have low vision, although
they may also be used as a low-bandwidth equivalent on the Web. An audio
description is either a pre-recorded human voice or a synthesized voice
(recorded or automatically generated in real time). The audio description
must be synchronized with the auditory track of a video presentation,
usually with descriptions occurring during natural pauses in the auditory
track.

author

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

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

authoring
action

Any action that the author takes
using the authoring
tool user interface with the intention of adding or modifying Web
content (e.g., typing text, inserting an element, launching a wizard;
but not resizing windows, viewing help, etc.).

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.

The
display and control mechanism that authors use
to communicate with and operate the authoring tool software. Authoring
tool user interfaces may be non-Web-Based or Web-based (e.g.,
on-line content management system) or a combination of both (e.g., non-Web-based
markup editor with on-line help pages). Authoring tool user interfaces
can usefully be considered in two parts:

Content
display: The tool's rendering of the content being edited
in an editing
view or previewed in a preview.
Examples include:

Capable of providing information to other software
(including assistive technologies) by following relevant accessibility
platform architectures (e.g., MSAA, Java Access) or, if the available accessibility
platform architectures are insufficient, following some other published
interoperability mechanism (custom-created by the developer, if necessary).

Equivalent
alternatives that consist of a text transcript of the auditory track
of a movie (or other video presentation) and that is synchronized with
the video and auditory tracks. Captions are generally rendered graphically.
They benefit people who are deaf or hard-of-hearing, and anyone who cannot
hear the audio (for example, someone in a noisy environment).

manual
checking in which the authoring tool only provides instructions
for authors to follow in order to identify problems;

semi-automated
checking in which the authoring tool is able to identify potential
problems, but still requires human judgment by the author to
make a final decision on whether an actual problem exists; and

automated
checking in which the authoring tool is able to check for problems
automatically, with no human intervention required. An authoring tool may
support any combination of checking types.

collection
of software components

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

completion
of authoring

The point in time at which an authoring session
ends and the author has no opportunity to make further changes. This may
be when an author chooses to "save and exit", or "publish",
or it may occur automatically at the end of a wizard, etc.

content type

A data format, programming or markup language that
is intended to be retrieved and rendered by a user
agent (e.g., HTML, CSS, SVG, PNG, PDF, Flash, JavaScript or combinations). The
usage of the term is a subset of WCAG 2.0's [WCAG20] current
usage of the term "Technology".

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.

Content that is an acceptable substitute
for other content that a person may not be able to access. An equivalent
alternative fulfills essentially the same function or purpose as the original
content upon presentation. Equivalent alternatives include text alternatives
and synchronized alternatives.

Text
alternatives present a text version of the information conveyed
in non-text objects such as graphics and audio clips. The text alternative
is considered accessible because it can be rendered in many different ways
(e.g., as synthesized speech for individuals who have visual or learning
disabilities, as Braille for individuals who are blind, as graphical text
for individuals who are deaf or do not have a disability).

Accessible
alternatives to multimedia present the same information
as is conveyed in the multimedia via
accessible text, navigation, forms, etc.

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

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;

there are more than three flashes within any one-second period; and

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.

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.

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

informative

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

keyboard
interface

Interface used by software to obtain keystroke input.

Note 1: Allows users to provide keystroke input to programs
even if the native technology does not contain a keyboard (e.g., a touch
screen PDA has a keyboard interface built into its operating system as
well as a connector for external keyboards. Applications on the PDA can
use the interface to obtain keyboard input either from an external keyboard
or from other applications that provide simulated keyboard output, such
as handwriting interpreters or speech to text applications with "keyboard
emulation" functionality).

Note 2: Operation of the application (or parts of the
application) through a keyboard operated mouse emulator, such as MouseKeys,
does not qualify as operation through a keyboard interface because operation
of the program is through its pointing device interface - not through its
keyboard interface.

markup

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

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 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 interfacewhen operating the authoring tool.
In this document, prominence refers to visual as well as keyboard-driven
navigation. Some of the factors that contribute to the prominence of
a control include:

Control size (large controls or controls surrounded
by extra white space may appear to be conferred higher importance),

Control order (items
that occur early in the "localized" reading order (e.g., left
to right and top to bottom; right to left and top to bottom) are conferred
higher importance),

Control grouping (grouping controls
together can change the reading order and the related judgments of importance),

advanced
options (when the properties are explicitly or implicitly grouped
into sets of basic and advanced properties, the basic properties may
gain apparent importance), and

Highlighting (controls
may be distinguished from others using icons, color, styling).

Manual repairing
in which the authoring tool only provides instructions for authors to
follow in order to make the necessary correction;

Semi-Automated repairing,
in which the authoring tool can provide some automated assistance to
the author in performing corrections, but the author's input is still
required before the repair can be completed; and

Automated repairing,
in which the authoring tool is able to make repairs automatically, with
no author input
or confirmation from the author. An authoring tool may support any combination
of repairing types.

reversible
actions

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 incude certain
save and delete actions as well as actions made in a collaborative environment
that another author has begun to work with.

selectable
items

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

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.

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.

Any material in a content
type. If the content type is a markup
language, then "content" covers the information both within
the tags (i.e., the markup)
and between them. In this document, "content" is primarily
used in the context of the material that is authored and outputted by authoring
tools.

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

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

References to a specific version of "Authoring Tool Accessibility
Guidelines 2.0." For example, use the "this version" URI to
refer to the current document: http://www.w3.org/TR/2006/WD-ATAG20-20061207/.

References to the latest version of "Authoring Tool Accessibility
Guidelines 2.0." Use the "latest version" URI to refer to
the most recently published document in the series: http://www.w3.org/TR/ATAG20/.

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

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

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

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.