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

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

W3C Public Working Draft
of ATAG 2.0

This is the W3C Working Draft of 12 February
2009. This draft synchronizes with the recently finalized WCAG 2.0, improves clarity, and corrects misplaced text. The Working Group is
still seeking feedback on the substantive changes of the 24 November 2008
Working Draft which included:

The Working Group refocused Part A ("Make the authoring tool user interface accessible")
on requirements that apply most specifically to Web content authoring
tools and away from generic accessibility guidelines. Instead, ATAG 2.0
will continue to require WCAG conformance for Web-based authoring tools
and will add a requirement to follow standards and/or platform
conventions that benefit accessibility for non-Web-based tools. This
change will let the Working Group keep a focus on authoring tools and
avoid the need to repeat operating system specific information that is
already available elsewhere.

The Working Group replaced the concept of "Web Content Accessibility Benchmark" with a
more straightforward relationship with WCAG 2.0. This has been made
possible by the progression of WCAG 2.0 to Candidate Recommendation
status on 30 April 2008.

The Working Group still seeks feedback on the following points from the 24 November 2008 draft:

Does the refocused Part A provide developers with sufficient guidance
on what must be done to ensure accessibility of authoring tools to
authors with disabilities?

Does the more direct relationship with WCAG 2.0 make the ATAG 2.0
requirements more clear?

May be
Superseded

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

Web Accessibility Initiative

No
Endorsement

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

This is a Working Draft of the Authoring Tool Accessibility Guidelines
(ATAG) version 2.0. This document includes recommendations for assisting
developers to make the authoring tools they develop more
accessible to people with disabilities, including blindness and low vision,
deafness and hearing loss, learning disabilities, cognitive limitations,
motor difficulties, speech difficulties, and others. However, even authoring
tools that conform to ATAG 2.0 may not be able to address the needs of people
with all types, degrees and combinations of disabilities.

In order to achieve accessibility, authoring tools must address the needs
of two (potentially overlapping) user groups with disabilities:

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 with disabilities (see Part B of the
guidelines).

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

As ATAG 2.0 guides authors in complying to WCAG 2.0, similar to the
constraints of WCAG 2.0, even content that conforms at the highest level
(AAA) will not be accessible to individuals with all types, degrees, or
combinations of disability, particularly in the cognitive language and
learning areas. Creation of authoring tools that fully address the
specialized needs of these communities for is encouraged, but is beyond the
scope of this document.

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

Integration of Accessibility Features

When implementing ATAG 2.0, the Working Group suggests that developers should consider close integration of
features that support accessible authoring with the "look-and-feel" of other
features of the authoring tool. This type of integration has the potential
to:

produce a more seamless product;

leverage the existing knowledge and skills of authors;

make authors more receptive to new accessibility-related authoring
requirements; and

ATAG 2.0 defines an "authoring tool" as any application, part of
an application, or collection of applications that authors interact with to create, modify or assemble
Web content to be used by other people.

The definition applies to all or part of the following types of
applications:

Notes on the Definition:

Any guidelines that require authors to modify content in some way
always assumes that the person has author permission.

Live content authoring tools (e.g., chats, collaboration tools,
whiteboards, etc.) are only required to meet Part A. However, many
guidelines in Part B may still usefully apply, especially if the tool
archives as Web content. For more information, please see the Techniques
- Appendix E: Real-time content production.

Components of Web
Accessibility

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

Accessibility solutions
must be promoted and integrated -Authoring tools should
encourage the author's awareness and discovery of tools, features, or
functions that support accessible authoring practices, while at the same
time, integrating functions related to accessibility in order to ensure
that authors make them common practice.

Note: While the requirements in Part B do not deal with
the accessibility of the authoring tool user interface per se, it
should be noted that any of the features (e.g., checker, tutorial) added to
an authoring tool to meet the Part B success criteria must also meet the user
interface accessibility requirements of Part
A.

Success Criteria

Under each guideline there are success criteria that describe specifically
what must be achieved in order to conform. They are similar to the
"checkpoints" in ATAG 1.0. Each success criterion is written as a statement
that will be either true or false when a specific authoring tool is tested against it.
While all of the ATAG 2.0 success criteria are written to be testable and
some test automation may be possible, human testing will usually be required.
In order to meet the needs of different groups and different situations,
three levels of conformance are defined: A (lowest), AA, and AAA
(highest).

Each of the success criteria has a link to the Techniques document that
provides:

"Sufficient" techniques for meeting the success criteria, and

optional "Advisory" techniques.

Note: Any success criteria that are judged not applicable
to a particular authoring tool are treated as satisfied for conformance
purposes, as long as a rationale is provided.

Levels of
Conformance

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

Full ATAG 2.0 Conformance at Level "A"
The authoring tool satisfies all of the Level A success
criteria.

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

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:

Partial ATAG 2.0 Conformance Level "A": Authoring Tool User
InterfaceThe authoring tool satisfies all of the Level A success
criteria in Part A. Nothing is claimed about Part B.

Partial ATAG 2.0 Conformance Level "Double-A": Authoring Tool
User InterfaceThe authoring tool satisfies all of the Level A and
Level AA success criteria in Part A. Nothing is claimed about Part B.

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.

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.

Partial ATAG 2.0 Conformance Level "Triple-A": Content
Production"The authoring tool satisfies all of the success
criteria in Part B. Nothing is claimed about Part A.

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

Relationship to the Web
Content Accessibility Guidelines (WCAG)

ATAG 2.0 is intended to be used in conjunction with WCAG 2.0 or similar
Web content accessibility guidance (e.g., WCAG 1.0, regulations that include
WCAG 2.0, etc.).

The relationship is as follows:

The normative requirements of ATAG 2.0 have been formulated to apply to
many different types of authoring tools that in turn may produce a range
of Web content technologies.

ATAG 2.0 points to the WCAG 2.0 success criteria in order to define the
ATAG 2.0 concept of "accessible authoring practices", which authoring
tools are required to support in various ways.

The normative requirements of WCAG are themselves not
technology-specific. However, specific informative guidance for
satisfying the success criteria for particular Web content technologies
are provided in separate documents.

ATAG 2.0 Conformance Claims are supported by WCAG-conforming examples
of Web content produced by the authoring tool (e.g., samples of
automatically-generated content).

ATAG 2.0
Guidelines

The success criteria and applicability notes in this section are normative.

PART A: Make
the authoring tool user interface accessible

Applicability Notes:

Scope: The success criteria in Part A
apply to all aspects of the authoring tool user interface that are under the
control of the developer. This includes
functionalities that are independent of the content being edited, such as what is
sometimes referred to as the authoring tool's "chrome" (e.g., menus, button
bars, status bars, etc.) and also user preferences and documentation, etc. In
addition, the developers' responsibility covers certain aspects of other
functionalities that reflect the content being edited (e.g., ensuring that an
image label present in the content is available programmatically). However,
where an accessibility
problem in the user interface is caused directly by an accessibility
problem in the content it is reflecting (e.g., if an image in the content
lacks a label), then this would not be considered a deficiency in the
accessibility of the authoring tool user interface.

PRINCIPLE A.2: Editing views must be
perceivable

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

Rationale:Authors need to have access to and control over both
the functional significance of presentation and also, in the context of
authoring, the presentation that will be experienced by the end user. This is especially important for user
interface components that do not implement an accessibility platform
architecture or leverage existing implementations (e.g. custom user interface
components built via JavaScript and CSS). Some authors require display settings that differ from the
presentation that they intend to define for
the published content (e.g., using a high
contrast setting during editing content that is not intended to be high
contrast).

A.2.2.1 Purpose of Added
Presentation: If the authoring tool modifies the presentation of the content being edited, then the functional
purpose for the modification is made available via the platform (e.g., if misspelled text is underlined,
the fact that it is misspelled is made available). (Level A)

A.2.2.2 Access to Text Presentation
(Minimum): If an editing view (e.g.,
WYSIWYG) renders any of the following text presentation properties and those
properties are editable by any editing view (e.g., instruction level), then the properties are
made available via the platform (Level A):

(a) font,

(b) style (e.g., italic, bold),

(c) color, and

(d) size.

A.2.2.3 Access to Text Presentation
(Enhanced): Any text presentation properties (text size,
positioning, etc.) that are rendered in an editing view (e.g., WYSIWYG) and
are editable by any editing view are available via the platform. (Level
AAA)

Guideline A.2.3: Ensure the independence of the
authors' display preferences.

Rationale: Some authors will require
display settings that differ from the presentation that they intend to define
for the published content (e.g., an author uses large fonts for themselves,
while editing content that is not intended to have a large font in the final
content).

PRINCIPLE A.3: Editing views must be operable

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

A.3.1.1 Important Command
Functions: If the authoring tool includes any of the following
functions, authors can enable key-plus-modifier-key (or single-key) access to
them (where allowed by the operating environment) (Level A):

A.3.4.2 Navigate By Element
Type: If an editing view displays a structured element set, authors
can move the editing focus forward/backward to the next identical element.
(Level AA)

A.3.4.3 Navigate By
Headings: If an editing view displays a structured element set,
authors can move the editing focus forward/backward to the heading,
regardless of level. (Level AA)

A.3.4.4 Navigate Tree
Structures: If an editing view displays a structured element set,
authors can, with a simple action, move the editing focus from any element to
other elements in the set with any of the following relationships (if they
exist) (Level AA):

(a) Parent: the element immediately
above,

(b) Child: the first element
immediately below,

(c) Previous Sibling: the element
immediately preceding at the same level, and

(d) Next Sibling: the element
immediately following at the same level.

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

A.3.6.1 Save Settings:
Preference settings are stored for any of the following that the authoring
tool controls (i.e., not controlled by the platform) (Level AA):

A.3.6.2 Multiple Sets:
Choosing between multiple sets of preferences (e.g., personal profiles,
personal settings) are supported for any of the following that the authoring
tool controls (i.e., not controlled by the platform) (Level AAA):

Rationale: Preview features are provided in many
authoring tools because the workflow of authors often includes periodically checking how
content will appear to end users in a user agent. Authors with disabilities need
to be able to follow the same workflow.

Note: Previews are treated differently
than editing views because authors, including
those with disabilities, will not be well-served if preview features diverge
too much from the actual functionality of available user agents. Therefore,
preview features are exempted from necessarily having to meet all of the
other requirements in Part A of this
guidelines document, if they meet this guideline.

A.3.7.1 Return Mechanism:
If a preview is
provided, then it is possible to return from the preview using a simple
action which is documented in the help system. (Level A)

A.3.7.2 Preview: If a
preview is provided, then it meets at least one of the following (Level
A):

(a) Existing User Agent: the preview
makes use of an existing user agent that is specified in the conformance profile (e.g., opening the content
in a third-party browser, browser component, video player, etc.)

(b) Part A.1: the preview meets all of
the Level A guidelines in Principle
A.1 of these guidelines, or

Applicability Notes:

PART
B: Support the production of accessible content

Applicability Notes:

Authors Availability: Any success
criteria in Part B that refer to authors only apply during authoring
sessions when authors are available.

Responsibility After Authoring
Sessions: Authoring tools are not responsible for accessibility
problems that result from carrying out instructions made by the author
during authoring sessions (e.g., the content of a third-party feed
specified by the author), but they are responsible if the changes are
automatically generated (e.g., the developer makes site wide changes to a
CMS).

Existing Technologies: The success
criteria in Part B only apply to support for accessible authoring
practices that are relevant to technologies that the authoring tool
already has the ability to create or edit. For example, a markup
authoring tool that adds images by simply linking to their URIs would be
required to support the production of alternative text for images in the
markup, but it would not be required to add image editing functionality
to ensure sufficient contrast in case any images are of text.

Authoring Systems: As per the
definition of authoring tool, several software tools can be used in
conjunction to meet the requirements of Part B. (e.g. a authoring tool
could make use of a 3rd party software accessibility checking and repair
program.

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

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

Rationale: Choosing
technologies which support the possibility of accessible authoring is the
first step in ensuring that the content produced is accessible.

B.1.1.2 Author Choice of
Technologies (Level A): If the authoring tool provides authors with
Web content technology options, technology options that can conform to WCAG
Level A are listed with at least as much prominence as any other options and
the tool guides the author towards the most accessible technology for the
task. (Level A)

B.1.1.4 Author Choice of
Technologies (Level AA): If the authoring tool provides authors with
Web content technology options, technology options that can conform to WCAG
Level AA are listed with at least as much prominence as any other options and
the tool guides the author towards the most accessible technology for the
task. (Level AA)

B.1.1.6 Author Choice of
Technologies (Level AAA): If the authoring tool provides authors
with Web content technology options, technology options that can conform to
WCAG Level AAA are listed with at least as much prominence as any other
options and the tool guides the author towards the most accessible technology
for the task. (Level AAA)

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

B.1.2.1 Target Preserves
Accessibility Information : If the target technology of the
transformation or conversion can preserve *recognized* accessibility
information that is required for that content to conform to WCAG Level A,
then the accessibility information is preserved and available for end users
in the resulting content. (Level A)

B.1.2.x Target Cannot Preserve
Accessibility Information: If the target technology of the
transformation or conversion cannot preserve *recognized* accessibility
information that is required for that content to conform to WCAG Level A,
then the authoring tool (Level A):

provides the author with the option to retain the information in
another way if possible (e.g., as a "comment", by saving a backup copy)
and

notifies the author that this will result in accessibility problems in
the target.

B.1.2.2 Accessibility Information
Preservation (Enhanced): If the authoring tool performs transformations or conversions
during an authoring session, then any accessibility information in the
pre-transformation/conversion content that is required for content to
conform to WCAG Level AA or AAA is preserved and available for end users in the
resulting content. (Level AA)

B.1.2.3 Notification Prior to
Deletion: If the authoring tool automatically deletes any author-generated content for
any reason, then at least one of the following is true (Level AA):

(a) Preserve Accessibility Information:
the authoring tool only automatically deletes content that it can detect
is not accessibility
information;

(b) Notification Option: authors have
the option to receive notification before deletion; or

(c) No Deletion Option: authors have
the option to turn off the automatic deletion.

Applicability Notes:

If an authoring tool performs transformations or conversions after an authoring session ends (e.g., a batch
maintenance process) only option (a) is allowed for both B.1.2.1 and B.1.2.3.

Applicability Notes:

This guideline applies to the automated behavior specified by the
authoring tool developer under the
assumption that authors will respond properly
to any prompts.

The guideline does not apply when actions of the authors prevent generation of accessible content
(e.g., by setting less strict preferences, ignoring prompts for accessibility
information, providing faulty information, writing their own
automated scripts, etc.).

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

Applicability
Notes:

Principle B.2 applies to authoring tool processes that interact with
human authors, and the authoring choices that author is making or the
authoring choices under the control of the authoring tool. Authoring
choices include choice of style sheets, templates, scripts, etc

B.2.1.1 Guide Accessible (Level
A): If authors
are prompted for any information as content is being added or updated (e.g.,
by an image modification dialog), then the tool also prominently prompts for any accessibility information
required for that content to meet WCAG Level A (Level A).

B.2.1.3 Guide Accessible (Level
AA): If authors are prompted for any information as content is being
added or updated, then the tool also prominently prompts for accessibility
information required for that content to meet WCAG Level AA. (Level AA)

B.2.1.5 Guide Accessible (Level
AAA): If authors are prompted for any information as content is
being added or updated, then the tool also prominently prompts for
accessibility information required for that content to meet WCAG Level AAA.
(Level AAA)

B.2.2.1 Check Accessibility (Level
A): At least one individual check is associated with each WCAG Level
A Success Criterion that the tool has the functionality to modify (e.g., a
tool that inserts images should check for alt text; a tool that can edit
captions should check for them). (Level A)

B.2.2.2 Availability:
Checking is available prior to publishing in a
manner appropriate to the workflow of the authoring tool. (Level A)

B.2.2.5 Check Accessibility (Level AA): At least one
individual check is associated with each WCAG Level AA Success Criterion that
the tool has the functionality to modify. (Level AA)

B.2.2.6 View Status: If the
authoring tool records accessibility problems found during checking, then a
list of any accessibility problems is available to authors prior to the end
of the authoring session. (Level AA)

B.2.2.7 Save Status for
Repair: If repair assistance is not provided during checking ,
authors have the option to save the list to facilitate interoperability
between checking and repair. (Level AA)

B.2.2.8 Metadata for
Discovery: If the authoring tool records accessibility status, then
authors have the option to associate this status with the content as metadata
to facilitate resource discovery by end users. (Level AA)

B.2.2.9 Check Accessibility (Level AAA): At least one
individual check is associated with each WCAG Level AAA Success Criterion
that the tool has the functionality to modify. (Level AAA)

B.2.5.5 New Templates: If
authors can use the authoring tool to create new templates for use by a
template selection mechanism, they have the option to record the
accessibility status of the new templates. (Level AA)

B.2.5.6 Templates in
Repository: If the authoring tool provides a repository of
templates, then each of the templates has a recorded accessibility status.
(Level AA)

B.2.5.7 Pre-Authored Content
Selection Mechanism: If authors are provided with a selection
mechanism for pre-authored content other than templates (e.g., clip art
gallery, widget repository, design themes), then both of the following are
true (Level AA):

(a) Indicate: the selection mechanism
indicates the accessibility status of the pre-authored content.

(b) Prominence: any accessible options
have prominence that is comparable with
that of other options in the selection mechanism.

B.2.5.8 Pre-Authored Content in
Repository: If the authoring tool provides a repository of
pre-authored content, then each of the content objects has a recorded
accessibility status. (Level AA)

Applicability Notes:

Templates may be complicated to check for
accessibility due to their inherent incompleteness. The accessibility status
of templates is instead measured by the accessibility of content (in the
final technology) created through
their proper use.

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

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

B.3.1.1 Accessible Options Prominent
(Level A): If authors are provided with
multiple options for an authoring task, give equal or greater prominence to any
options that will result in content conforming to *WCAG* Level A.

B.3.1.1 Accessible Options Prominent
(Level AA): If authors are provided with
multiple options for an authoring task, give equal or greater prominence to any
options that will result in content conforming to *WCAG* Level AA.

B.3.1.1 Accessible Options Prominent
(Level AAA): If authors are provided with
multiple options for an authoring task, give equal or greater prominence to any
options that will result in content conforming to *WCAG* Level AAA.

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

B.3.2.1 Sequencing
Features: Function that sequences authoring actions for authors (e.g., wizards) provide any accessibility prompts relevant to the content being
edited at or before the first opportunity to successfully complete the
function. (Level AA)

B.3.2.2 Sequenced
Instructions: Instructions (e.g., tutorials, reference manuals, design guides) that
consist of a sequence of steps for authors to follow include the relevant accessibility authoring
practices in the sequence before the first opportunity to successfully
complete the sequence. (Level AA)

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

B.3.3.2 Reactivate Option:
If authors deactivate an
accessible content support feature, then they can always reactivate the
feature. (Level A)

B.3.3.3 Deactivation
Warning: If authors deactivate an
accessible content support feature, then the authoring tool informs them that
this may increase the risk of content accessibility
problems. (Level AA)

Conformance
Claims

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., product
information website), 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
(including claims that include products for which they are not
responsible) 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 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. Note: The burden is on the conformance claimant rather
than the developer of any of the software components.

Optional Components of an ATAG 2.0
Conformance Claim

A description of the authoring tool that identifies
the types of editing views that it
includes.

A description of how the 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 that has
not been published under the authority of the W3C, WAI, or WAI-AUWG.

Appendix A: Glossary

Shortened form of a word, phrase, or name where the abbreviation has
not become part of the language. Includes:

initialism: shortened forms of
a name or phrase made from the initial letters of words or
syllables contained in that name or phrase (e.g., ESP is an
initialism for extrasensory perception).

acronym:
abbreviated forms made from the initial letters or parts of other
words (in a name or phrase) which may be pronounced as a word
(e.g., WAI is an acronym made from the initial letters of the Web
Accessibility Initiative).

accessibility platform
architecture

A programmatic interface that is specifically engineered to enhance
communication between mainstream
software applications and assistive technologies (e.g., UIA,
MSAA and IAccessible2 for Windows applications, UA, AXAPI for Mac OSX,
Gnome Accessibility Toolkit API for Gnome applications, Java Access for
Java applications). On some platforms it may be conventional to enhance
communication further via implementing a document object.

accessibility problem

ATAG 2.0 refers to two types of accessibility problems:

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

Any features of an authoring tool that directly support authors in
increasing the accessibility of the content being authored.
Specifically, this will include any functionality that is used to meet
the success criteria for B.2.1, B.2.2, B.2.3, B.2.4, and B.2.5.

ASCII art[WCAG 2.0]

Picture created by a spatial arrangement of characters or glyphs
(typically from the 95 printable characters defined by ASCII).

Software and/or hardware that provides services to meet the
requirements of users with disabilities that go beyond direct accessibility features
offered by mainstream software
applications and hardware. Such services include alternative
presentations (e.g., as synthesized speech or magnified content),
alternative input methods (e.g., voice), additional navigation or
orientation mechanisms, and content transformations (e.g., to make
tables more accessible). Examples of assistive technologies that are
important in the context of this document include the following:

screen magnifiers, and other visual reading assistants, which are
used by people with visual, perceptual and physical print
disabilities to change text font, size, spacing, color,
synchronization with speech, etc in order improve the visual
readability of rendered text and images;

screen readers, which are used by people who are blind to read
textual information through synthesized speech or braille;

text-to-speech software, which is used by some people with
cognitive, language, and learning disabilities to convert text into
synthetic speech;

voice recognition software, which may be used by people who have
some physical disabilities;

alternative keyboards, which are used by people with certain
physical disabilities to simulate the keyboard;

alternative pointing devices, which are used by people with
certain physical disabilities to simulate mouse pointing and button
activations.

Mainstream software applications and hardware may also provide
services directly that meet the requirements of users with
disabilities.

audio description - also
called described video, video description and
descriptive narration[WCAG
2.0]

An equivalent alternative
that takes the form of narration added to the soundtrack to describe
important visual details that cannot be understood from the main
soundtrack alone. Audio description of video provides information about
actions, characters, scene changes, on-screen text, and other visual
content. In standard audio description, narration is added during
existing pauses in dialogue. In extended audio
description, the video is paused so that there is time to add
additional description.

authoring action

Any action that authors take using the authoring tool user
interface with the intention of editing content (e.g., typing text,
deleting, inserting an element, applying a template). Most authoring
tool user interfaces also enable actions that do not edit content
(e.g., setting preferences for the tool, searching the help
system).

authoring outcome

A characteristic of content that results from one or
more authoring actions being
applied. Authoring outcomes exist at different levels (e.g., making a
paragraph bold vs. deploying a site-wide navigation system) and are
cumulative (e.g., text is entered, then styled, then made into a link,
then given title). Mainstream rendered
(authoring) outcomes are only the subset of content
characteristics that are apparent to end-users of mainstream user agents (e.g., text that is bold, a
seamless patchwork of images; but not commented code or table
relationships). Often, multiple authoring practices exist that will
result in the same mainstream rendered authoring outcome, but the
outcomes may differ with respect to accessibility (e.g., styled text
may appear identical to an image of text on the screen, but will appear
differently in audio output).

A state of the authoring tool during which content can be edited by
the author. The end of an authoring session is the point in time at
which a session ends and the author has no further opportunity to make
changes without starting another session. This may be under the control
of the author (e.g., closing a document, publishing) or it may be
controlled by the authoring tool (e.g., when the authoring tool
transfers editing permission to another author on a collaborative
system). Note: Automated content generation may
continue after the end of an authoring session (e.g., CMS updates).

The display and control mechanism that authors use to communicate
with and operate the authoring tool software. User interfaces may be non-Web-based
or Web-based
or a combination (e.g., a non-Web-based authoring tool might have
Web-based help pages). User interfaces include content independent
functions and content dependent functions. An accessible
authoring tool user interface is one that meets the success
criteria in Part A (i.e., does not
include any authoring tool
user interface accessibility problems). The level of accessibility is
determined by the levels of the satisfied success criteria.

Whether a person has a right to modify given Web content. In other
words, whether they qualify as an author of
the content. Some authoring tools are capable of managing authoring
permissions in order to prevent unauthorized modifications.

authors

Any person using an authoring tool
to create or modify Web content for use by other
people. This may include content authors, designers, programmers,
publishers, testers, etc. working either alone or collaboratively. A
person will only qualify as an author of given Web content if the (1)
the authoring tool provides functionality to create or modify the
relevant Web content
technology and (2) the person has author permission for that
particular Web content.

Switch back and forth between two visual states in a way that is
meant to draw attention. It is possible for something to be large
enough and blink brightly enough at the right frequency to be also
classified as a flash.

An equivalent alternative
that takes the form of text presented and synchronized with synchronized media
to provide not only the speech, but also non-speech information
conveyed through sound, including meaningful sound effects and
identification of speakers. In some countries, the term "subtitle" is
used to refer to dialogue only and "captions" is used as the term for
dialogue plus sounds and speaker identification. In other countries,
"subtitle" (or its translation) is used to refer to both.

Change of view or focus. Content that changes the function or meaning
of an interface. A change of content is not always a change of context.
Small changes in content, such as an expanding outline or dynamic menu,
do not change the context.

manual checking: where the
tests are carried out by authors. This
includes the case where the authors are aided by instructions or
guidance provided by the authoring tool, but where authors must
carry out the actual test procedure;

semi-automated
checking: where the tests are partially carried out by the
authoring tool, but where authors' input or judgment is still
required to decide or help decide the outcome of the tests; and

automated checking:
where the tests are carried out automatically by the authoring tool
without any intervention by the authors.

An authoring tool may support any combination of checking types.

collection of software
components

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

content
being edited

The Web content that is currently
being modified by the authoring tool for use by other people.

Information and sensory experience to be communicated to the user by
means of a user agent, including code or markup
that defines the content's structure, presentation, and interactions.
In ATAG 2.0, "content" is primarily used in the context of the output
that is produced by the authoring tool. This includes
Web applications, including those that, in turn, act as Web-based
authoring tools. Accessible Web content is
Web content that does not contain accessibility
problems. Usually this refers to a particular level of accessibility (e.g.,
Web content that meets Level "A" Web content accessibility).
Accessible Web content is shorthand for content that meets a given
set of accessibility criteria. This does not not necessarily mean that
it will be accessible to every person with a disability.

User interface
functionality that the authoring tool presents as it renders, plays or
executes Web content. In this document
the term covers conventional renderings (e.g., What-you-see-is
wh-you-get "WYSIWYG" interfaces), unconventional renderings
(e.g., rendering an audio file as a graphical wavefront) and
partial renderings, in which some aspects of the content are
rendered, played, or executed, but not others (e.g., a frame-by-frame
video editor renders the graphical, but not the temporal aspect, of a
video).

A process that takes as input, content
in one Web content technology
(or non-Web content technology, such as a word processing format) and
produces as output, content in a different Web content technology
(e.g., "Save as HTML" functions).

Any people responsible for programming the authoring tool. This will
include the programmers of any components included by
the claimant in the conformance claim. In some cases, development of
the authoring tool is complete before the author uses it, however in
other cases (e.g., some Web-based tools) the developer may continue to
modify the authoring tool after content is published by the
author such that the Web content experienced by the end user is modified.

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 work flows, 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:

full text
alternative for synchronized media including any interaction
[WCAG 2.0]: document
including correctly sequenced text descriptions of all visual
settings, actions, speakers, and non-speech sounds, and transcript
of all dialogue combined with a means of achieving any outcomes
that are achieved using interaction (if any) during the synchronized media.

A sequence of flashes or rapidly changing image sequences where all
three of the following occur:

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

the flashing is below 50 Hz, and

the combined area of flashes occurring concurrently and
contiguously occupies more than a total of .006 steradians (25% of
any 10 degree visual field on the screen).

Notes: For the general
flash threshold, a flash is defined as a pair of opposing
changes in relative luminance of 10% or more and the relative luminance
of the darker image is below 0.80. An "opposing change" is an increase
followed by a decrease, or a decrease followed by an increase. For the
red flash threshold, a flash is defined as any
transition to or from a saturated red. For general Web content, using a
341 x 256 pixel rectangle anywhere on the displayed screen area when
the content is viewed at 1024 x 768 pixels will provide a good estimate
of a 10 degree visual field for standard screen sizes and viewing
distances.

To provide authors with information via the authoring tool user interface.
Informing mechanisms range from unobtrusive (i.e., information
presented without stopping the authors' current activity) to intrusive
(i.e., interrupting the author's current activity). Information may be
provided as part of a prompt.

informative[WCAG 2.0]

For information purposes and not required for conformance.

label[WCAG
2.0]

Text or other component with a text
alternative that is presented to authors to identify a component. A label
is presented to all authors whereas the name
may be hidden and only exposed by assistive technology. In many (but
not all) cases the name and the label are the same.

Software applications and hardware for which augmenting accessibility
is secondary to some other purpose (as opposed to assistive technology where it is
the primary purpose). Mainstream technologies may include direct accessibility features.

markup

A set of tags from a markup language. Markup can be
presentational (i.e.,
markup that encodes information about the visual layout of the
content), structural (i.e., markup that
encodes information about the structural role of elements of the
content) or semantic (i.e., markup that
encodes information about the intended meaning of the content). A markup
language is a syntax and/or set of rules to manage markup (e.g., HTML,
SVG, MathML).

name[WCAG
2.0]

Text by which software can identify a component to the user. The name
may be hidden and only exposed by assistive technology, whereas a label is presented to
all users. In many (but not all) cases, the label and the name are the
same.

non-text content[WCAG 2.0]

Any content that is not a sequence of characters that can be made available via the platform or
where the sequence is not expressing something in human
language. This includes ASCII Art (which is a pattern of
characters), emoticons, leetspeak (which is character substitution),
and images representing text.

normative[WCAG 2.0, UAAG 2.0]

Required for conformance. One may conform in a variety of
well-defined ways to this document. Content identified as "informative" or "non-normative" is never
required for conformance.

option

When an author is presented with choices. An option may be local
(e.g., prompting whether to save before closing a piece of content) or
global
(e.g., preference settings).

platform

The software environment within which the authoring tool operates.
For non-Web-baseduser
interface functionality this will be an operating system (e.g.,
Windows, Mac OS, Linux), virtual machine (e.g., JVM) or a higher level
GUI toolkit (e.g., Eclipse). For Web-based
authoring user interface functionality, "platform" applies more
generically to user agents in general,
although for purposes of evaluating conformance to ATAG 2.0 a specific
user agent(s) will be listed in the conformance
profile. Available via the platform:
For non-Web-based user interface functionality this means via an
implemented accessibility
platform architecture. For Web-based
user interface functionality this means following relevant Web
content accessibility design guidelines so that the user agent can pass on the information.

plug-in[UAAG 2.0]

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

A heuristic measure of the degree to which authors are likely to notice components in the authoring tool user
interface when operating the authoring tool. In this document,
prominence refers to visual as well as keyboard-driven navigation. Some
of the factors that contribute to the prominence of a component
include:

Any authoring tool initiated request for a decision or piece of
information from authors. Well designed
prompting will urge, suggest, and encourage authors.

publishing

The point at which the authors or the authoring tool make content available to end users (e.g., uploading a Web page,
committing a change in a wiki).

recognized (by the tool)

When an authoring tool is able to process encoded information, such
as properties or relationships, with certainty. For example, an
authoring tool would only be able to recognize a particular text string
as a text label for a non-text object, if this relationship was
appropriately encoded (e.g., in an "alt" attribute, by a "labeledby"
property). If success criteria apply to recognized types of content
(e.g., tool-recognized equivalent alternatives), the conformance claim must list the recognized
types.

relationships[WCAG 2.0]

Meaningful associations between distinct pieces of content.

relative
luminance[WCAG 2.0]

The relative perceived brightness of any point, normalized to 0 for
darkest black and 1 for lightest white.

The "^" character is the exponentiation operator. (Formula taken from
[sRGB] and [IEC-4WD]).

Note 2: Almost all systems used
today to view Web content assume sRGB encoding. Unless it is known that
another color space will be used to process and display the content,
authors should evaluate using sRGB colorspace.

Note 3: For dithered colors, use
average values of the colors used (average R, average G, and average
B).

Note 4: Tools are available that
automatically do the calculations when testing contrast and flash.

manual: where the repairs
are carried out by authors. This includes the case where the
authors are aided by instructions or guidance provided by the
authoring tool, but where authors carry out the actual repair
procedure;

semi-automated:
where the repairs are partially carried out by the authoring tool,
but where authors' input or judgment is still required to complete
the repair; and

automated: where the
repairs are carried out automatically by the authoring tool without
any intervention by the authors.

reversible actions

Authoringactions that, by their nature, can be
completely undone so that the system returns to the state it was in
before the action. Actions that are not reversible may include certain
save and delete actions as well as actions made in a collaborative
environment that another author has begun to work with.

role[WCAG 2.0]

Text or a number by which software can identify the function of a
component within Web content (e.g., a number that indicates whether an
image functions as a hyperlink, command button, or check box).

A mechanism for encoding instructions to be rendered, played or
executed by user agents. Web Content
technologies may include markup
languages, data formats, or programming languages that authors may use alone or in combination to
create end-user experiences that range from static Web pages to
multimedia presentations to dynamic Web applications. Some common
examples of Web content technologies include HTML, CSS, SVG, PNG, PDF,
Flash, and JavaScript.

A content pattern that is filled in by authors or the authoring tool to produce content
for end users (e.g., document templates,
content management templates, presentation themes). Often templates
will pre-specify at least some authoring decisions.

Any software that retrieves and presents Web content for end users. Examples include Web browsers,
media players, plug-ins, and other programs including assistive technologies, that help
in retrieving, rendering and interacting with Web content.

A part of the user
interface or content display
(including renderings) that is perceived by authors as a single control for a distinct
function. In ATAG 2.0, the term is used to denote any part of the user
interface of the authoring tool involved with display or control.

User interface functionality that authors
use to interact with the content being
edited. In addition to being editable (i.e., editing
views) or non-editable (e.g. a preview that presents content as it would
appear in a user agent), there are
several broad approaches to presenting the content:

meta-content in which authors set
high-level options that the authoring tool then interprets to
generate the resulting content (e.g., a content management system
that only lets authors set the month and year on a built-in
calendar module).

workflow

A customary sequence of steps or tasks authors follow to produce a deliverable.

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:

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

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

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

This publication has been funded in part with Federal funds from the U.S.
Department of Education, National Institute on Disability and Rehabilitation
Research (NIDRR) 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.