This specification provides guidelines for designing authoring
tools that lower barriers to Web accessibility for people with disabilities.
An authoring tool that conforms to these guidelines will promote accessibility
by providing an accessible authoring interface to authors with disabilities
as well as enabling, supporting, and promoting the production of accessible
Web content by all authors.
"Authoring Tool Accessibility Guidelines 2.0" (ATAG 2.0) is part
of a series of accessibility guidelines published by the W3C Web Accessibility Initiative
(WAI).
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is a W3C Last Call Working Draft of a specification which will supersede
the W3C Recommendation "Authoring Tool Accessibility Guidelines 1.0" [ATAG10].
The Authoring Tool Accessibility Guidelines Working Group plans
to submit this specification for consideration as a W3C Candidate Recommendation
after examining feedback to this draft. Comments on this specification should
be sent to w3c-wai-au@w3.org, the
Working Group's public email list. This list is archived and
acceptance of this archiving policy is requested automatically upon first
post. To subscribe to this list, send email to w3c-wai-au-request@w3.org with
the word "subscribe" in the subject line. Comments are accepted
until 7 January 2005.
This document has been produced by the Authoring Tool Accessibility Guidelines Working
Group (AUWG).
The goals of the Working Group are described in the AUWG charter. The AUWG is part
of the WAI Technical Activity.
The AUWG also provides additional resources to support this document such
as Frequently Asked Questions (FAQ) about ATAG 2.0, issues, implementation reports, and
test suites. Please consult the AUWG
home page for more information.
This document was produced under the 24
January 2002 CPP as amended by the W3C Patent Policy
Transition Procedure. Patent disclosures relevant to this specification may be found on the Working
Group's patent disclosure
page in conformance with W3C policy. An individual
who has actual knowledge of a patent which the individual believes
contains Essential Claim(s) with respect to this specification
should disclose the information in accordance with
section 6 of the W3C Patent Policy.
This draft refers non-normatively to the Techniques for Authoring Tool Accessibility
Guidelines 2.0 [ATAG20-TECHS].
This draft refers normatively to ATAG 2.0 References to various versions
of the Web Content Accessibility Guidelines (WCAG) as well as the requirements
in an ISO document that is currently titled
"Ergonomics of human-system interaction - Guidance on accessibility for human-computer
interfaces". This is explained in Section
1.4.
The AUWG expects the ATAG 2.0 to be backwards-compatible with ATAG 1.0, or at most
to make only minor changes in requirements. Before this document reaches
last call, the Working Group will publish a detailed analysis of the differences
in requirements.
Publication as a Working Draft does not imply endorsement by the W3C Membership.
This is a draft document and may be updated, replaced or obsoleted by other
documents at any time. It is inappropriate to cite this document as other
than work in progress.
Please send comments about this document to the public mailing list: w3c-wai-au@w3.org
(public archives). Please
note that this document may contain typographical errors. It was published
as soon as possible since review of the content itself is important, although
noting typographical errors is also helpful.
This document specifies requirements that, if satisfied by authoring tool
developers, will lower barriers to accessibility. This document includes the
following:
-
This introduction provides context for understanding
the requirements listed in section 2.
- Section 2 provides 4 general principles of accessible
authoring tool design, called "guidelines". Each guideline consists
of a list of requirements, called "checkpoints", which must be satisfied
in order to conform to this document. Note: Section 2 is numbered differently
than the other sections; it consists of a list of guidelines. In section 3,
"checkpoint 1.2" refers to the second checkpoint of the first guideline.
-
Section 3 explains how to
make claims that software components satisfy the requirements of section
2.
- An appendix lists all
of the checkpoints for convenient
reference (e.g., as a tool for developers to evaluate software for conformance).
- A separate document, entitled "Techniques for Authoring Tool Accessibility
Guidelines 2.0" [ATAG20-TECHS]
(the "Techniques document" from here on), provides suggestions
and examples of how each checkpoint might be satisfied. It also includes
references to other accessibility resources (such as platform-specific software
accessibility guidelines) that provide additional information on how an
authoring tool may satisfy each checkpoint. The techniques in the Techniques
document are informative examples only, and other strategies may be used
or required to satisfy the checkpoints. The Working Group expects to update
the Techniques document more frequently than the current guidelines. Developers,
W3C Working Groups, users, and others are encouraged to contribute techniques.
1.1 Scope
These guidelines cover a wide range of recommendations
for assisting authoring tool software developers in making authoring tools,
as well as the content that the authoring tools generate,
more accessible to all potential Web content users and authors, especially people
with disabilities
.
These guidelines have been written to address the requirements of
many different audiences, including, but not limited to: policy makers, technical
administrators, and those who develop/manage content. Every attempt has been
made to make this document as readable and usable as possible while still retaining
the accuracy and clarity needed in a technical specification.
1.2 Definition of authoring
tool
ATAG 2.0 defines an "authoring tool" as: any software or service
that authors may use to create or modify Web content for publication.
To illustrate the range of this term as it is used in these guidelines, an
authoring function categorization scheme has been developed. The scheme is
used primarily within the Techniques document [ATAG20-TECHS]
to call out examples that may be of interest to developers of particular types
of tools. It is important to note that many authoring tools will include authoring
functions that fall into one or more of the categories (e.g. many basic HTML
editors have 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 the author the same freedom
of control as plain text editing (e.g. graphical tag placeholders).
Examples: text editors, text editors enhanced with graphical
tags, etc.
WYSIWYG ("What-you-see-is-what-you-get") Authoring
Functions:
Authors have control over entities that closely resemble the final
appearance and behavior of the resulting Web content.
Examples: rendered document editors, bitmap graphics editors,
etc.
Object Oriented Authoring Functions: Authors have control
over functional abstractions of
the low level aspects of the resulting Web content.
Examples: timelines, waveforms, vector-based graphic editors,
etc.
Indirect Authoring Functions: Authors have control over
only high-level parameters related to the automated production of the
resulting Web content. This may include interfaces that assist the author
to create and organize Web content without the author having control over
the markup, structure, or programming implementation.
Examples: content management systems, site building wizards, site
management tools, courseware, weblogging tools, content aggregators, and
conversion tools, etc.
The guiding principle of ATAG 2.0 is that:
Everyone should have the ability to create and access Web content.
Authoring tools play a crucial role in achieving this principle because the
design of the tool's authoring interface determines
who can access the tool as a Web content author and
the accessibility of the resulting Web content determines who can be an end-user of that Web content.
As an introduction to accessible authoring tool design, consider that the
authors and end-users of Web content may be using the tool and its output in
contexts that are very different from that which you may regard as typical.
For example, authors and end-users may:
- 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].
Designing authoring tools for accessibility will have benefits for authors
and end-users beyond those listed in these various disability-related
contexts. For example, a person may have average hearing, but still require
an equivalent alternative for audio information due to a noisy workplace.
Similarly, a person working in an eyes-busy environment may require an audio
alternative to information they cannot view.
1.4 Relationship with other guidelines
and standards
ATAG 2.0 is part of a series of accessibility guidelines published by the Web
Accessibility Initiative (WAI). The documents in this series reflect an accessibility
model in which format designers, Web content authors, and software developers
have roles in ensuring that users with disabilities have access to the Web.
The accessibility-related interests of these stakeholders intersect and complement
each other as follows:
- Designers of formats (e.g., HTML, XHTML, XML, SVG, SMIL, MathML, and XForms)
and protocols (e.g., HTTP) create specifications that allow communication
on the Web. Format designers include features in these specifications that
authors should use to create accessible content and that user agents should
support through an accessible user interface. The "XML Accessibility
Guidelines (XAG)" [XAG] explains
the responsibilities of XML format designers; many XAG requirements make sense
for non-XML formats as well.
- User agent developers design software that meets the needs of users with
disabilities through conformance to other specifications, an accessible user
interface, accessible documentation, and communication with other software
(notably assistive technologies). The "User Agent Accessibility Guidelines
1.0" [UAAG10] explains the responsibilities
of user agent developers.
- Authoring tool developers design software that can be operated by authors
with disabilities and that enables, supports, and promotes the creation of
accessible Web content by all authors. ATAG 2.0 (this document) explains the
responsibilities of authoring tool developers.
- Authors make use of the accessibility features of different format specifications,
use markup appropriately, write in clear and simple language, and organize
a Web site consistently. The "Web Content Accessibility Guidelines (WCAG)",
version 1.0 [WCAG10]
or version 2.0 [WCAG20],
explains the responsibilities of authors in meeting the needs of users with
disabilities.
In particular, ATAG 2.0 has a special normative
relationship with the WCAG because WCAG serves as the
benchmark against which the accessibility of Web content produced by authoring
tools can be judged. WCAG also serves as the benchmark for judging the accessibility
of authoring interfaces that are Web-based.
In addition, while
the W3C documents listed here provide excellent coverage of Web-based technologies,
the W3C has not published any documents specifically covering the accessibility
of software interfaces that are not Web-based. Instead of duplicating some
of the work that exists outside of W3C in this area, the Working Group has
chosen to normatively reference an International
Organization for Standardization (ISO) document that is under development,
entitled: "Ergonomics
of human-system interaction - Guidance on accessibility for human-computer
interfaces" (referred
to by its current version number "ISO-TS-16071"),
as the benchmark for judging the accessibility of authoring interfaces that
are not Web-based.
1.4.1 Relationship to "Web Content
Accessibility Guidelines (WCAG)"
ATAG 2.0 depends on WCAG to act as a benchmark for
judging the accessibility of Web content and Web-based authoring interfaces
and also to define the terms "Accessible
Web Content" and "Accessible
Authoring Interface".
At the time of publication, version 1.0 of WCAG is a W3C Recommendation [WCAG10],
and a second version of the guidelines is under development [WCAG20].
However, within the guidelines section of ATAG 2.0, references
are made to WCAG without an associated version number. This has been done to
allow developers to select, for the conformance profile,
whichever version of WCAG is most appropriate for the circumstances of a given
authoring tool. The Working Group does recommend considering the following factors
when deciding on which WCAG version to use:
- 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 that published WCAG technique documents be available for any output
formats that are given priority by the authoring tool (Checkpoint 2.1).
- 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 to will legislation
and policies, albeit at an uneven pace. Authoring tool developers may, therefore,
consider supporting multiple versions of WCAG.
1.4.2 Relationship to "Ergonomics
of human-system interaction - Guidance on accessibility for human-computer interfaces
(ISO TS 16071:2003)"
For the reason stated previously,
ATAG 2.0 depends on the International Organization for Standardization (ISO)
document that is titled "Ergonomics of human-system interaction - Guidance
on accessibility for human-computer interfaces" to act as a benchmark
for judging the accessibility of authoring interfaces that are not Web-based
and to define the term "Accessible
Authoring Interface".
At the time of publication, the last stable version
number for the ISO document is ISO TS 16071:2003[ISO-TS-16071].
However, it is expected that an additional ISO document based on ISO TS 16071:2003
will be released in 2006. As with the relationship
to WCAG, ATAG 2.0 allows developers to have the option of substituting
more recent versions of the ISO document into the conformance
profile as they become available.
ISO TS/16071:2003 "Ergonomics
of human-system interaction - Guidance on accessibility for human-computer
interfaces" provides
guidance to application developers on designing software with the goal of
making it accessible to people with a wide range of visual, hearing,
motor and cognitive abilities. The document addresses software considerations
for accessibility that complement general design for usability covered
by ISO 9241-10 to ISO 9241-17 and ISO 13407. The document defines requirements
that are relevant to operating systems, application
or both. Three levels of accessibility impact are defined:
- Core: A substantial
subset of users cannot accomplish most tasks without either additional
assistance or extensive extra effort to compensate for the omission
of the item. For these users, the system is unusable.
- Primary:
Most users can accomplish most tasks, but a substantial subset
of users may not be enabled to perform some tasks, either due to lack of
access to functionality or severe usability problems.
- Secondary: Most users
can accomplish most tasks, but a substantial
subset of users may not be enabled to perform some tasks without a severe
decrease in efficiency and satisfaction.
ATAG Guidelines refer to part
7.2 of the document that contains general
guidelines where the following requirements refer to "Application":
7.2.1.1 (core), 7.2.1.2 (secondary), 7.2.2 (core), 7.2.3 (secondary),
7.2.4 (core), 7.2.5 (secondary), 7.2.9 (secondary), 7.2.10 (core),
7.2.11 (secondary), 7.2.12 (core) and 7.2.13 (secondary).
1.5 How this document is organized
The four guidelines that reflect steps toward the development of accessible
authoring tools are:
- Guideline 1: Make the authoring interface accessible
- Guideline 2: Enable the production of accessible content
- Guideline 3: Support the author in the production of accessible content
- Guideline 4: Promote and integrate accessibility solutions
The first guideline addresses the accessibility of the authoring interface
of the tool. The other three guidelines address the means by which Web content
comes to be produced by the tool. These three guidelines build upon each other,
with guideline 2 establishing core requirements, guideline 3 establishing key
author support functionality and guideline 4 specifying general considerations
for how any functionality related to accessibility should be integrated with
the rest of the tool. Each guideline includes:
- 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 sufficiently specific
to be verifiable, while being sufficiently general to allow developers the freedom
to use the most appropriate strategies to satisfy it. Each checkpoint definition
includes the following parts. Some parts are normative (i.e., relate to conformance);
others are informative only:
- The checkpoint number.
- The checkpoint title. (Informative)
- The priority of the checkpoint.
(Normative)
- A rationale for the checkpoint. (Normative)
- A pointer to implementation techniques for the checkpoint in the "Implementation
Techniques for Authoring Tool Accessibility Guidelines 2.0" [ATAG20-TECHS].
(Informative)
- Success criteria for testing whether the checkpoint has been satisfied.
The authoring tool must satisfy these requirements to claim conformance.
(Normative)
2. The Authoring Tool Accessibility
Guidelines
GUIDELINE
2: Enable the production of accessible content
The creation of accessible content is dependent on the actions of the tool
and the author. This guideline delineates the responsibilities that rest
exclusively with the tool.
The first responsibility is to support formats that
enable accessible content (Checkpoint 2.1). Web content produced by an authoring
tool is most likely to be accessible, if the content is created in accordance
with the requirements of WCAG and preserved in that
state throughout the authoring process. The checkpoint requirements that
support this include preserving accessible or unknown content (Checkpoint
2.2), automatically generating accessible content (Checkpoint 2.3), and
including accessible pre-authored content (Checkpoint 2.4).
-
- 2.1 Support formats
that enable the creation of Web content that conforms to WCAG.
[Priority 1]
-
Rationale: Formats with published
WCAG techniques documents facilitate
the creation of accessible Web content.
-
Techniques: Implementation Techniques for Checkpoint 2.1
Success Criteria:
- Any authoring tool that chooses the format of content for the
author (i.e. a default format) must always choose formats
for which there are published WCAG
techniques documents for meeting each WCAG checkpoint.
- Any authoring tool that allows authors to choose the format
of content must always support at least one format for
which there is a published WCAG
techniques documents
for meeting each WCAG checkpoint and always give prominence
to those formats.
- 2.2
Ensure that the tool preserves all unrecognized markup and accessibility
information during transformations and conversions. [Priority 2]
-
Rationale: Unrecognized
markup may include recent
technologies that have been added to enhance accessibility and should
be preserved during conversions or transformations.
Accessibility information should
also be preserved.
Techniques: Implementation Techniques for Checkpoint
2.2
Success Criteria:
- All transformations and conversions supported by the authoring
tool must always meet both of the following conditions:
- (a) The author is notified before any unrecognized
markup is permanently removed.
- (b) All accessibility
information is handled according to at least one of
the following:
- (i) Be preserved in the target format such that the
information can be "round-tripped" (i.e.
converted or transformed back into its original form)
by the same authoring tool.
- (ii) Be preserved in some other way in the target
format.
- (iii) Be removed only after the author has been notified
and the content has been preserved in its original
format
- 2.3
Ensure that when the tool automatically generates content it conforms
to WCAG. [Web Content Checkpoints
Relative to WCAG]
-
Rationale: Authoring tools that automatically generate
content that does not conform
to WCAG are a
source of accessibility
problems.
Note: WCAG includes a markup validity requirement.
Techniques: Implementation Techniques for
Checkpoint 2.3
- 2.4
Ensure that all pre-authored content for the tool conforms
to WCAG. [Web Content Checkpoints Relative
to WCAG]
-
Rationale: Pre-authored content, such as templates,
images, and videos, is often included with authoring tools for use
by the author. When this content conforms
to WCAG,
it is more convenient for authors and more easily reused.
Techniques: Implementation Techniques for
Checkpoint 2.4
Success Criteria:
- Any Web content (e.g.,
templates, clip art, example pages, etc.) that is bundled with
the authoring tool or preferentially licensed to the users of the
authoring tool (i.e. provided for free or sold at a discount),
must conform to WCAG when
inserted.
Actions may be taken at the author's initiative that may result in accessibility
problems. The authoring tool should include features that provide support
and guidance to the author in these situations, so that accessible
authoring practices can be followed and accessible
web content can be produced.
This support includes prompting and assisting the author to create accessible
web content (Checkpoint 3.1), especially for information that cannot be
generated automatically, checking for accessibility problems (Checkpoint
3.2), and assisting in the repair of accessibility problems (Checkpoint
3.3). In performing these functions, the authoring tool must avoid including
automatically generated equivalent alternatives or previously authored equivalent
alternatives without author consent (Checkpoint 3.4). The authoring tool
may also provide automated means for managing equivalent alternatives (Checkpoint
3.5) and provide accessibility status summaries (Checkpoint 3.6).
Accessibility-related documentation provides support and guidance to the
author. The documentation must accommodate the various levels of author
familiarity with web content accessibility issues. The checkpoint requirements
include documenting accessible content promoting features (Checkpoint
3.7) and ensuring that documentation demonstrates
accessible authoring practices (Checkpoint 3.8) and provides instruction
in creating accessible content (Checkpoint 3.9).
- 3.1
Prompt and assist the author to create content that conforms to WCAG.
[Web Content Checkpoints Relative to WCAG]
-
Rationale: The authoring tool should help to prevent
the author from making decisions or omissions that cause accessibility
problems. If accessibility problems are prevented, less effort is required
to create content that conforms
to WCAG. Different
tool developers will accomplish this goal in ways that are appropriate
to their products, processes, and authors.
Techniques: Implementation Techniques for Checkpoint
3.1
Success Criteria:
- Every time that content is added or updated
that requires accessibility
information from
the author in order to conform
to WCAG, then the
authoring tool must inform the
author that this additional information is required (e.g. via
input dialogs, interactive feedback, etc.).
- Whenever the tool provides instructions to the author, either the
instructions (if followed) must lead to the creation of Web content that
conforms to WCAG, or the author must be informed that following the
instructions would lead to Web content accessibility problems.
- 3.2 Check for and inform the
author of accessibility problems. [Web Content Checkpoints Relative to WCAG]
-
Rationale: Authors may not notice or be able to check for accessibility
problems without assistance from the authoring
tool.
Note: This checkpoint does not apply to authoring
tools that constrain authoring choice to such a degree that it is not
possible to create Web content that does not conform to WCAG.
Techniques: Implementation Techniques for Checkpoint
3.2
Success Criteria:
- The authoring tool must always provide a check (automated
check, semi-automated check or manual check) for each applicable
requirement to conform to WCAG.
- The authoring tool must always inform the
author of any failed check results prior to completion
of authoring.
- 3.3
Assist authors in repairing accessibility problems. [Web Content Checkpoints Relative to WCAG]
-
Rationale: Assistance by the authoring tool may
simplify the task of repairing accessibility
problems for some authors, and make
it possible for others.
Techniques: Implementation Techniques for
Checkpoint 3.3
Success Criteria:
- The authoring tool must always provide a repair (automated
repair, semi-automated repair or manual repair) for each applicable
requirement to conform to WCAG.
- For accessibility
problems for which an authoring tool provides only manual
repairs, the repair instructions must always be directly
linked
from the corresponding check.
- 3.4 Do
not automatically generate equivalent alternatives or reuse previously
authored alternatives without author confirmation, except when the function
is known with certainty. [Priority 1]
-
Rationale: Improperly generated equivalent alternatives can create
accessibility problems and interfere with accessibility checking.
Techniques: Implementation Techniques for Checkpoint
3.4
Success Criteria:
- When the author inserts an unrecognized non-text object, the
tool must never
insert an automatically generated text equivalent (e.g. label generated
from the file name).
- When the author inserts a non-text object for which the tool
has a previously authored equivalent alternatives (i.e. created by the author, tool
designer, pre-authored content developer, etc.), but the function
of the object is not known with certainty, the tool must always
prompt the author to confirm insertion of the equivalent. However,
where the function of the non-text object is known with certainty
(e.g.
"home button" on a navigation bar, etc.), the tool may
automatically insert the equivalent.
- 3.5
Provide functionality for managing, editing, and reusing alternative
equivalents. [Priority
3]
-
Rationale: Simplifying the initial production and
later reuse of alternative equivalents will encourage authors to use
them more frequently. In addition, such an alternative equivalent management
system will facilitate meeting the requirements of Checkpoints 3.1,
3.2, 3.3 and 3.4.
Techniques: Implementation Techniques for Checkpoint
3.5
Success Criteria:
- The authoring tool must always keep a record of alternative equivalents that the author inserts for particular non-text objects
in a way that allows the text equivalent to be offered back to the
author for modification and re-use if the same non-text object is
reused.
- 3.6
Provide the author with a summary of accessibility status. [Priority 3]
-
Rationale: This summary will help the author to improve
the accessibility status of their work, keep track of problems, and
monitor progress.
Techniques: Implementation Techniques for Checkpoint
3.6
Success Criteria:
- The authoring tool must provide an option to view a list
of all known accessibility
problems (i.e. detected by automated
check or identified by the author as part of a semi-automated or
manual check) prior to completion
of authoring.
- 3.7
Document all features of the tool that support the production of accessible
content. [Priority 2]
-
Rationale: Without documentation
of the features that support the production of accessible
content (e.g. prompts for alternates, code validators, accessibility checkers,
etc.) authors may not find or use them.
Techniques: Implementation Techniques for Checkpoint
3.7
Success Criteria:
- All features that play a role in creating accessible content must
be documented in the help system.
- 3.8
Ensure that accessibility is modeled in all documentation and help, including
examples. [Priority 3]
-
Rationale: If accessible authoring is integrated
into instruction and guidance offered by the tool (e.g. documentation,
help, tutorials, examples, and workflow processes), authors are more
likely to follow accessible authoring as a common practice. This can
also facilitate a better understanding of the reasoning behind and
the consequences of authoring accessible content.
-
Techniques: Implementation Techniques
for Checkpoint 3.8
- 3.9
Provide a tutorial on the process of accessible authoring. [Priority
3]
-
Rationale: Authors are more likely to use features
that promote accessibility if they understand when and how to use them.
-
Techniques: Implementation Techniques for Checkpoint
3.9
Success Criteria:
- A tutorial on accessible authoring for the specific authoring
tool must be provided.
-
For Guideline 1 checkpoints: If the authoring tool does not
satisfy this checkpoint, one or more groups of authors with disabilities
will find it impossible to author for the Web.
-
For Guideline 2, 3, 4 checkpoints: The checkpoint is essential
for authors using the authoring tool to create Web content that conforms
to WCAG.
Priority 2:
-
For Guideline 1 checkpoints: If the authoring tool does
not satisfy this checkpoint, one or more groups of authors with disabilities
will find it difficult to author for the Web.
-
For Guideline 2, 3, 4 checkpoints: The checkpoint is important
for authors using the authoring tool to create Web content that conforms
to WCAG.
Priority 3:
-
For Guideline 1 checkpoints: If the authoring tool does
not satisfy this checkpoint, one or more groups of authors with disabilities
will find it inefficient to author for the Web.
-
For Guideline 2, 3, 4 checkpoints: The checkpoint is beneficial
for authors using the authoring tool to create Web content that conforms
to WCAG.
Relative Priority
Checkpoints (3 types): The importance of these checkpoints
depends on the requirements of external documents. For each type of
relative priority checkpoint, there are three levels of conformance, each
with different applicable requirements (as listed).
- Web
Content Checkpoints Relative to WCAG:
These checkpoints can be met to one of three levels:
- Level 1:
- Level 2:
- Level 3:
- Authoring
Interface Checkpoints Relative to WCAG:
These checkpoints can be met to one of three levels:
- Level 1:
- Level 2:
- Level 3:
- Authoring
Interface Checkpoints Relative to ISO-TS-16071: These checkpoints
can be met to one of three levels designated as "application" in part 7.2 of ISO TS 16071:2003:
- Level 1:
- The authoring interface meets guidelines designated as "core" in
Part 7.2 of ISO TS 16071:2003.
- Level 2:
- The authoring interface meets guidelines designated as "core" and "primary" in
Part 7.2 of ISO TS 16071:2003.
- Level 3:
- The authoring interface meets guidelines designated as "core", "primary",
and "secondary" in
Part 7.2 of ISO TS 16071:2003.
A conformance claim (with or without an accompanying ATAG
2.0 conformance icon) is an assertion by a claimant that
an authoring tool (or bundle of authoring tools)
has satisfied the requirements of a chosen ATAG 2.0 conformance
profile. The claim must be supported by a listing of conformance
details.
The existence of a conformance
claim does not imply that the W3C has reviewed the claim or assured its validity.
As of the publication of this document, W3C does not act as an assuring party,
but it may do so in the future, or it may establish recommendations for assuring
parties.
Conformance claims may be published anywhere (e.g., on the Web or in paper
documentation).
If usability tests are referenced, the details of the testing
methods and results must also be published.
3.2.1 Claimants
- Claimants may be anyone (e.g., developers, journalists, or other third
parties).
- Claimants are solely responsible for the validity of their claims, keeping
claims up to date, and proper use of the conformance icons.
- Claimants are expected to modify or retract any conformance claim if
it may be demonstrated that the claim is not valid.
- Claimants are encouraged to claim conformance to the most recent version
of the Authoring Tool Accessibility Guidelines Recommendation that is available.
3.2.2 Bundling Authoring
Tools
A conformance claim may cover more than one authoring tool used
together (e.g. a markup editor and an evaluation and repair tool or
a multimedia editor with a custom plug-in), each of which may or may not
conform to ATAG 2.0 by themselves, as long as:
- The authoring tools are distributed together.
- The workflow used to determine the conformance of the tool bundle is
typical of how the tools are used together.
3.2.3 Conformance Profiles
An authoring tool conforms to this document by satisfying the requirements
identified by a conformance profile. A conformance profile includes the following
assertions:
-
Required: The guidelines title/version and URI of the guidelines: "Authoring
Tool Accessibility Guidelines 2.0" (e.g., http://www.w3.org/TR/2004/WD-ATAG20-20041122)
-
-
Required: The title/version and URI for the
WCAG
document that was used as the Web content accessibility benchmark
for determining the level of
relative priority
checkpoints:
e.g. "Web Content Accessibility Guidelines 2.0"
- Required: The title/version for the ISO-TS-16071
document that was used as the benchmark for determining the level of Authoring
Interface Checkpoints Relative to ISO-TS-16071:
e.g.
"ISO TS 16071:2003"
- Required: The
name of each format produced by the authoring tool that will be included
in the conformance profile. To be included, a format must have a
published WCAG techniques document, the title and URI of which must be provided. e.g. "HTML
(HTML Techniques for WCAG 2.0)"
- Optional: A description of the authoring tool that identifies the
types of authoring tool functions that are present
in the tool.
Sample Conformance Profile
-
Guidelines: "Authoring
Tool Accessibility Guidelines 2.0" (http://www.w3.org/TR/2004/WD-ATAG20-20041122)
- Conformance Level: "Double-A"
- WCAG document: "Web Content Accessibility Guidelines
2.0" (http://www.w3.org/TR/2004/WD-WCAG20-20041119)
- ISO-TS-16071 document: "ISO
TS 16071:2003"
- Included Formats: HTML 4.01 ("HTML
Techniques for WCAG 2.0" (http://www.w3.org/TR/2004/WD-WCAG20-HTML-TECHS-20041119))
- Authoring Tool Functions: The authoring tool ("Example_Tool")
includes "code-level" and "WYSIWYG" authoring functions for HTML 4.01.
3.2.4 Conformance Details
An ATAG 2.0 conformance claim must also include a description of how the authoring
tool (or tool bundle) meets each of the
normative success criteria for each of the checkpoints that are required
for the conformance
level that has been specified by the conformance
profile.
For relative
priority checkpoints, the situation is more complex. In these
cases, the normative success criteria will make reference to one of two
external document, WCAG or ISO-TS-16071,
which each contain a large number of their own requirements. The set of
WCAG or ISO-TS-16071 requirements that are applicable to the ATAG 2.0 success
criteria is determined by the conformance level that
has been specified by the conformance profile.
For each applicable WCAG or ISO-TS-16071 requirement, a sub-description
of how each of those requirements was satisfied is required.
3.2.5 Conformance Icons
There are currently no conformance icons available for
this draft specification. If it becomes a Recommendation, it is expected that
there will be conformance icons like those available for ATAG 1.0.
4. Glossary
This glossary is normative. However, some
terms (or parts of explanations of terms) may not have an impact on conformance.
- Accessibility
Problem, Authoring Interface
- An authoring interface accessibility problem is
an aspect of an authoring
interface that fails to meet one of the checkpoint success criteria
in Guideline 1. For
checkpoints 1.1 and 1.2, the severity of the problem is relative and is
determined by reference
to WCAG (for
Web-based authoring interfaces) or by reference
to ISO-TS-16071 (for
non-Web-based authoring interfaces). For
checkpoints 1.3 to 1.5, the severity of the problem is defined by the
ATAG 2.0 priority
level of
the failed checkpoint.
- Accessibility
Problem, Web Content
- A Web content accessibility problem is an aspect of Web
content that
fails to meet some requirement of WCAG. The severity of the problem is
relative and is determined by reference
to WCAG.
- Accessible
Web Content
- Accessible Web content is Web content (e.g.
output of an authoring tool) that is sufficiently free of
Web content accessibility
problems
to be usable by end-users regardless of disability.
- Accessible
Authoring Interface
- An accessible authoring interface is an authoring
interface, Web-based or not, for
an authoring tool that is sufficiently free of authoring
interface accessibility problems to
be usable by authors regardless of disability.
- Accessibility
Information
- Accessibility
information is any information that is necessary and sufficient for
undertaking an accessible
authoring practice. This information may include, but
is not limited to, equivalent alternatives.
- Accessible
Authoring Practice
- An accessible
authoring practice is any authoring activity by the author or the authoring
tool that leads to accessible
Web content.
- Alert
- An alert makes the author aware
of events or actions that require a response
or reaction, but not necessarily immediately. The event or actions that
trigger an alert may have serious consequences if ignored.
- Attribute
- An attribute, as used in the document, has the same sense as in SGML
and XML [XML]. Some attributes are integral to the accessibility
of content (e.g., the "
alt
", "title
",
and "longdesc
"
attributes in HTML).
- Audio
Description
- Audio description (also called "Described Video") is an equivalent alternative that provides aural information about
actions, body language, graphics, and scene changes in a video. Audio
descriptions are commonly used by people who are blind or have low vision,
although they may also be used as a low-bandwidth equivalent on the Web.
An audio description is either a pre-recorded human voice or a synthesized
voice (recorded or automatically generated in real time). The audio
description must be synchronized with the auditory track of a video presentation,
usually during natural pauses in the auditory track.
- Author
- An author is a
user of an authoring tool. This may include content authors, designers,
programmers, publishers, testers, etc.
- Authored
"By Hand"
- Authoring by hand is a situation in which the author specifies
Web content at the lowest level (e.g. typing
into a text editor).
- Authoring
Action
- An authoring action is any action that the author takes
using the authoring interface with
the intention of adding or modifying Web
content.
- Authoring
Interface
- An authoring interface is the display and control
mechanism available to an
author to communicate with and operate the authoring
tool software. ATAG 2.0 divides authoring tool interfaces into two categories:
Web-Based (i.e. tools that are implemented using Web content
and run within a user agent) and non-Web-Based (i.e. tools
that run directly on a operating system such as Windows or Mac OS).
- Authoring
Interface, Full-Featured
- A full-featured authoring interface is
one that includes editing
methods for all of the properties that are editable by an authoring
tool.
- Authoring Tool
- See "Definition of
authoring tool".
- Captions
- Captions are equivalent
alternatives for movie audio.
Captions consist of a text transcript of the auditory track of the movie
(or other video presentation) that is synchronized with the video and
auditory tracks. Captions are generally rendered graphically and benefit
people who can see but are deaf, hard-of-hearing, or cannot hear the
audio.
- Checking, Accessibility
- Accessibility checking (or "accessibility evaluation") is the
process by which Web content is evaluated
for Web content accessibility
problems. ATAG 2.0 identifies three categories of checking: Automated (i.e.
the authoring tool is able to check for problems automatically, with no
human intervention required), Semi-Automated (i.e. the
authoring tool is able to identify potential problems, but still requires
human judgment by the author to make a final
decision on whether an actual problem exists) and Manual (i.e.
the authoring tool provides the author with instructions for detecting
a problem, but does not automate the task of detecting the problem in any
meaningful way).
- Completion
of Authoring
- Completion of authoring is the point in time at which an authoring session
ends and the author has no opportunity to make further changes. This
may be when an author chooses to "save and exit", or "publish",
or it may occur automatically at the end of a wizard, etc.
- Configurability
- Configurability refers to the adjustment of authoring
tool settings, such as layout, rendering style, or other parameters that
may affect the author's ability to use the authoring
interface or editing methods. The author must
then be able to store these adjustments, or author preferences, so they
can
be used in all future sessions with the authoring tool.
- Continuously
Active
- Continuously active features of an authoring tool
are those that constantly examine an author's
actions (e.g. a "check-spelling-as-you-type"
feature). These contrast with features that must be activated
and then operate only for a discrete period (e.g. a print feature)
- Conversion
- A conversion is a process that takes, as input, Web
content in
one format and produces, as output, Web content
in another format (e.g.,"Save
as HTML" functions).
- Device-Independent
Action
- A device-independent action is not bound to only
one type of input device.
- Directly
Linked
- Two interface features are directly linked if there
is a single author action on one of the features that causes the other
to appear.
- Display
- Display refers to the presentation of information
to the author, either
visually or through a device such as a screen reader.
- Document
- A document is a structure of elements along with any associated
content; the elements used are defined by a markup language.
- Documentation
- Documentation refers to any information that supports the use
of an authoring tool. This information may be found electronically or otherwise
and includes manuals, installation instructions, help mechanisms, sample
workflows, and tutorials, etc.
- Editable
- A property is editable when the authoring tool allows its value to be
changed. It is possible for a Web content property to be editable by one
authoring tool, but not by another.
- Editing
Method
- An editing method is a means by which an author is able to change the
value of an editable property. Examples of editing methods include direct
text entry, selection from a list, etc.
- Editing
View
- An editing view is a view provided by the authoring tool that
allows editing by the author.
- Element
- An element is any identifiable item within a document: for example,
a character, word, image, paragraph, or spreadsheet cell. In [HTML4] and [XML], an element refers to a pair of tags and their
content, or an "empty" tag - one that requires no closing tag
or content.
- End-User
- An end-user is a person who interacts with Web
content once
it has been authored. In some cases, the author and
end-user is the same person.
- Equivalent
Alternative
- An equivalent
alternative is content that is an acceptable substitute for other content
that an end-user may not be able to access. An equivalent alternative fulfills
essentially the same function or purpose as the original content upon presentation
to the end-user.
Equivalent alternatives include text alternatives, which present a text
version of the information conveyed in non-text content such as graphics
and audio clips. The text alternative is considered accessible because
it can be rendered in many different ways (e.g. as synthesized
speech for individuals who have visual or learning disabilities, as Braille
for individuals who are blind, as graphical text for individuals who
are deaf or do not have a disability). Equivalent alternatives also include
"media alternatives", which present essential audio information
visually (captions)
and essential video information auditorily (audio descriptions).
- Format
- A format is a preset specification for organizing
information.
- Inform
- To inform is to make the author aware of an event
or situation using methods
such as alert, prompt, sound, flash. These methods may
be unintrusive (that is, presented without stopping the author's current
activity), or intrusive
(that is, interrupting the author's current activity).
- Information
Icon
- An information icon is a graphic within the authoring interface that
an author can
select to receive additional information.
- Informative
- Informative ("non-normative") parts of this document are never required
for conformance
- Markup
- Markup is a set of tags from a markup
language that specify
the characteristics of a document. Markup can
be presentational (i.e., markup that encodes information about the visual
layout of the content), structural (i.e., markup that encodes information
about the structural role of elements of the content) or semantic (i.e.,
markup that encodes information about the intended meaning of the content).
- Markup
Language
- A markup language is a syntax and/or set of rules used to manage markup (e.g.
HTML [HTML4], SVG [SVG], or MathML [MATHML]).
- Markup,
Unrecognized
- Unrecognized markup are elements, attributes, etc.
that fall outside the DTD that an authoring tool is using to process author
input.
- Normative
- Normative parts of this document are always required
for conformance.
- Object
- An object is one or more elements that together are
perceived as one entity.
- Prominence
- The prominence of a control in the authoring interface
is a heuristic measure of the degree to which authors
are likely to notice a control when operating the authoring tool. In
this document, prominence refers
to visual as well as keyboard-driven navigation. Some of the factors
that contribute to the prominence of a control include: control
size
(large controls or controls surrounded by extra white space may appear
to be conferred higher importance), control order (items
that occur early in the "localized" reading order (e.g. left
to right and top to bottom; right to left and top to bottom, etc.) are
conferred higher importance), control grouping (grouping
controls together can change the reading order and the
related judgments of importance), advanced options (when
the properties are explicitly or implicitly grouped into sets of basic
and advanced properties, the basic properties may gain apparent importance),
and highlighting (controls may be distinguished from others
using icons, color, styling, etc.).
- Prompt
- In this document "prompt" is used
as a mechanism initiated by the authoring tool designed to
urge, suggest, and encourage.
- Property
- A property is a characteristic of an object, for example
structural information (e.g., first class heading, list item)
or presentation information (e.g., bold font, 14pt font).
- Repairing,
Accessibility
- Accessibility repairing is the process by which Web
content accessibility problems that have been identified within Web
content are resolved. ATAG 2.0 identifies three categories
of repair: Automated (i.e. the authoring tool is
able to make repairs automatically, with no author input
required),
Semi-Automated (i.e. the authoring tool can provide
some automated assistance to the author in performing corrections, but
the author's input is still required before the repair can be complete)
and Manual (i.e. the authoring
tool provides the author with instructions for making the necessary correction,
but does not automate the task in any substantial way).
- Transcript
- Transcripts are equivalent alternatives for
the sounds in an audio clip or an auditory track of a multimedia presentation.
A "collated
text transcript"
for a video combines (collates) caption text with text descriptions of
video information (descriptions of the actions, body language, graphics,
and scene changes of the visual track).
- Techniques
- Techniques are informative suggestions and examples for ways in which
the success criteria of a checkpoint might be satisfied.
- Transformation
- A transformation is a process that takes, as input, an object of Web
content in one format and produces, as output, a different object of
Web content in the same format (e.g., a function that transforms tables
into lists).
- Typical
Author
- A person who possesses levels of authoring knowledge, authoring tool
proficiency, and experience with accessibility
authoring practices that are average for users
of a particular authoring tool.
- User Agent
- A user agent is software that retrieves and renders Web content. This
may include Web browsers, media players, plug-ins,
and other programs - including assistive technologies - that help
in retrieving and rendering Web content.
- View
- A view is a rendering of Web content by
an authoring tool.
- Web Content
- Content published on the Web.
- Workflow
- A workflow is a customary sequence of steps or tasks that are followed
to produce a deliverable.
5. References
For the latest version of any W3C
specification please consult the list of W3C
Technical Reports at http://www.w3.org/TR/. Some documents listed below
may have been superseded since the publication of this document.
Note: In this document, bracketed labels such as "[HTML4]"
link to the corresponding entries in this section. These labels are also
identified as references through markup. Normative references are highlighted
and identified through markup.
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/2004/WD-ATAG20-20041122/.
- References to the latest version of "Authoring Tool Accessibility Guidelines
2.0." Use the "latest version" URI to refer to the most recently published
document in the series: http://www.w3.org/TR/ATAG20/.
In almost all cases, references (either by name or by link) should be to a
specific version of the document. W3C will make every effort to make this
document indefinitely available at its original address in its original form.
The top of this document includes the relevant catalog metadata for specific
references (including title, publication date, "this version"
URI, editors' names, and copyright information).
An XHTML 1.0 [XHTML10] paragraph including a
reference to this specific document might be written:
<p>
<cite><a href="http://www.w3.org/TR/2004/WD-ATAG20-20041122">
"Authoring Tool Accessibility Guidelines 1.0",</a></cite>
J. Treviranus, C. McCathieNevile, J. Richards, M. May, eds.,
W3C Recommendation, 16 November 2004.
The <a href="http://www.w3.org/TR/2004/WD-ATAG20-20041122/">latest
version</a> of this document is available at
http://www.w3.org/TR/2004/WD-ATAG20-20041122/.
</p>
For very general references to this document (where stability of content and
anchors is not required), it may be appropriate to refer to the latest version
of this document.
Other sections of this document explain how to build a conformance
claim.
A document appears in this section if at least one reference to the document
appears in a checkpoint success criteria.
- [ISO-TS-16071]
- ISO TS 16071:2003 - Ergonomics of human-system interaction - Guidance
on accessibility for human-computer interfaces. ISO's Web site is http://www.iso.ch.
- [WCAG10]
- "Web Content
Accessibility Guidelines 1.0", W. Chisholm, G. Vanderheiden, and I. Jacobs,
eds., 5 May 1999. This WCAG 1.0 Recommendation is
http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/.
- [WCAG20]
- "Web Content Accessibility
Guidelines 2.0 (Working Draft)", W. Chisholm, G. Vanderheiden,
and J. White, editors. The latest version of the Web Content Accessibility
Guidelines 2.0 is available at http://www.w3.org/TR/WCAG20/. Note:
This document is still a working draft.
- [ATAG10]
- "Authoring Tool Accessibility
Guidelines 1.0", J. Treviranus, C. McCathieNevile, I. Jacobs, and J.
Richards, eds., 3 February 2000. This W3C Recommendation is http://www.w3.org/TR/2000/REC-ATAG10-20000203/.
- [ATAG10-TECHS]
- "Techniques for Authoring
Tool Accessibility", J. Treviranus, J. Richards, I. Jacobs, and C. McCathieNevile
editors. The latest version is available at http://www.w3.org/TR/ATAG10-TECHS.
- [ATAG20-TECHS]
- "Techniques for Authoring
Tool Accessibility 2.0", J. Treviranus, J. Richards, C. McCathieNevile,
and M. May, editors. The latest version is available at http://www.w3.org/TR/ATAG20-TECHS.
- [CSS1]
- "CSS, level 1 Recommendation",
B. Bos and H. Wium Lie, editors., 17 December 1996, revised 11 January 1999.
This CSS1 Recommendation is http://www.w3.org/TR/1999/REC-CSS1-19990111.
The latest version of CSS1 is available at
http://www.w3.org/TR/REC-CSS1. Note: CSS1 has been superseded
by CSS2. Tools should implement the CSS2 cascade in particular.
- [CSS2]
- "CSS, level 2 Recommendation",
B. Bos, H. Wium Lie, C. Lilley, and I. Jacobs, editors., 12 May 1998. This
CSS2 Recommendation is http://www.w3.org/TR/1998/REC-CSS2-19980512. The
latest version of CSS2 is available
at http://www.w3.org/TR/REC-CSS2.
- [HTML4]
- "HTML 4.01 Recommendation",
D. Raggett, A. Le Hors, and I. Jacobs, editors., 24 December 1999. This
HTML 4.01 Recommendation is http://www.w3.org/TR/1999/REC-html401-19991224.
The latest version of HTML 4 is available at
http://www.w3.org/TR/html4.
- [MATHML]
- "Mathematical Markup Language",
P. Ion and R. Miner, editors., 7 April 1998, revised 7 July 1999. This MathML
1.0 Recommendation is http://www.w3.org/1999/07/REC-MathML-19990707. The
latest version of MathML 1.0 is available
at http://www.w3.org/TR/REC-MathML.
- [PWD-USE-WEB]
- "How
People With Disabilities Use the Web", J. Brewer, editor, 4 January
2001. The latest version of How People with Disabilities Use the Web is
available at http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/.
- [RDF10]
- "Resource
Description Framework (RDF) Model and Syntax Specification", O. Lassila,
R. Swick, editors. The 22 February 1999 Recommendation is http://www.w3.org/TR/1999/REC-rdf-syntax-19990222.
The latest version of RDF 1.0 is available
at http://www.w3.org/TR/REC-rdf-syntax.
- [SVG]
- "Scalable Vector Graphics (SVG) 1.0
Specification (Working Draft)", J. Ferraiolo, editor. The latest version
of the SVG specification is available at http://www.w3.org/TR/SVG.
- [UAAG10]
- "User Agent Accessibility Guidelines
1.0", I. Jacobs, J. Gunderson, E. Hansen, editors, 17 December
2002. This is a W3C Recommendation.
- [UAAG10-TECHS]
- "Techniques for User Agent
Accessibility Guidelines 1.0", J. Gunderson and I. Jacobs, editors.
The latest version of Techniques for User
Agent Accessibility Guidelines 1.0 is available at http://www.w3.org/TR/UAAG10-TECHS/.
- [XAG]
- "XML Accessibility Guidelines",
D. Dardailler, S. B. Palmer, C. McCathieNevile, editors, 3 October 2002.
This is a Working Group Draft.
- [XHTML10]
- " XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition)",
S. Pemberton, et al., authors., 26 January 2000, revised 1 August 2002. This
XHTML 1.0 Recommendation is http://www.w3.org/TR/2002/REC-xhtml1-20020801/.
The latest version of XHTML 1.0 is available at
http://www.w3.org/TR/xhtml1.
- [XML]
- "The Extensible Markup
Language (XML) 1.0", T. Bray, J. Paoli, C. M. Sperberg-McQueen, editors.,
10 February 1998. This XML 1.0 Recommendation is http://www.w3.org/TR/1998/REC-xml-19980210.
The latest version of the XML specification
is available at http://www.w3.org/TR/REC-xml.
6. Acknowledgments
The active participants of the Authoring Tool Accessibility Guidelines Working
Group who authored this document were: Tim Boland (National Institute for
Standards and Technology), Barry A. Feigenbaum (IBM), Karen Mardahl (STC),
Matt May (Team Contact, W3C), Greg Pisocky (Adobe), Jan Richards (Adaptive
Technology Resource Centre, University of Toronto), Roberto Scano (IWA/HWG),
and Jutta Treviranus (Chair of the working group, Adaptive Technology Resource
Centre, University of Toronto)
Many thanks to the following people who have contributed to the AUWG through
review and comment: Kynn Bartlett, Giorgio Brajnik, Judy Brewer, Wendy Chisholm,
Daniel Dardailler, Geoff Deering, Katie Haritos-Shea, Kip Harris, Phill
Jenkins, Len Kasday, Marjolein Katsma, William Loughborough, Charles McCathieNevile,
Matthias Müller-Prove, Liddy Nevile, Graham Oliver, Bob Regan, Chris
Ridpath, Gregory Rosmaita, Heather Swayne, Gregg Vanderheiden, Carlos Velasco,
and Jason White.
This document would not have been possible without the work of those
who contributed to ATAG 1.0.