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. The latest status of this document series
is maintained at the W3C.
This is a Public Working Draft of a document which will supersede the W3C
Recommendation "Authoring Tool Accessibility Guidelines 1.0" [ATAG10].
It has been made available for review by W3C Members and other interested
parties, in accordance with W3C Process. It is not endorsed by the W3C or
its Members. It is inappropriate to refer to this document other than as a
work in progress.
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 (e.g., Frequently Asked Questions (FAQ) about ATAG 2.0, issues, implementation reports, and
test suites). Please consult the AUWG home
page for more information.
Patent disclosures relevant to this specification may
be found on the Working Group's patent
disclosure page in conformance with W3C policy.
This draft refers non-normatively to the Techniques for
Authoring Tool Accessibility Guidelines 2.0 [ATAG20-TECHS].
This draft refers normatively to ATAG 2.0 References
to various versions of the Web Content Accessibility Guidelines (WCAG). This
is explained in Section 1.3.1.
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.
For information about the current activities of the working group, please
refer to the AUWG home page.
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 the checkpoints for convenient
reference (e.g., as a tool for developers to evaluate software for conformance)
@@from RS@@.
- 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 AUWG 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 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.
In order 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):
1.1.1 Code-level Authoring Functions: Author has 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.
1.1.2 WYSIWYG ("What-you-see-is-what-you-get") Authoring
Functions: Author has control over entities that closely resemble
the final appearance and behavior of the resulting Web content.
Examples: rendered document editors, bitmap graphics editors,
etc.
1.1.3 Object Oriented Authoring Functions: Author has
control over non-WYSIWYG entities that represent a functional abstraction
from the low level aspects of the resulting Web content.
Examples: timelines, waveforms, vector-based graphic editors,
etc.
1.1.4 Indirect Authoring Functions:
Authors have control of 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@@KM added@@, 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 a consumer of that Web content.
As an introduction to accessible authoring tool design,
consider that the authors and consumers 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 consumers 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 Web content consumers beyond those listed in these
various disability-related contexts. For example, a person may have average
hearing, but still require an alternative representation for audio information
due to a noisy workplace. Similarly, a person working in an eyes-busy environment
may require an audio equivalent to information they cannot view.
1.3 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)" [XAG10] explains the responsibilities
of XML format designers; many XAG requirements make sense for non-XML formats
as well.
- 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.
- 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 explains the responsibilities
of authoring tool developers.
In particular, ATAG 2.0 has a special normative
relationship with the WCAG because WCAG serves as the
accessibility benchmark against which the Web content produced by authoring
tools can be judged. WCAG also serves as the accessibility benchmark for authoring
interfaces that are Web-based.
In addition, while the
W3C documents listed here provide robust coverage of Web-based technologies,
the W3C has not published any documents specifically covering the accessibility
of general-purpose software interfaces that are not Web-based. Instead of duplicating
the high quality work that exists outside of W3C in this area, the Working Group
has chosen to reference an International Organization for Standards (ISO) document
that is under development, entitled: "Ergonomics of human-system interaction
- Guidance on accessibility for human-computer interfaces (ISO TS 16071:2003)".
1.3.1 Relationship to "Web Content
Accessibility Guidelines (WCAG)"
ATAG 2.0 depends on WCAG to act as an accessibility benchmark
and define the terms "Accessible
Web Content" and "Accessible
Authoring Interface (Web-Based)".
At the time of publication, one version of WCAG is a W3C
Recommendation, version 1.0 [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 whichever version of WCAG makes the most sense to
use as the accessibility benchmark for a given authoring tool. The Working Group
does recommend considering the following factors when deciding which on a 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.
Note: The most important ATAG 2.0 references
to WCAG occur within two types of Relative Priority checkpoints. The conformance
section includes an explanation of how the normative
WCAG references are to be resolved.
1.3.2 Relationship to "Ergonomics
of human-system interaction - Guidance on accessibility for human-computer
interfaces (ISO TS 16071:2003)"
For the reason stated above, ATAG
2.0 depends on the International Standards Organization (ISO) document titled
"Ergonomics of human-system interaction - Guidance on accessibility for
human-computer interfaces (ISO TS 16071:2003)" [ISO16071]
to define the term "Accessible
Authoring Interface (Not Web-Based)". The ISO document contains guidelines
relevant to software and operating system accessibility. It is expected that
final publication could occur in 2006.
Note: The most important ATAG 2.0 references
to the ISO document occur within one type of Relative Priority checkpoint. The
conformance section includes an explanation of the normative
ISO reference.
1.4 How this document is organized
The four guidelines that reflect steps towards development
of accessible authoring tools:
- Guideline 1: Make the @@authoring interface@@
tool
itself 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. (Informative)
- An explanation of the guideline. (Informative)
- A list of checkpoint definitions.
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. (Informative)
- A pointer to implementation techniques for that checkpoint. (Informative)
- Success criteria for testing whether a checkpoint has been met. These requirements
must be satisfied by the user agent for conformance. (Normative)
A separate document, entitled "Implementation Techniques
for Authoring Tool Accessibility Guidelines 2.0" [ATAG20-TECHS],
provides suggestions and examples of how to achieve the success criteria in
this document.
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 create valid, standards-based Web content,
this can be rendered reliably by more user agents, including assistive technologies
(Checkpoint 2.1). The next responsibility is to support formats that enable
accessible content (Checkpoint 2.2).
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 ensuring that it is possible to author
accessible content (Checkpoint 2.3), preserving accessible or unknown content
(Checkpoint 2.4), automatically generating accessible content (Checkpoint
2.5), and including accessible pre-authored content (Checkpoint 2.6).
- 2.1 Ensure that markup which
the tool automatically generates is valid for the language the tool is
generating. [Priority 1]
-
Rationale: Following language specifications is the
most basic requirement for accessible content production. When content
is valid, it is easier to check and correct accessibility errors and
user agents are better able to render
the content properly and personalize the content to the needs of individual
content consumer's devices.
Techniques: Implementation Techniques for Checkpoint 2.1,
Evaluation Techniques for Checkpoint 2.1
Success Criteria:
- All markup strings written automatically by the tool (i.e. not
authored "by hand") must conform to
the applicable markup language specification.
- 2.2
Support formats that enable the creation of @@content that conforms
to WCAG@@
WCAG-conformant content. [Priority 1]
-
Rationale: Some formats enable
the creation of web content that conforms to WCAG,
while other formats may intrinsically preclude this possibility. This
is achieved when a public WCAG techniques document explains how to meet
each applicable WCAG checkpoint. Non-text formats may still meet this
requirement if they support equivalent alternatives.
Note that the format's WCAG techniques document must contain techniques
that fully satisfy a given conformance level of WCAG in order to claim
that level of eligibility for ATAG 2.0.
-
Techniques: Implementation Techniques for Checkpoint 2.2,
Evaluation Techniques for Checkpoint 2.2
Success Criteria:
- In order to give priority to a format,
that format must have a published techniques document for
meeting each WCAG checkpoint @@jr idea???:
(that applies to the content that an authoring tool is capable of
producing)@@. @@from techs@@
The authoring tool must support at least one WCAG-capable
format for each Web content type produced. @@???@@When format selection is automatic, the selected format must
be WCAG-capable. @@???@@
- 2.3 Ensure that the author
can produce accessible content in the markup language(s) supported by the tool. [Priority 1]
-
Rationale: The ability to produce accessible Web content
is the most basic requirement of this document.
Techniques: Implementation Techniques for
Checkpoint 2.3, Evaluation Techniques for Checkpoint 2.3
Success Criteria:
- Tools must always meet at least one of the following:
(1) generate accessible content automatically, (2) provide the author
with accessible options for every authoring task, or (3) provide
a method for authoring "by hand"
- 2.4 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 (i.e. taking content encoded in one
markup language and re-encoding it in another) or transformations (i.e.
modifying the encoding of content without changing the markup language).
Accessibility information should
also be preserved.
Techniques: Implementation Techniques for Checkpoint
2.4, Evaluation Techniques for Checkpoint 2.4
Success Criteria:
- During all transformations and conversions, all unrecognized markup
and accessibility information must be preserved, unless
prevented by limitations of the target format.
- When unrecognized markup or accessibility information cannot be
preserved during a conversion or transformation, the author must
be notified before any change is made.
- 2.5
Ensure that when the tool automatically generates content it conforms
to WCAG. [WCAG Relative Priority
(Web Content)]
-
Rationale: Authoring tools that automatically generate
content that does not conform to WCAG are an
obvious source of accessibility problems.
Techniques: Implementation Techniques for
Checkpoint 2.5, Evaluation Techniques for Checkpoint 2.5
Success Criteria:
- All markup strings written automatically by
the tool (i.e. not authored
"by hand") must be accessible (i.e. meet the Web
content checkpoints requirements to Level 1, 2, or 3). @@mm:
maybe we should just say WCAG in the document
and link to our section discussing this@@
Unless the author explicitly instructs the authoring tool otherwise,
all content generated by the tool must conform to WCAG.
@@replaced by tech version@@
- 2.6
Ensure that all pre-authored content for the tool conforms to WCAG.@@ed: link to multiplexor@@[WCAG
Relative Priority (Web Content)]
-
Rationale: Pre-authored content (e.g. templates, images,
videos) is often included with authoring tools for the convenience of
the author. When this content conforms to WCAG,
it is more convenient for authors and more easily reused.
Techniques: Implementation Techniques for
Checkpoint 2.6, Evaluation Techniques for Checkpoint 2.6
Success Criteria:
- Any Web content (e.g. templates, clip art,
multimedia objects, scripts, applets, example pages, etc.) preferentially
licensed (i.e. better terms of use for users of tool than for others)
for users of the tool, must be accessible (i.e. meet the
Web content checkpoints requirements
to Level 1, 2, or 3).
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
authoring practices (Checkpoint 3.8) and workflow processes that result
in accessible content (Checkpoint 3.9).
All functions that support accessible
authoring practices should allow author preferences to be configurable
to allow for different authoring styles. Custom configurations should improve
use of the tool and make authors more receptive to assistive interventions
from the authoring tool.
- 3.1 Prompt and assist the author
to create accessible content. [WCAG Relative Priority (Web Content)]
-
Rationale: Appropriate assistance should increase
the likelihood that typical authors will 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, Evaluation Techniques for Checkpoint 3.1
Success Criteria:
- When the actions of the author risk creating
Web content that is not accessible (i.e. fails to meet the Web
content checkpoints requirements to Level 1, 2, or 3) (e.g.
image inserted, author typing invalid element into a code view,
author initiating a page creation wizard, etc.), the tool must
introduce the appropriate accessible authoring practice.
- 3.2 Check for and inform the author of accessibility problems. [WCAG Relative Priority (Web Content)]
-
Rationale: Authors may not notice or be able to identify
accessibility problems. The tool can assist in their identification.
Techniques: Techniques for checkpoint 3.2,
Evaluation Techniques for Checkpoint 3.2.
Success Criteria:
- The tool must provide a check
(automated check, semi-automated check, or manual check) for detecting
violations of each accessibility requirement (i.e. violations of
the Web content checkpoints requirements
to Level 1, 2, or 3).
- 3.3 Assist authors in repairing
accessibility problems. [WCAG Relative Priority (Web Content)]
-
Rationale: Assistance by the tool may simplify the
task of repairing accessibility problems for some authors, and make
it possible for others.
Techniques: Techniques for checkpoint 3.3,
Evaluation Techniques for Checkpoint 3.3
Success Criteria:
- The tool must provide a repair (automated
repair, semi-automated repair, or manual repair) for correcting violations
of each accessibility requirement (i.e. violations of the Web
content checkpoints requirements to Level 1, 2, or 3).
- 3.4
Do not automatically generate equivalent alternatives @@need to synchronize with WCAG@@ or
reuse previously authored alternatives without author confirmation, except
when the function is known with certainty. [Priority
2]
- @@do we to say "text-alternative" instead
of equivalent alternative (like WCAG)@@
-
Rationale: Improperly generated alternatives can create
accessibility problems and interfere with accessibility checking.
Techniques: Implementation Techniques for Checkpoint
3.4, Evaluation Techniques for Checkpoint 3.4
Success Criteria:
- When the author inserts an unrecognized non-text object, the tool
must not 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 (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 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 @@jr: and sharing: http://lists.w3.org/Archives/Public/w3c-wai-au/2004JulSep/0121.html@@
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 Checkpoint 3.4.
Techniques: Implementation Techniques for Checkpoint
3.5, Evaluation Techniques for Checkpoint 3.5
Success Criteria:
- When non-text objects have been previously inserted using the
tool, the tool must suggest any previously authored textual equivalents
for that non-text object.
When objects, for
which alternative equivalents have been previously provided, are
inserted, the tool must always offer those alternative
equivalents for reuse or modification.(@@replaced by tech version@@)
- 3.6 Provide
the author with a summary of
the document's 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: Techniques for checkpoint 3.6,
Evaluation Techniques for Checkpoint 3.6.
Success Criteria:
- The tool must provide the author with an option to view
a listing of all current accessibility problems.
- 3.7 Document all features of the
tool that promote the production of accessible content. [Priority 2]
-
Rationale: Without documentation
of the features that promote accessibility (e.g. prompts for alternates,
code validators, accessibility checkers, etc.) authors may not find
or use them.
Techniques: Techniques for checkpoint 3.7,
Evaluation 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 2]
-
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 reinforces
the message of accessibility that is being promoted and facilitates
a better understanding of the reasoning behind its use and its consequences.
Authors are also more likely to use features that promote accessibility
if they understand when and how to use them.
-
Techniques: Implementation Techniques
for Checkpoint 3.8, Evaluation Techniques for Checkpoint 3.8
Success Criteria:
- All examples of markup code and views of the authoring interface
(dialog screenshots, etc.) must meet the requirements of
WCAG, regardless of whether the examples
are intended to demonstrate accessibility authoring practices.
- 3.9 Document the workflow process
of using the tool to produce accessible content. [Priority
3]
-
Rationale: @@???@@MM action item
-
Techniques: Implementation Techniques for Checkpoint
3.9, Evaluation Techniques for Checkpoint 3.9
Success Criteria:
- The documentation must contain suggested content creation
workflow descriptions that include how and when to use the accessibility-related
features of the tool.
- For tools that lack a particular accessibility-related feature,
the workflow description must include a workaround for
the missing feature.
-
Required: The guidelines title/version and URI of the guidelines: "Authoring
Tool Accessibility Guidelines 2.0" (http://www.w3.org/@@@@)
-
-
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" (http://www.w3.org/@@@@)
- Required: The formats produced by the tool. For each format include the
URI of the published WCAG techniques document, if one exists: e.g. "HTML
Techniques for WCAG 2.0" (http://www.w3.org/@@@@)
- Optional: A description of the authoring tool that identifies
the types of authoring tool functions that are
present in the tool.
3.2.2 Conformance Details
An ATAG 2.0 conformance claim must include a description
of how the authoring tool meets each of the checkpoints that are required
for the conformance level specified by the conformance
profile. In the case of relative priority checkpoints, this description
is required to be a point-by-point accounting of the requirements in the
external document. A checkpoint is considered to have been met when
the tool satisfies all of the normative success criteria listed for that
checkpoint.
3.2.3 Notes on Making
a Conformance Claim
A conformance claim (with or without an accompanying ATAG
2.0 conformance icon) is an assertion by a claimant that an authoring tool
has satisfied the requirements of a chosen conformance level.
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.
Publishing Claims
- Conformance claims may be published anywhere (e.g., on the Web or in paper
documentation).
- 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.
- If usability tests are referenced, the details of the testing methods and
results must also be published. @@rework of a note about usability@@
Bundling Tools for Conformance
Claims
A conformance claim may cover more than one tool used in conjunction (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 with ATAG 2.0 by themselves,
as long as:
- The tools are distributed together.
- The workflow used to determine the conformance of the tool bundle is typical
of how the tools are used together.
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.
- Accessible
- Within these guidelines, there are three types of
accessibility:
- Accessibility
- ???
- Accessibility
Information
- Any information that is necessary for an accessible
authoring practice including, but is not limited to, equivalent alternative information.
- Accessibility
Problem (Authoring Interface (Not Web-Based))
- An aspect of a non-Web-based authoring
tool interface that fails to meet a success criteria of the checkpoints
of Guideline 1. The severity of the problem
is defined by the ATAG 2.0 priority level of the
failed checkpoint. Two of the checkpoints have Relative
Priorities that refer to ISO16071.
- Accessibility
Problem (Authoring Interface (Web-Based))
- An aspect of a non-Web-based authoring
tool interface that fails to meet a success criteria of the checkpoints
of Guideline 1. The severity of the problem
is defined by the ATAG 2.0 priority level of the
failed checkpoint. Two of the checkpoints have Relative
Priorities that refer to WCAG via "Resolving ATAG References to
WCAG" [WCAG-REFS].
- Accessibility
Problem (Web Content)
- Web content that fails to meet some requirement of the Web Content Accessibility
Guidelines. The severity of the problem in the context of ATAG 2.0 is defined
Relative Priority checkpoints that refer
to WCAG via the "Resolving ATAG References to WCAG" [WCAG-REFS]
document.
- Accessible
Authoring Practice
- Web content modifications made by the author or the tool that increase
the likelihood of producing accessible
Web content.
Accessible Authoring Interface (Not Web-Based)Authoring tool interface,
that is not Web-based, with no authoring
tool interface accessibility problems.Accessible Authoring Interface (Web-Based)Authoring tool interface,
that is Web-based, with no authoring
tool interface accessibility problems.Accessible Web ContentWeb content with no Web content
accessibility problems.- Alert
- An "alert" draws the author's attention to an event or situation. It may
require a response from the author.
- Attribute
- This document uses the term "attribute" as used in SGML and XML [XML]: Element types may be defined as having any number
of attributes. Some attributes are integral to the accessibility of content
(e.g., the
"alt", "title", and "longdesc"
attributes in HTML).
- Auditory
Description
- An "auditory description" provides information about actions, body language,
graphics, and scene changes in a video. Auditory 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 auditory description
is either a pre-recorded human voice or a synthesized voice (recorded or
automatically generated in real time). The auditory description must be
synchronized with the auditory track of a video presentation, usually during
natural pauses in the auditory track.
- Author
- For the purposes of this document, an author is a
user of an authoring tool. This may include content authors, designers,
programmers, publishers, testers, etc.
- Authored
"by hand"
- When the author specifies the precise text string, as by typing into a
text editor.
- Authoring
Action
- ???
- Authoring
Interface
- The display and control mechanism available to an
author to communicate with and operate the authoring tool software. Authoring
tool interfaces may we Web-Based (i.e. consisting of Web content) or not.
- Authoring Tool
- See "Definition of
authoring tool"
- Captions
- "Captions" are essential 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.
- Configurability
- ???@@new dfn@@
- Continuously
Active Process
- ???@@new dfn@@
- Conversion
Tool
- A "conversion tool" is any application or application feature (e.g.,"Save
as HTML") that transforms convert in one format to another format (such
as a markup language).
- Checking
- The process by which web content is evaluated for accessibility problems.
This applies to evaluations performed automatically or with assistance from
the author. The evaluation may be performed at specific times or be performed
on an continuous basis as Web content is modified. For more information
on checking, see checkpoint 3.2.
- Display
- ???
- Document
- A "document" is a series of elements that are defined by a markup language (e.g., HTML 4 or an XML
application).
- Documentation
- Documentation: Documentation refers to 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@@???@@
- ???
- Editing Method@@???@@
- ???
- Editing
View
- An "editing view" is a view provided by the authoring tool that
allows editing.
- Element
- An "element" is any identifiable object 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.
- Equivalent Alternative
- Content is "equivalent" to other content
when both fulfill essentially the same function or purpose upon presentation
to the content consumer. Equivalent alternatives play an important role
in accessible authoring practices since certain types of content may not
be accessible to all authoring content consumers (e.g., video, images, audio,
etc.). Authors are encouraged to provide text equivalents for non-text content
since text may be rendered as synthesized speech for individuals who have
visual or learning disabilities, as Braille for individuals who are blind,
or as graphical text for individuals who are deaf or do not have a disability.
For more information about equivalent alternatives, please refer to the
Web Content Accessibility Guidelines [WCAG-REFS].
- Format
- ???
- Inform
- To "inform" is to make the author aware of an event or situation through
alert, prompt, sound, flash, or other means.
- Information
Icon
- Any graphic that an author can select to receive additional information.
- Markup
- Set of tags that specify the characteristics of a document.
Markup can be presentational, structural or semantic.
- Markup
Language
- Authors encode information using a "markup language" such as HTML [HTML4], SVG [SVG], or MathML [MATHML].
- Normative
- What is identified as "normative" is required
for conformance (noting that one may conform in a variety of well-defined
ways to this document). What is identified as "informative" (sometimes,
"non-normative") is never required for conformance. @@NEW-from
UAAG@@
- Object
- ???
- Presentation
Markup
- "Presentation markup" is markup language that encodes information
about the desired presentation or layout of the content. For example, Cascading
Style Sheets [CSS1], [CSS2] can be used to control fonts, colors, aural
rendering, and graphical positioning. Presentation markup should not be
used in place of structural markup to convey structure.
For example, authors should mark up lists in HTML with proper list markup
and style them with CSS (e.g., to control spacing, bullets, numbering, etc.).
Authors should not use other CSS or HTML incorrectly to lay out content
graphically so that it resembles a list.
- Prominence
- The "prominence" of a control in the authoring interface is
a heuristic measure of the degree to which users take notice of the control
when operating the system. In these guidelines, "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: Larger controls or controls surrounded by more whitespace
may appear to be conferred higher importance.
- Control Order: Without any other forms of organization, most people
will read interface items in a "localized" reading order (i.e.
left to right and top to bottom; right to left and top to bottom, etc.).
The higher visibility of items that occur early in the reading order
confers higher apparent importance.
- Control Grouping: Grouping input fields (e.g. in a vertical list,
etc.) 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.
- Highlighting: Controls may be distinguished from others using icons,
color, styling, etc. When these methods are used, it is important to
ensure that that they are consistent with the overall look and feel
of the authoring tool interface (see
Checkpoint 4.4). (An additional consideration is that in order to
meet ATAG Checkpoint 1.1, the highlighting must be implemented so that
it is available through the appropriate API (MSAA, Java Accessibility
API, GNOME accessibility, etc.), allowing an author with disabilities
to access the highlighting through assistive devices).
- Prompt
- In this document prompt does not refer to the narrow
software sense of a "prompt," rather it is used as a verb meaning to urge,
suggest, and encourage. The form and timing that this prompting takes can
be user configurable. "Prompting" does not depend upon the author to seek
out the support but is initiated by the tool. "Prompting" is more than checking,
correcting, and providing help and documentation
as encompassed in guideline
3 @@???@@. The goal of prompting the author is to encourage, urge, and
support the author in creating meaningful equivalent text without causing
frustration that may cause the author to avoid access options. Prompting
should be implemented in such a way that it causes a positive disposition
and awareness on the part of the author toward accessible authoring practices.
- Property
- A "property" is a piece of information about an element, for example structural
information (e.g., it is item number 7 in a list, or plain text) or presentation
information (e.g., that it is marked as bold, its font size is 14). In XML
and HTML, properties of an element include the type of the element (e.g.,
IMG or DL), the values of its attributes, and information associated
by means of a style sheet. In a database, properties of a particular element
may include values of the entry, and acceptable data types for that entry.
- Repairing
- The process by which Web content is modified to solve accessibility problems.
This applies to modifications performed automatically or with assistance
from the author. For more information on repairing, see checkpoint
3.3.
- Structural
Markup
- "Structural markup" is markup language that encodes information
about the structural role of elements of the content. For example, headings,
sections, members of a list, and components of a complex diagram can be
identified using structural markup. Structural markup should not be used
incorrectly to control presentation or layout. For example, authors should
not use the
BLOCKQUOTE element in HTML [HTML4]to achieve an indentation visual layout effect.
Structural markup should be used correctly to communicate the roles of the
elements of the content and presentation markup should be used separately
to control the presentation and layout.
- Transcript
- A "transcript" is a text representation of 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). Collated text transcripts are essential for
individuals who are deaf-blind and rely on Braille for access to movies
and other content.
- Techniques
- Informative suggestions and examples for ways in which the success criteria
of a checkpoint might be satisfied.
- Transformation
- A "transformation" is a process that changes a document or object into
another, equivalent, object according to a discrete set of rules. This includes
conversion tools, software that allows
the author to change the DTD
defined for the original document to another DTD, and the ability to change the markup
of lists and convert them into tables.
- Typical
Author
- A typical author is a hypothetical individual who possesses levels of
authoring knowledge, tool proficiency, and experience with accessibility
issues that fall at the mean of the levels measured from a large random
sample of actual users of an authoring tool.
- User Agent
- A "user agent" is software that retrieves and renders Web content. User
agents include browsers, plug-ins for a particular media type, and some
assistive technologies.
- View
- Authoring tools may render the same content in a variety of ways; each
rendering is called a "view". Some authoring tools will have several different
types of view, and some allow views of several documents at once. For instance,
one view may show raw markup, a second may show a structured tree, a third
may show markup with rendered objects while a final view shows an example
of how the document may appear if it were to be rendered by a particular
browser. A typical way to distinguish views in a graphic environment is
to place each in a separate window.
- Web
Content
- ???
- WCAG-Conformant
- ???
WCAG-Capable FormatA format is WCAG-capable when a public WCAG techniques
document explains how to meet each applicable WCAG checkpoint. Non-text
formats may still be WCAG-capable if they support equivalent
alternatives. Note that the format's WCAG techniques document must contain
techniques that fully satisfy a given conformance level of WCAG in order
to claim that level of eligibility for ATAG 2.0.- Workflow
- The 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/@@@@@.
- 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/@@@@@@@@">
"Authoring Tool Accessibility Guidelines 1.0,"</a></cite>
J. Treviranus, C. McCathieNevile, J. Richards, M. May, eds.,
W3C Recommendation, @@Date@@.
The <a href="http://www.w3.org/TR/ATAG20/">latest
version</a> of this document is available at
http://www.w3.org/TR/ATG20/.</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.
- [ISO16071]
- ISO/TS 16071:2002(E) - Ergonomics of human-system interaction - Guidance
on accessibility for human-computer interfaces. ISO's Web site is http://www.iso.ch.
- [WCAG10]
- @@@@
- [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.
- [CONFORMANCE]
- "Conformance icons
for ATAG 1.0". Information about ATAG 1.0 conformance icons
is available at http://www.w3.org/WAI/ATAG10-Conformance.
- [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-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/.
[WCAG-REFS]ATAG 2.0 References to WCAG,
J. Treviranus, J. Richards, and M. May, editors.- [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), Liddy Nevile, 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, Graham Oliver, 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.
