May be
Superseded
This section describes the status of this document at the time of its
publication. Other documents may supersede this document. A list of current W3C
publications and the latest revision of this technical report can be found in
the W3C technical reports index at
http://www.w3.org/TR/.
Web Accessibility Initiative
This document has been produced as part of the W3C Web Accessibility Initiative (WAI). The goals
of the AUWG are discussed in the Working Group charter. The
AUWG is part of the WAI
Technical Activity.
No
Endorsement
Publication as a Working Draft does not imply endorsement by the W3C
Membership. This is a draft document and may be updated, replaced or obsoleted
by other documents at any time. It is inappropriate to cite this document as
other than work in progress.
Patents
This document was produced by a group operating under the 5 February 2004 W3C
Patent Policy. W3C maintains a public list of any patent
disclosures made in connection with the deliverables of the group; that
page also includes instructions for disclosing a patent. An individual who has
actual knowledge of a patent which the individual believes contains Essential
Claim(s) must disclose the information in accordance with section
6 of the W3C Patent Policy.
This section is informative.
This is a Working Draft of the Authoring Tool Accessibility Guidelines
(ATAG) version 2.0. This document includes recommendations for assisting authoring tool developers to
make their authoring tools more accessible to
people with disabilities, including blindness and low vision, deafness and
hearing loss, learning disabilities, cognitive limitations, motor difficulties,
speech difficulties, and others.
Accessibility, from an authoring tool perspective, includes addressing the
needs of two overlapping user groups with disabilities:
It is important to note that, while the requirements for meeting these two
sets of user needs are separated for clarity within the guidelines, the
accelerating trend toward user-produced content means that, in reality, they
are deeply inter-connected. For example, when a user participates in an online
forum, they frequently author content that is then incorporated with other
content authored by other users. Accessibility problems in either the authoring
user interface or the content produced by the other forum users would reduce
the overall accessibility of the forum.
Notes:
- The term "authoring tools" has a specific
definition in ATAG 2.0. The definition, which includes several normative notes, appears in the Glossary.
- ATAG 2.0 recommends that authoring tools be
capable of producing web content that conforms with WCAG 2.0. However, WCAG 2.0 notes that even
content that conforms to the highest level of WCAG 2.0 (i.e. Level AAA) may
not be "accessible to individuals with all types, degrees, or combinations
of disability, particularly in the cognitive language and learning areas".
Development of authoring tools that address more specialized needs is
encouraged, but is beyond the scope of this document.
- ATAG 2.0 does not include standard usability recommendations, except
where they have a significantly greater impact on people with disabilities
than on other people.
- Authoring tools are just one aspect of web accessibility. For an overview
of the different components of accessibility and how they work together
see:
ATAG 2.0 Layers of
Guidance
The individuals and organizations that may use ATAG 2.0 vary widely and
include authoring tool developers, authoring tool users (authors), authoring tool
purchasers, and policy makers. In order to meet the varying needs of this
audience, several layers of guidance are provided:
- Parts: ATAG 2.0 is divided into two parts, each
reflecting a key aspect of accessible authoring tools. Part A relates to ensuring the accessibility of authoring tool user interfaces to
authors with disabilities. Part B relates to ensuring
support by authoring tools for the creation, by any author (not just those
with disabilities), of web content that is accessible to end
users with disabilities. Both parts include normative
"Conformance Applicability Notes" that apply to all of the success criteria
within that part (see Part A Conformance
Applicability Notes, Part B Conformance
Applicability Notes).
- Principles: Under each part are several high-level
principles that organize the guidelines.
- Guidelines: Under the principles are guidelines. The
guidelines provide the basic goals that authoring tool developers should
work toward in order to make authoring tools more accessible to both
authors and end users of web content with different disabilities. The
guidelines are not testable, but provide the framework and overall
objectives to help authoring tool developers understand the success
criteria. Each guideline includes a brief rationale for why the guideline
was included.
- Success Criteria: For each guideline, testable success
criteria are provided to allow ATAG 2.0 to be used where requirements and
conformance testing are necessary, such as in design specification,
purchasing, regulation, and contractual agreements. In order to meet the
needs of different groups and different situations, multiple levels of full
and partial conformance are defined (see Levels of
Conformance).
- Implementing ATAG 2.0 document: The Implementing
ATAG 2.0 document provides additional non-normative information for
each success criterion, including a description of the intent of the
success criterion, examples and links to related resources.
Levels of Conformance
In order to ensure that the process of using ATAG 2.0 and WCAG 2.0 together in the development of authoring tools is as simple as
possible, ATAG 2.0 shares WCAG 2.0's three level
conformance model: Level A (lowest), AA (middle), AAA (highest).
Integration of Accessibility
Features
When implementing ATAG 2.0, authoring tool developers
should carefully integrate features that support accessible authoring into the
same "look-and-feel" as other features of the authoring
tool. Close integration has the potential to:
- produce a more seamless product;
- leverage the existing knowledge and skills of authors;
- make authors more receptive to new accessibility-related authoring
requirements; and
- reduce the likelihood of author confusion.
Guidelines
The success criteria and the conformance applicability notes in this section
are normative.
PART A: Make the authoring tool user
interface accessible
- Scope of "authoring tool user interface": The Part
A success criteria apply to all aspects of the authoring
tool user interface that are concerned with producing the "included" web content technologies. This
includes views of the web content being edited
and features that are independent of the content being edited, such as
menus, button bars, status bars, user preferences, documentation, etc.
- Reflected content accessibility problems: The authoring tool is responsible for
ensuring that editing-views display the web content being edited
in a way that is accessible to authors with disabilities (e.g. ensuring
that text alternatives
in the content can be programmatically
determined). However, where an accessibility problem is caused directly by the content
being edited (e.g. if an image in the content lacks a text alternative),
then this would not be considered a deficiency in the accessibility of the
authoring
tool user interface.
- Developer control: The Part A success criteria only
apply to the authoring
tool user interface as it is provided by the developer. It does not
apply to any subsequent modifications by parties other than the authoring
tool developer (e.g. by plug-ins, user modifications, etc.).
- User agent features: Web-based authoring tools may rely on user
agent features (e.g. keyboard navigation, find functions, display
preferences, undo features, etc.) to satisfy success criteria. If a conformance claim is made, the claim must cite the
user agent.
- Features for meeting Part A must be accessible: The
Part A success criteria apply to the entire authoring
tool user interface, including any features added to meet the success
criteria in Part A (e.g. documentation, search functions, etc.). The only
exemption is for preview features, as long as they meet the
relevant success criteria in Guideline A.3.7.
Previews are treated differently than editing-views because all authors,
including those with disabilities, benefit when preview features accurately
reflect the functionality of user agents that are actually in use by end users.
PRINCIPLE
A.1: Authoring tool user interfaces must follow applicable accessibility
guidelines
Guideline A.1.1: (For
the authoring tool user interface) Ensure that web-based functionality is
accessible. [Implementing
A.1.1]
Rationale: When authoring
tools (or parts of authoring tools) are web-based,
conforming to WCAG 2.0 will facilitate access by
all authors, including those using assistive technologies.
A.1.1.1 Web-Based Accessible (WCAG): Web-based
authoring tool user interfaces meet the WCAG
2.0 success criteria. [Implementing
A.1.1.1]
The WCAG 2.0 Level A success criteria are met (Level
A); or
The WCAG 2.0 Level A and Level AA success criteria are met (Level AA); or
The WCAG 2.0 Level A, Level AA, and Level AAA success criteria are met (Level
AAA).
Guideline A.1.2: (For
the authoring tool user interface) Ensure that non-web-based functionality is
accessible. [Implementing
A.1.2]
Rationale: When authoring
tools (or parts of authoring tools) are non-web-based,
following existing accessibility guidelines and implementing communication with
platform accessibility
services facilitates access by all authors, including those using
assistive technologies.
PRINCIPLE
A.2: Editing-views must be perceivable
Guideline A.2.1: (For
the authoring tool user interface) Make alternative content available to
authors. [Implementing
A.2.1]
Rationale: Some authors require access to alternative content in order to interact with the web
content that they are editing.
Guideline A.2.2: (For
the authoring tool user interface) Editing-view presentation can be
programmatically determined. [Implementing
A.2.2]
Rationale: Some authors need access to details about the editing-view presentation, via
their assistive technology, when that presentation is used to convey status
information (e.g. underlining misspelled words) or provide information about
how the end user will experience the web content being edited.
A.2.2.1 Editing-View Status Information:
If an editing-view modifies the presentation to convey status information,
then that status information can be programmatically
determined. Status information conveyed by modifying the presentation of
editing-views may include, but is not limited to, spelling, grammar and syntax
errors. (Level A) [Implementing
A.2.2.1]
PRINCIPLE
A.3: Editing-views must be operable
Guideline A.3.1: (For
the authoring tool user interface) Provide keyboard access to authoring
features. [Implementing
A.3.1]
Rationale: Some authors with limited mobility or visual
disabilities are not able to use a mouse, and instead require keyboard access
to all of the functionality of the authoring
tool.
A.3.1.1 Keyboard Access (Minimum): All
functionality of the authoring tool is operable through a keyboard interface without requiring
specific timings for individual keystrokes, except where the underlying
function requires input that depends on the path of the user's movement and not
just the endpoints. (Level A) [Implementing
A.3.1.1]
Note 1: The path exception relates to the underlying function, not the
input technique. For example, if using handwriting to enter text, the input
technique (handwriting) requires path-dependent input, but the underlying
function (text input) does not. The path exception encompasses other input
variables that are continuously sampled from pointing devices, including
pressure, speed, and angle.
Note 2: This success criterion does not forbid and should not discourage
providing mouse input or other input methods in addition to keyboard
operation.
A.3.1.2 No Keyboard
Traps: Keyboard traps are prevented as follows:
(Level A) [Implementing
A.3.1.2](a) In
the Authoring
Tool User Interface: If keyboard focus can be moved to a component
using a keyboard interface, then focus can
be moved away from that component using only a keyboard interface and, if it
requires more than unmodified arrow or tab keys or other standard exit methods,
the user is advised of the method for moving focus away; and (b) In Editing-Views
that Render Content: If an editing-view
renders content (e.g. WYSIWYG view), then a documented
keyboard command is provided that moves the editing-view keyboard focus to a
known location (e.g. the start of the editing-view).
Guideline A.3.2: (For
the authoring tool user interface) Provide authors with enough time. [Implementing
A.3.2]
Rationale: Some authors who have difficulty typing, operating
the mouse, or processing information can be prevented from using systems with
short time limits or that require fast reaction speeds, such as clicking on a
moving target.
A.3.2.1 Content Edits Saved (Minimum): If the authoring tool includes authoring session time limits, then the authoring tool
saves all edits made by authors. (Level A) [Implementing
A.3.2.1]
A.3.2.2 Timing Adjustable: If a time limit is set
by the authoring tool, then at least one of the
following is true: (Level A) [Implementing
A.3.2.2] (a)
Turn Off: Authors are allowed to turn off the time limit
before encountering it; or (b) Adjust: Authors are allowed to adjust the time
limit before encountering it over a wide range that is at least ten times the
length of the default setting; or (c) Extend: Authors are warned before time expires and
given at least 20 seconds to extend the time limit with a simple action (e.g.
"press the space bar"), and authors are allowed to extend the time limit at
least ten times; or (d)
Real-time Exception: The time limit is a required part of a real-time
event (e.g. a collaborative authoring system), and no alternative to the time
limit is possible; or (e)
Essential Exception: The time limit is essential and extending it
would invalidate the activity; or (f) 20 Hour Exception: The time limit is longer than 20
hours.
A.3.2.3 Static Pointer Targets: Authoring
tool user interface components that accept pointer input are either
stationary or authors can pause the movement. (Level A) [Implementing
A.3.2.3]
Guideline A.3.3: (For
the authoring tool user interface) Help authors avoid flashing that could cause
seizures. [Implementing
A.3.3]
Rationale: Flashing can cause seizures in authors with
photosensitive seizure disorder.
A.3.3.1 Static View Option: Editing-views that render visual time-based content can be paused and can be
set to not play automatically. (Level A) [Implementing
A.3.3.1]
Guideline A.3.4: (For
the authoring tool user interface) Enhance navigation and editing via content
structure. [Implementing
A.3.4]
Rationale: Some authors who have difficulty typing or operating
the mouse benefit when authoring tools make use of the
structure present in web content to simplify the tasks of
navigation and editing the content.
Guideline A.3.5: (For
the authoring tool user interface) Provide text search of the content. [Implementing
A.3.5]
Rationale: Some authors who have difficulty typing or operating
the mouse benefit from the ability to use text search to navigate to arbitrary
points within the web content being authored.
A.3.5.1 Text Search: Authors can perform text
searches of web content that meet the following: (Level
AA) [Implementing
A.3.5.1] (a)
Search All Editable: Any information that is text and that the authoring tool can modify is searchable,
including: text content, text alternatives for non-text
content, metadata, markup elements and attributes; and
Note: If the current editing-view is not able
to display the results of a search, then the authoring tool may provide a
mechanism to switch to a different editing-view to display the
results.(b) Two-way:
The search can be made forwards or backwards; and (c) Case Sensitive: The
search can be in both case sensitive and case insensitive modes; and
(d) No Match: Authors
are informed when no results are found.
Guideline A.3.6: (For
the authoring tool user interface) Manage preference settings. [Implementing
A.3.6]
Rationale: Some authors need to set their own display settings in a way that differs
from the presentation that they want to define for
the published web content. Providing the ability to save
and reload sets of keyboard and display preference settings benefits authors who
have needs that differ over time (e.g. due to fatigue).
Guideline A.3.7: (For
the authoring tool user interface) Ensure that previews are as accessible as
existing user agents. [Implementing
A.3.7]
Rationale: Preview features are provided in many authoring tools because the workflow
of authors often includes periodically checking how user
agents will display the web content to end users. Authors with
disabilities need the same opportunity to check their work.
A.3.7.1 Preview (Minimum): If a preview is provided, then
at least one of the following is true: (Level A) [Implementing
A.3.7.1] (a)
Pre-existing User Agent: The preview makes use of a pre-existing user
agent; or (b) UAAG
(Level A): The preview conforms to the User Agent Accessibility
Guidelines Level A [UAAG].
PRINCIPLE
A.4: Editing-views must be understandable
Guideline A.4.1: (For
the authoring tool user interface) Help authors avoid and correct mistakes.
[Implementing
A.4.1]
Rationale: Some authors who have difficulty
making fine movements may be prone to making unintended actions.
A.4.1.1 Content Changes Reversible (Minimum): For
authoring actions, one of the following are true: (Level A)
[Implementing
A.4.1.1]
Note 1: Reversing actions (e.g. an "undo" function) are also
considered authoring actions, meaning they must also meet this success
criterion (e.g., a "redo" function).
Note 2: It is acceptable to collect a series of text entry actions
(e.g. typed words, a series of backspaces) into a single reversible authoring
action.
Note 3: It is acceptable to clear the authoring action history at the
end of authoring sessions. (a) Reversible: The authoring action can be immediately
reversed; or (b) Warn
and Confirm: The authoring tool includes a warning to authors that
the action is irreversible and
requires authors to confirm the action before proceeding.
A.4.1.2 Setting Changes Reversible: If actions
modify authoring tool settings, then one of the
following are true: (Level A) [Implementing
A.4.1.2] (a)
Reversible: The authoring tool setting can be reversed by the same
mechanism that made the change; or (b) Warn and Confirm: The authoring tool includes a
warning to authors that the action is irreversible and requires authors to confirm the action or
save the current settings before proceeding.
Guideline A.4.2: (For
the authoring tool user interface) Document the user interface including all
accessibility features. [Implementing
A.4.2]
Rationale: Some authors may not be able to
understand or operate the authoring
tool user interface without proper accessible documentation.
PART B: Support the production of
accessible content
Part B Conformance Applicability Notes:
- Author availability: Any Part B success criteria
that refer to authors only apply during authoring sessions.
- Developer control: The Part B
success criteria only apply to the authoring
tool as it is provided by the developer. This does not
include subsequent modifications by parties other than the authoring tool
developer (e.g. by plug-ins, user-defined templates, user modifications of
default settings, etc.).
- Applicability after the end of an authoring
session: Authoring tools are responsible for
the accessibility of web content that they automatically
generate after the end of an
author's authoring session (see Success Criterion
B.1.1.1). For example, if the developer changes the site-wide templates of a content management system, these would
be required to meet the accessibility requirements for
automatically-generated content. Authoring tools are not responsible for
changes to the accessibility of content that the author has specified,
whether it is author-generated or
automatically-generated by another system that the author has specified
(e.g. a third-party feed).
- Authoring systems: As per the ATAG
2.0 definition of authoring tool, several software
tools (identified in any conformance claim) can
be used in conjunction to meet the requirements of Part B (e.g. an
authoring tool could make use of a third-party software accessibility
checking tool).
- Features for meeting Part B must be
accessible: The Part A success criteria
apply to the entire authoring
tool user interface, including any features that must be present to
meet the success criteria in Part B (e.g. checking tools, repair tools,
tutorials, documentation, etc.).
- Multiple author roles: Some authoring tools include multiple author
roles, each with different views and content editing permissions (e.g. a content management system may
separate the roles of designers, content authors, and quality assurers). In
these cases, the Part B success criteria apply to the authoring tool as a
whole, not to the view provided to any particular author role. Accessible content
support features should be made available to any author role where it
would be useful.
PRINCIPLE
B.1: Fully automatic processes must produce accessible content
Guideline B.1.1: Ensure
automatically specified content is accessible. [Implementing
B.1.1]
Rationale: If authoring
tools automatically specify web content
that is not accessible, then additional repair tasks are imposed on
authors.
B.1.1.2 Content Auto-Generation During Authoring Sessions
(WCAG): Authors have the default
option that, when web content is automatically generated during an authoring session, then one of the following is true: [Implementing
B.1.1.2]
Note 1: Automatic generation includes automatically selecting
templates for authors.
Note 2: This success criterion applies only to automatic processes
specified by the authoring tool developer. It
does not apply when author
actions prevent generation of accessible web content.
(a) Accessible: The
content is accessible web content (WCAG)
without author input; or (b) Prompting: During the automatic generation process,
authors are prompted for any required accessibility information
(WCAG); or (c)
Automatic Checking: After the automatic generation process,
accessibility checking is automatically performed; or (d) Checking Suggested: After
the automatic generation process, the authoring tool prompts authors to perform
accessibility checking. The WCAG 2.0 Level A
success criteria are met (Level A); or
The WCAG 2.0 Level A and Level AA success criteria are met (Level AA); or
The WCAG 2.0 Level A, Level AA, and Level AAA success criteria are met (Level
AAA).
Guideline B.1.2: Ensure
accessibility information is preserved. [Implementing
B.1.2]
Rationale: Accessibility information is
critical to maintaining comparable levels of accessibility between the input
and output of web content transformations.
B.1.2.1 Restructuring and Recoding Transformations
(WCAG): If the authoring tool provides restructuring
transformations or re-coding transformations,
then at least one of the following is true: [Implementing
B.1.2.1]
Note: This success criteria only applies to transformations in which
the output technology is an "included" technology for conformance.(a) Preserve: Accessibility information
(WCAG) is preserved in the output; or (b) Warning: Authors have the
default option to be warned that accessibility information may be lost (e.g.,
when saving a vector graphic into a raster image format); or (c) Automatic Checking: After
the transformation, accessibility checking is automatically performed; or
(d) Checking
Suggested: After the transformation, the authoring tool prompts
authors to perform accessibility checking. The WCAG 2.0 Level A success criteria are met (Level A);
or
The WCAG 2.0 Level A and Level AA success criteria are met (Level AA); or
The WCAG 2.0 Level A, Level AA, and Level AAA success criteria are met (Level
AAA).
PRINCIPLE
B.2: Authors must be supported in producing accessible content
Guideline B.2.1: Ensure
accessible content production is possible. [Implementing
B.2.1]
Rationale: For the purposes of this
document, WCAG 2.0 defines the accessible web content (WCAG)
requirements. To support accessible web content production, at minimum, it must
be possible to produce web content that conforms with WCAG 2.0 using the authoring
tool.
B.2.1.1 Accessible Content Possible (WCAG): If the
authoring tool places restrictions on the
web
content that authors can specify, then those restrictions do not prevent
WCAG 2.0 success
criteria from being met: [Implementing
B.2.1.1] The WCAG 2.0 Level A
success criteria can be met (Level A); or
The WCAG 2.0 Level A and Level AA success criteria can be met (Level AA); or
The WCAG 2.0 Level A, Level AA, and Level AAA success criteria can be met
(Level AAA).
Guideline B.2.2: Guide
authors to produce accessible content. [Implementing
B.2.2]
Rationale: By guiding authors from the outset
toward the creation and maintenance of accessible web content (WCAG) ,
web
content accessibility problems (WCAG) are mitigated and less repair
effort is required.
B.2.2.1 Accessible Option Prominence (WCAG): If authors are
provided with a choice of authoring actions for achieving the
same authoring outcome (e.g. styling text), then options that
will result in accessible web content (WCAG) are at least as prominent as options
that will not. (Level A) [Implementing
B.2.2.1] The WCAG 2.0 Level A
success criteria are met (Level A); or
The WCAG 2.0 Level A and Level AA success criteria are met (Level AA); or
The WCAG 2.0 Level A, Level AA, and Level AAA success criteria are met (Level
AAA).
B.2.2.2 Setting Accessibility Properties (WCAG): If
the authoring tool provides mechanisms to set web content properties (e.g.
attribute values, etc.), then mechanisms are also provided to set web content
properties related to accessibility information
(WCAG): [Implementing
B.2.2.2]
Note: Success Criterion B.4.1.4 addresses the
prominence of the mechanisms. The WCAG 2.0 Level A
success criteria are met (Level A); or
The WCAG 2.0 Level A and Level AA success criteria are met (Level AA); or
The WCAG 2.0 Level A, Level AA, and Level AAA success criteria are met (Level
AAA).
Guideline B.2.3: Assist
authors with managing alternative content for non-text content. [Implementing
B.2.3]
Rationale: Improperly generated alternative content can create accessibility
problems and interfere with accessibility checking.
See Also: This guideline applies when non-text
content is specified by authors (e.g. inserts an image). When non-text content is
automatically added by the authoring tool, see Guideline B.1.1.
Guideline B.2.4: Assist
authors with accessible templates. [Implementing
B.2.4]
Rationale: Providing accessible
templates and other pre-authored content (e.g. clip art, synchronized
media, widgets, etc.) can have several benefits, including: immediately
improving the accessibility of web content being
edited, reducing the effort required of authors, and demonstrating
the importance of accessible web content (WCAG)
.
Guideline B.2.5: Assist
authors with accessible pre-authored content. [Implementing
B.2.5]
Rationale: Providing accessible templates and other
pre-authored content (e.g. clip art, synchronized media, widgets, etc.) can
have several benefits, including: immediately improving the accessibility of web content being
edited, reducing the effort required of authors, and demonstrating
the importance of accessible web content
(WCAG).
B.2.5.1 Pre-Authored Content Selection Mechanism:
If authors are provided with a selection mechanism for
pre-authored content other than templates (e.g. clip art
gallery, widget repository, design themes), then both of the following are
true: (Level AA) [Implementing
B.2.5.1] (a)
Indicate: The selection mechanism indicates the accessibility status
of the pre-authored content (if known); and (b) Prominence: Any
accessible options are at
least as prominent as other pre-authored content options.
B.2.5.2 Pre-Authored Content Accessibility Status:
If the authoring tool provides a repository of
pre-authored content, then each of the content objects has a recorded
accessibility status. (Level AAA) [Implementing
B.2.5.2]
PRINCIPLE
B.3: Authors must be supported in improving the accessibility of existing
content
Guideline B.3.1: Assist
authors in checking for accessibility problems. [Implementing
B.3.1]
Rationale: Accessibility checking as an
integrated function of the authoring tool helps make authors aware
of web
content accessibility problems during the authoring process, so they can be
immediately addressed.
B.3.1.4 Status Report: Authors can receive an
accessibility status report based on the results of the accessibility checks.
(Level AA) [Implementing
B.3.1.4]
Note: The format of the accessibility status is not specified. For
example, the status might be a listing of problems detected or a WCAG
2.0 conformance level, etc.
B.3.1.5 Metadata
Production: Authors have the option of associating
accessibility checking results with the web content as
metadata. (Level AA) [Implementing
B.3.1.5]
Note: The metadata format that is implemented will dictate the nature
of the associated results (e.g. specific check results, summary conformance
claims, etc.)
Guideline B.3.2: Assist
authors in repairing accessibility problems. [Implementing
B.2.3]
Rationale: Repair as an integral part of
the authoring process greatly enhances the utility of checking and increases the
likelihood that accessibility
problems will be properly addressed.
PRINCIPLE
B.4: Authoring tools must promote and integrate their accessibility features
Guideline B.4.1: Ensure
the availability of features that support the production of accessible content.
[Implementing
B.4.1]
Rationale: The accessible content
support features will be more likely to be used if they are turned on and
are afforded reasonable prominence within the authoring
tool user interface.
Guideline B.4.2: Ensure
that documentation promotes the production of accessible content. [Implementing
B.4.2]
Rationale: Without documentation
of the features that support
the production of accessible content (e.g. prompts for text alternatives,
accessibility checking tools), some authors may not be able to use them.
Demonstrating accessible authoring as routine practice will encourage its
acceptance by some authors.
Conformance
Conformance means that the authoring tool satisfies the applicable success criteria defined in the guidelines section. This conformance section describes
conformance and lists the conformance requirements.
Relationship to the Web
Content Accessibility Guidelines (WCAG) 2.0
Because WCAG 2.0 [WCAG20] is the most
recent W3C Recommendation regarding web content accessibility, ATAG 2.0
frequently refers to WCAG 2.0 in order to set requirements for (1) the
accessibility of web-based
authoring tool user interfaces (in Part A) and (2)
how authors should be enabled, supported, and guided toward
producing web content that is accessible to end
users with disabilities (in Part B).
Whenever success criteria or defined terms in ATAG 2.0 depend on WCAG 2.0,
they are marked with "(WCAG)".
Note on "accessibility-supported
ways of using technologies":
Part of conformance to WCAG 2.0 is the requirement that "only
accessibility-supported ways of using technologies are relied upon to satisfy
the WCAG 2.0 success criteria. Any information or functionality that is
provided in a way that is not accessibility supported is also available in a
way that is accessibility supported." In broad terms, WCAG 2.0
considers a web content
technology to be "accessibility supported" when (1) the way that the web
content technology is used is supported by users' assistive technology and (2) the
web content technology has accessibility-supported user agents that are
available to end users.
This concept is not easily extended to authoring
tools because many authoring tools can be installed and used in a variety
of environments with differing availabilities for assistive technologies and
user agents (e.g. private intranets versus public websites, monolingual sites
versus multilingual sites, etc.). Therefore:
For the purposes of ATAG 2.0 conformance, the
accessibility-supported requirement is waived.
Once an authoring tool has been installed and put into use, it would be
possible to assess the WCAG 2.0 conformance of the web content that
the authoring tool produces, including whether the WCAG 2.0
accessibility-supported requirement is met. However, this WCAG 2.0 conformance
assessment would be completely independent of the authoring tool's conformance
with ATAG 2.0.
Applicability of Success
Criteria
The ATAG 2.0 definition of authoring tool
is inclusive and, as such, it covers software with a wide range of capabilities
and contexts of operation. In order to take into account authoring tools with
limited feature sets (e.g., a photo editor, a CSS editor, a status update field
in a social networking application, etc.), many of the ATAG 2.0 success
criteria are conditional, applying only to authoring tools with the given
features(s) (e.g., Success Criterion B.1.1.1 applies only to authoring tools
that automatically generate web content after the end of authoring
sessions).
If a conformance claim is made, a declaration that
a success criterion is not applicable requires a rationale.
Conformance Requirements
In order for an authoring tool to conform to ATAG 2.0,
all of the following conformance requirements must be satisfied:
Conformance Levels:
Authoring tools may conform "fully" or
"partially" to ATAG 2.0. In either case, the level of conformance depends on
the level of the success criteria that have been satisfied.
"Full" ATAG 2.0 Conformance: This type of conformance is
intended to be used when developers have considered
the accessibility of the authoring tools from both the perspective of authors (Part A: Make the authoring tool user interface accessible)
and the perspective of end users of web content produced by the authoring tools
(Part B: Support the production of accessible
content):
- Full ATAG 2.0 Conformance at Level A
The authoring tool satisfies all of the applicable Level A success criteria.
- Full ATAG 2.0 Conformance at Level AA
The authoring tool satisfies all of the applicable Level A and
Level AA success criteria.
- Full ATAG 2.0 Conformance at Level AAA
The authoring tool satisfies all of the applicable success
criteria.
And the Part A Conformance
Applicability Notes and Part B Conformance
Applicability Notes have been applied.
"Partial" ATAG 2.0 Conformance: Authoring Tool User
Interface: This type of conformance is intended to be used when
developers have initially focused on the accessibility of the authoring tool to
authors (Part A: Make the authoring tool user interface accessible):
- Partial ATAG 2.0 Conformance Level A: Authoring Tool User
Interface
The authoring tool satisfies all of the applicable Level A success criteria in Part A.
Nothing is implied about Part B.
- Partial ATAG 2.0 Conformance Level AA: Authoring Tool User
Interface
The authoring tool satisfies all of the applicable Level
A and Level AA success criteria in Part A. Nothing is implied about Part B.
- Partial ATAG 2.0 Conformance Level AAA: Authoring Tool User
Interface
The authoring tool satisfies all of the applicable
success criteria in Part A. Nothing is implied about Part B.
And the Part A Conformance
Applicability Notes have been applied.
"Partial" ATAG 2.0 Conformance: Content Production: This
type of conformance is intended to be used when developers have initially
focused on the accessibility of the web content produced by the authoring tool
to end users (Part B: Support the production of accessible content):
- Partial ATAG 2.0 Conformance Level A: Content Production
The authoring tool satisfies all of the applicable Level A success criteria in Part B.
Nothing is implied about Part A.
- Partial ATAG 2.0 Conformance Level AA: Content Production
The authoring tool satisfies all of the applicable Level
A and Level AA success criteria in Part B. Nothing is implied about Part A.
- Partial ATAG 2.0 Conformance Level AAA: Content Production
The authoring tool satisfies all of the applicable
success criteria in Part B. Nothing is implied about Part A.
And the Part B Conformance
Applicability Notes have been applied.
Note: The Working Group remains committed to the guiding
principle that: "Everyone should have the ability to create and access web
content". Therefore, it is recommended that "Partial" Conformance be
claimed only as a step toward "Full" Conformance.
Web Content
Technologies Produced:
Authoring tools conform to ATAG 2.0 with
respect to the production of specific web content technologies (e.g.
Full Level A conformance with respect to the production of XHTML 1.0, Partial
Level AA Conformance: Content Production with respect to the production of SVG
1.1).
If an authoring tool is capable of producing multiple web content
technologies, then the conformance may include only a subset of these
technologies as long as the subset includes any technologies that the developer either sets for automatically-generated content or sets as the default for
author-generated content. The
subset may include "interim" formats that are not intended for publishing to end users, but this is not
required.
When Success Criterion B.2.1.1 refers to web content
technologies for which the authoring tool provides support for the
production of accessible content, it is referring to this subset.
Live publishing authoring tools:
ATAG 2.0 may be applied to authoring tools with workflows that involve live
authoring of web content (e.g. some collaborative tools). Due to the challenges
inherent in real-time publishing, conformance to Part B
of ATAG 2.0 for these authoring tools may involve some combination of support
before (e.g. support in preparing accessible slides), during (e.g. live
captioning as WCAG 2.0 requires at Level AA) and after the live authoring
session (e.g. the ability to add a transcript to the archive of a presentation
that was initially published in real-time). For more information, see the Implementing
ATAG 2.0 - Appendix E: Authoring Tools for Live Web Content.
Conformance Claims (Optional)
If a conformance claim is made, then the conformance claim must meet the
following conditions and include the following information (authoring tools can
conform to ATAG 2.0 without making a claim). Claimants are encouraged to claim
conformance to the most recent version of the Authoring Tool Accessibility
Guidelines Recommendation.
Conditions on
Conformance Claims
- At least one version of the conformance claim must be published on the
web as a document meeting Level A of WCAG 2.0. A suggested metadata
description for this document is "ATAG 2.0 Conformance Claim".
- Whenever the claimed conformance level is published (e.g. product
information web site), the URI for the on-line published version of the
conformance claim must be included.
- The existence of a conformance claim does not imply that the W3C has
reviewed the claim or assured its validity.
- Claimants are solely responsible for the accuracy of their claims and
keeping claims up to date.
Required Components of an ATAG 2.0
Conformance Claim
- Claimant name and affiliation.
- Date of the claim.
- Guidelines title, version
andURI
- Conformance level
satisfied.
- Authoring tool information: The name of the authoring tool and sufficient
additional information to specify the version (e.g. vendor name, version
number (or version range), required patches or updates, human
language of the user interface or documentation).
- Note: If the authoring tool is a collection of software components (e.g. a markup editor, an image editor, and a validation
tool), then information must be provided separately for each component,
although the conformance claim will treat them as a whole. As
stated above, the Claimant has sole responsibility for the conformance
claim, not the developer of any of the software
components.
- Web content technologies
produced.
- A list of the web content
technologies produced by the authoring tool that the Claimant
is including in the conformance claim. For each web
content technology, provide information on how the web content
technology might be used to create accessible web content
(e.g. provide links to technology-specific techniques).
- A list of any web content technologies produced by the authoring tool
that the Claimant is not including in the conformance
claim.
- Declarations: For each success criterion:
- A declaration of whether or not the success criterion has been
satisfied; or
- A declaration that the success criterion is not applicable and a rationale for why not.
- Platform(s): The platform(s) upon which the authoring tool
was evaluated:
Optional Components of an ATAG 2.0
Conformance Claim
- A description of the authoring tool that identifies the
types of editing-views that it includes.
- A description of how the ATAG 2.0 success criteria were
met where this may not be obvious.
"Progress Toward
Conformance" Statement
Developers of authoring tools that do not yet conform
fully to a particular ATAG 2.0 conformance level are encouraged to publish a
statement on progress toward conformance. This statement would be the same as a
conformance claim except that this statement would
specify an ATAG 2.0 conformance level that is being progressed toward, rather
than one already satisfied, and report the progress on success criteria not yet
met. The author of a "Progress Toward Conformance" Statement is solely
responsible for the accuracy of their statement. Developers are encouraged to
provide expected timelines for meeting outstanding success criteria within the
Statement.
Disclaimer
Neither W3C, WAI, nor AUWG take any responsibility for any aspect or result
of any ATAG 2.0 conformance claim that has not been
published under the authority of the W3C, WAI, or AUWG.
Appendix DH: Acknowledgments
Appendix Editors:
- Jan Richards (Adaptive Technology Resource Centre, University of
Toronto)
- Jeanne Spellman (W3C)
- Roberto Scano (IWA/HWG)
Participants
active in the AUWG at the time of publication:
- Tim Boland (National Institute for Standards and Technology)
- Alastair Campbell (Nomensa)
- Cherie Ekholm (Microsoft)
- Alex Li (Microsoft)
- Alessandro Miele (Invited Expert)
- Sueann Nichols (IBM)
- Greg Pisocky (Adobe)
- Jan Richards (Inclusive Design Institute, OCAD University)
- Andrew Ronksley (Royal National Institute for the Blind)
- Roberto Scano (IWA/HWG)
- Jeanne Spellman (W3C)
- Jutta Treviranus (WG Chair; Inclusive Design Institute, OCAD
University)
Other
previously active AUWG participants and other contributors to ATAG 2.0:
Kynn Bartlett, Giorgio Brajnik, Judy Brewer, Wendy Chisholm, Daniel
Dardailler, Geoff Deering, Barry A. Feigenbaum, Katie Haritos-Shea, Kip Harris,
Phill Jenkins, Len Kasday, Marjolein Katsma, William Loughborough, Karen
Mardahl, Matt May, Charles McCathieNevile, Ann McMeekin, Matthias
Müller-Prove, Liddy Nevile, Graham Oliver, Wendy Porch, Bob Regan, Chris
Ridpath, Gregory Rosmaita, Dana Simberkoff, Reed Shaffner, Michael Squillace,
Heather Swayne, Gregg Vanderheiden, Carlos Velasco, and Jason White.
This document would not have been possible without the work of those who contributed to
ATAG 1.0.
This publication has been funded in part with Federal funds from the U.S.
Department of Education, National Institute on Disability and Rehabilitation
Research (NIDRR) under contract number ED-OSE-10-C-0067. The content of this
publication does not necessarily reflect the views or policies of the U.S.
Department of Education, nor does mention of trade names, commercial products,
or organizations imply endorsement by the U.S. Government.