[ Contents ] [ Techniques ]
Copyright © 2008 W3C ® ( MIT , ERCIM , Keio ), All Rights Reserved. W3C liability , trademark and document use rules apply.
Editing Styles :
This specification provides guidelines for designing Web content
authoring tools that are more accessible for people with
disabilities. An authoring tool that conforms to these guidelines
will promote accessibility by providing an accessible user
interface to authors with disabilities as well as by enabling, supporting, and promoting the
production of accessible Web content by all authors . authors.
The "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 document is the internal working draft used by the ATAG WG and is updated continuously and without notice. This document has no formal standing within W3C. Please consult the group's home page and the W3C technical reports index for information about the latest publications by this group.
The Authoring Tool Accessibility Guidelines Working Group (AUWG) intends to publish ATAG 2.0 as a W3C Recommendation. Until that time Authoring Tool Accessibility Guidelines 1.0 (ATAG 1.0) [ATAG10] is the stable, referenceable version. This Working Draft does not supersede ATAG 1.0.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This 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 .
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This 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 , except where noted.
This is a Editor's Draft of the Authoring Tool Accessibility
Guidelines (ATAG) version 2.0. This document includes
recommendations for assisting authoring tool
developers to make the authoring
tools that they develop more
accessible to people with disabilities, including blindness and low
vision, deafness and hearing loss, learning disabilities, cognitive
limitations, motor difficulties, speech difficulties, and others.
However, even authoring tools that conform to
ATAG 2.0 may not be able to address the needs of people with all
types, degrees and combinations of disabilities.
In order to achieve accessibility,
Accessibility, from
an authoring tools
must address tool perspective, includes addressing the needs of two
(potentially overlapping) user groups with disabilities: disabilities :
This section is normative .
ATAG 2.0 defines an "authoring tool" as any "any software
application, part of an application, or collection of applications
that authors interact with to create, modify
or assemble Web
content to be used by other people. people".
The individuals and
organizations that use ATAG 2.0 vary widely and include
authoring tool developers ,authoring tool users ( authors are just one
aspect ), authoring
tool purchasers, and policy makers.
In order to meet the varying needs of accessibility. For an overview this audience, several layers of the different components guidance are provided including two
parts ,overall principles ,general guidelines ,testable success
criteria and a collection of
accessibility sufficient techniques and how they work together see: advisory techniques with examples and resource links.
- Introduces
guidelines on making Web content accessible.
User Agent Accessibility Guidelines
(UAAG) Overview Parts -
Introduces guidelines on the design of
accessible browsers and other user agents. Organization of the ATAG
2.0 Document Two Parts ATAG 2.0 is divided into two parts,
each reflecting a key aspect of accessible authoring
tools . Part A includes principles and associated guidelines that are
related relates to ensuring
accessibility of the authoring tool user interface to authors with disabilities. Part B contains principles and guidelines related
relates to ensuring support by
authoring tools for the creation
of accessible Web content by any author (not just
those with disabilities) to end users with
disabilities. Part A: Make the
authoring tool user interface accessible The guidelines and success
criteria in Part A are organized around the following four
principles, adapted from the four principles in WCAG 2.0:
Authoring
tools must be perceivable Principles - Authors with a varying range of abilities must be able
to perceive the functions and components Each of the authoring tool
user interface. Authoring tools must be operable - Authors with a
varying range of abilities must be able to operate
two parts have principles that provide
the functions and components
high-level view of the what accessible
authoring tool
user interface. Authoring tools must be
understandable - Authors with a
varying entail.
range of abilities must be able to understand
the user interface functions and components that they can perceive
and operate. Part B: Support the
production of accessible content There are three principles in Part
B:
Production
of accessible content must be enabled Guidelines - The
creation of accessible content is dependent on Under the combined actions
of principles are guidelines. The
guidelines provide the basic goals
that authoring tool and the author . This guideline specifies the
responsibilities that rest exclusively with the tool. Authors must
be supported in the production of accessible content
developers -
Actions may be taken at the author's initiative that may
result should work toward in
accessibility problems . The
order to make authoring
tool should include features that provide
support and guidance tools
more accessible to authors in these situations, so that accessible authoring
practices can be followed and
accessible web Web content can be
produced. Accessibility solutions must be promoted and
integrated end users
- Authoring tools should facilitate awareness
and proper use of features that support accessible authoring
practices, with a goal of incorporating
accessibility into common practice. Note: While the requirements in
Part B do different disabilities. The
guidelines are not deal with the
accessibility of the authoring tool user interface per se , it
should be noted that any of testable,
but provide the features (e.g.,
checker, tutorial) added framework and
overall objectives to an
help authoring tool to meet developers
understand the Part B success criteria must
also meet and better implement
the user interface accessibility requirements
of Part A . techniques.
Success Criteria Under - For
each guideline there are guideline, testable success criteria that describe specifically what must be achieved in
order are provided to conform. Each success criterion is written as a
statement that will be either true or false when a specific
authoring tool is tested against it. While all of the
allow ATAG 2.0 success criteria are written to be testable used where
requirements and some test automation
may be possible, human conformance testing will
usually be required. are necessary such
as in design specification, purchasing, regulation, and contractual
agreements. In order to meet the needs of different groups
and different situations, three
multiple levels of full and partial conformance are defined: A (lowest), AA, and AAA (highest). Each
defined. See Levels of
the success criteria has a link to the
Techniques document that provides: "Sufficient" techniques for
meeting the success criteria, and @@define@@ Conformance .
Authoring tools may claim full conformance
to ATAG 2.0 at one of three "full" conformance levels. The level
achieved depends on the level of the success criteria that have
been satisfied. The full conformance levels are: Full ATAG 2.0 Conformance
at Level "A" Sufficient and Advisory
Techniques The authoring tool
satisfies all - For each of the
Level A success criteria. Full ATAG 2.0
Conformance at Level "Double-A" The authoring tool satisfies
all guidelines of the Level
A and Level AA success criteria. Full
ATAG 2.0 Conformance at Level "Triple-A" The authoring tool
satisfies all of the success
criteria. In addition, a "partial conformance" claim option is
available in cases where an authoring tool has satisfied all of
the success criteria at a specified
level in one of the two Parts
of the ATAG 2.0 document
(i.e., "Part A: Make the authoring tool user
interface accessible" and "Part B: Support itself, the production
working group has also documented a wide
variety of accessible content"). The
partial conformance levels are: Partial ATAG 2.0 Conformance Level
"A": Authoring Tool User Interface The authoring tool
satisfies all of the Level A
success criteria in Part A. Nothing is claimed about Part B.
Partial ATAG 2.0 Conformance Level "Double-A": Authoring Tool User
Interface techniques . The
authoring tool satisfies techniques are informative and fall into two categories:
those that are all
sufficient of for meeting the
Level A and Level AA success criteria
in Part A. Nothing is claimed about Part B.
Partial ATAG 2.0 Conformance Level "Triple-A": Authoring Tool User
Interface The authoring tool satisfies and those that are all
of advisory .The advisory techniques go beyond what is required
by the individual success
criteria in Part A. Nothing is claimed about
Part B. Partial ATAG 2.0 Conformance Level "A": Content Production"
The and allow authoring tool satisfies all of developers to better
address the Level A guidelines. Some advisory techniques address situations
that are not covered by the testable success criteria in Part B. Nothing is claimed about Part A.
Partial criteria. See Techniques for ATAG 2.0 Conformance Level "Double-A": Content Production" The
authoring tool satisfies all .
All of the Level A and Level AA these layers of guidance (parts, principles,
guidelines, success criteria in Part B.
Nothing is claimed about Part A. Partial ATAG 2.0 Conformance Level
"Triple-A": Content Production" The criteria, and sufficient and advisory techniques) work
together to provide guidance on how to make authoring tools more
accessible. Authoring tool satisfies developers are
encouraged to view and apply all of layers that they are able
to, including the success criteria in
Part B. Nothing is claimed about Part A. advisory techniques.
@@
Note: The Working Group remains
committed to the guiding principle that: " Everyone should have the
ability to create and access Web content ". Therefore, it is
recommended that partial conformance be claimed as a step towards
full conformance. Editor's
Note :Insert section on
meeting Success Criteria of different levels. @@
ATAG 2.0 is intended to be used in conjunction with WCAG 2.0
or [
WCAG20
] (or similar Web content accessibility guidance (e.g., WCAG 1.0, guidance, such as regulations that include based on
WCAG 2.0, etc.).
The relationship is as follows:
When implementing ATAG 2.0, it is recommended that authoring tool developers closely integrate features that support accessible authoring with the "look-and-feel" of other features of the authoring tool .This type of integration has the potential to:
The success criteria and applicability notes in this section are normative .
Rationale: In addition to
generally improving the accessibility of the authoring tool user interface,
implementing Web-based functionality (e.g., editing views
interface , documentation ) using accessible Web content
to implement Web-based functionality ( e.g., authoring tools that implemented as Web
applications) facilitates communication with assistive technologies via
user agents .
A.1.1.1 Web-Based Accessible (Level A): Web-based authoring tool user interfaces conform to WCAG 2.0 Level A. (Level A)
A.1.1.2 Web-Based Accessible (Level AA): Web-based authoring tool user interfaces conform to WCAG 2.0 Level AA. (Level AA)
A.1.1.3 Web-Based Accessible (Level AAA): Web-based authoring tool user interfaces conform to WCAG 2.0 Level AAA. (Level AAA)
This guideline also applies to any parts of authoring tools that are Web-based (e.g., help systems).
Rationale: Following When
authoring tools are not Web-based (i.e., they run directly on platforms such as Windows
and MacOS that are not user agents ), following
existing accessibility standards and/or platform
conventions will facilitate access by all authors , people,
including those using assistive technologies .
A.1.2.1 Non-Web-Based
Accessible (Level A): Non-Web-based
authoring tool user interfaces comply
with, and follow (and
cite in the conformance claim , ) the "Level A"
requirements of standards and/or platform
conventions that benefit accessibility. The "Level A" requirements
are those that are functionally equivalent to WCAG 2.0 Level A
success criteria. (Level A)
A.1.2.2 Non-Web-Based
Accessible (Level AA): Non-Web-based
authoring tool user interfaces comply with,
and follow (and
cite in the conformance claim, claim
) the "Level AA" requirements of
standards and/or platform conventions that benefit
accessibility. The "Level AA" requirements are those that are
functionally equivalent to WCAG
2.0 Level AA success criteria.
(Level AA)
A.1.2.3 Non-Web-Based
Accessible (Level AAA): Non-Web-based
authoring tool user interfaces comply with,
and follow (and
cite in the conformance claim, claim
) the "Level AAA" requirements of
standards and/or platform conventions that benefit
accessibility. The "Level AAA" requirements are those that are
functionally equivalent to WCAG
2.0 Level AAA success criteria.
(Level AAA)
This guideline also applies to any parts of authoring tools that are non-Web-based (e.g., client-side file uploaders).
Rationale: People who have
difficulty perceiving non-text objects content
are often able to access text alternatives of the same information
because there are a variety of ways to display text (e.g.,
magnification, enhancement, text-to-speech, Braille output) braille).
A.2.1.1 Recognized Alternative
equivalents in the content: Content : Editing views If an
editing
view that render includes renderings of
non-text content
(e.g., WYSIWYG) provide WYSIWYG
view), then authors with have access to
any equivalent alternatives alternative content for
the rendered non-text content that
are recognized by the
authoring tool . (Level A)
This guideline does not apply to editing
views ,such as plain
text editors as they editors, that do not render non-text content. content .
Rationale: Authors need to
have access to and control over
both the functional significance
of information signified by
presentation and also, in the context of authoring, the presentation
that will be experienced added by
the end user authoring
tool . This is especially important
for user interface components that do not implement an
accessibility platform architecture or leverage existing
implementations (e.g. custom user interface components built via
JavaScript and CSS). Some In addition,
since content rendering editing views support a workflow in which
authors require display
settings that differ from are
constantly able to observe the presentation end user that they
intend experience, authors
with disabilities also need access to
define for the published presentation content
(e.g., using a high contrast setting during editing content
that is not intended to will be high
contrast). experienced by
end users
.
A.2.2.1 Purpose of Added
Presentation: If the authoring tool an
editing
view modifies the presentation of
the Web content being edited
, to provide authors
with additional information (e.g.,
underlining misspelled words), then the
functional purpose for the modification that additional information is made
available via the platform
(e.g., if misspelled text is underlined, the
fact that it is misspelled is made available). . (Level
A)
A.2.2.2 Access to Text
Presentation (Minimum): If an
editing view (e.g., WYSIWYG) renders I f any of the following text presentation properties and those properties are editable
by any the
authoring
tool (even via a different
editing view
(e.g., instruction level ), then
if the properties
are property is rendered in an
editing
view (e.g., WYSIWYG
view) it
is made available via the
platform (Level A):
A.2.2.3 Access to Text
Presentation (Enhanced): Any
I f any text presentation
properties property (text size, text positioning, etc.) that
are can be modified by the
authoring
tool (even via a different
editing view ), then if
it is rendered in an editing
view (e.g., WYSIWYG) and are editable by
any editing view are WYSIWYG
view) it
is made available via the
platform. platform . (Level AAA)
Rationale : Some authors
will require need display settings that differ
from the presentation that they intend to define for the published
Web
content (e.g., an author uses large fonts
for themselves, while may zoom an editing content view
in order to modify text that
is not intended will appear small by default to have a large font in the final content). end
users ).
A.2.3.1 Independence of
Display: Editing views that usually
have their display characteristics set by Content rendering the
content being edited editing views (e.g., WYSIWYG) allows WYSIWYG )
allow the authors' visual display settings and audio display settings
to override these characteristics
take precedence in the editing
view without affecting the Web content being edited (e.g., markup, (i.e., no
effect on markup , style
sheets, etc.). (Level A)
Rationale: Providing alternate keyboard Keyboard accessibility provides access for to people with
limited mobility and people with
or visual disabilities, who cannot rely on hand-eye coordination for navigating the
user interface. are not able to use a mouse to
navigate .
A.3.1.1 Important
Command Functions: Commands: If the authoring
tool includes any of the following functions, features,
authors can enable key-plus-modifier-key
(or single-key) access to them (where allowed by the operating
environment) (Level A):
A.3.1.2
Importing
Avoiding Content Keyboard Trap: Traps:
The authoring tool prevents keyboard traps as
follows by both of the
following (Level A):
Web-based authoring tools may rely on the keyboard
navigation functions features of the user agent
listed in the conformance profile to
help satisfy some of these success
criteria.
Rationale: People who have difficulty typing, operating the mouse, or processing information can be prevented from using systems with short time limits.
A.3.2.1 Data Saved: If the authoring tool ends an authoring session due to a time limit (e.g., an authenticated session expires), then authors have the global option to ensure that the Web content being edited is saved. For Web-based authoring tools , this applies to any Web content that has already been submitted to the server by the user agent . (Level A)
A.3.2.2 Timing
Adjustable: The author is
If the authoring
tool includes time limits,
then authors are warned before time expires and given at least
20 seconds to extend the time limit with a simple action (e.g.
"press pressing the space
bar"). enter key to accept more
time). (Level A)
A.3.2.3 Moving
Targets: If the a user interface includes
any moving targets for authors' actions (e.g.,a selectable
component that accepts mouse input is
capable of an animation), then
movement (e.g., animated vector graphic),
provide authors can
with the option to stop
that the
movement. (Level A)
Rationale: Flashing can cause seizures in people with photosensitive epilepsy.
A.3.3.1 Static
View: If an editing view
renders
time-based content (e.g., WYSIWYG) then the author has animations), provide authors with the
global option of a static
view in which rendering only the
initial state of time-based content
appears in a fixed state. content. (Level A)
Rationale: People Author
s who have difficulty typing or
operating the mouse benefit when authoring
tools make use of the structure present in the Web content to simplify the tasks of navigation and editing. editing the
content
.
A.3.4.1 Edit by
Structure: If an editing
view displays a structured
element set , then authors can, with a
simple action, can select any
element in the structured element set and perform editing
functions (e.g., cut, copy, paste, presentation ) on that element, element
, its contents, and its sub-elements. (Level A)
A.3.4.2 Navigate By
Element Type: If an editing
view displays a structured
element set, set ,authors can move the editing focus
forward/backward to the next identical
element. instance of the same
element .
(Level AA)
A.3.4.3 Navigate By
Headings: If an editing
view displays a structured
element set, set ,authors can move the editing focus
forward/backward to the heading, regardless of level. heading before or the heading after the element .
(Level AA)
A.3.4.4 Navigate Tree
Structures: If an editing
view displays a structured
element set, set ,authors can, with
a simple action, can move the
editing focus from any element to the
following other elements in the structured element set with
any of the following relationships (if they exist) (Level
AA):
Rationale: People Authors
who have difficulty typing or operating the mouse benefit from the
ability to navigate to arbitrary points within editing views .
A.3.5.1 Text
Search: A function is provided that
allows Authors
can perform text search searches of
the content, Web content in
which meets all
of the following conditions
are true (Level AA):
Web-based authoring tools may rely on the "find" function of the user agent listed in the conformance profile to help perform searches.
Rationale: Providing the
ability to save and reload sets of keyboard and display preference
settings benefits people using multi-user
tools as well as people who have needs that differ over time
(e.g., due to fatigue).
A.3.6.1 Save Settings: Preference settings are stored for any of the following that the authoring tool controls (i.e., not controlled by the platform ) (Level AA):
A.3.6.2 Multiple Sets: Choosing between multiple sets of preferences (e.g., personal profiles, personal settings) are supported for any of the following that the authoring tool controls (i.e., not controlled by the platform) (Level AAA):
A.3.6.3 Options
Wizard: Assistance: Authors An interactive
mechanism helps authors are provided
with an accessibility option-setting "wizard" to configure
options related to Part A . (Level AAA)
Rationale: Preview
features are provided in many authoring
tools because the workflow of authors often
includes periodically checking how content user
agent will appear display the Web
content to end users in a user agent . Authors with
disabilities need to be able to follow the same workflow. workflow .
Note: Previews are
treated differently than editing views
because authors, authors , including those with disabilities,
will not be well-served if preview features diverge too much
from the actual functionality of available user agents. agents .
Therefore, preview features are exempted from
necessarily having to meet all of the other requirements in
Part A of
this guidelines document, , if they meet this
guideline.
A.3.7.1 Return
Mechanism: If a preview is provided, then it is
possible for authors to
return from the preview using
a simple action which is documented in the
help system. only keyboard
commands . (Level A)
A.3.7.2 Preview:
If a preview is provided, then it meets at least one of the following is true (Level A):
Rationale: People who have difficulty making fine movements may be prone to making unintended actions.
A.4.1.1 Undo Content
Changes: Authoring
actions are either reversible by
an "undo" function or include a warning to authors that the
action is
irreversible. irreversible . (Level A)
A.4.1.2 Undo Setting
Changes: Actions that modify authoring
tool settings are either reversible or include a warning to the author authors that the setting
modification action is
irreversible. irreversible . (Level A)
A.4.1.3 Redo:
Authors can immediately reverse the most recent
content "undo(s)" "undo" action(s) (i.e., a "redo" function). (Level
AA)
A.4.1.4 Multiple
Undos: Authors can reverse at least 5 consecutive
reversible
authoring
actions. actions . (Level AAA)
Rationale: While intuitive
user interface design is valuable to many authors , some
people may still not be able to
understand or be able to operate the authoring tool user interface without proper documentation .
A.4.2.1 Document
Accessibility Features: All features that are specifically
required to meet Part A of these guidelines (e.g.
keyboard shortcuts, text search, etc.) are documented. documented . (Level A)
A.4.2.2 Accessibility Feature Tutorials: Tutorials are provided for some of the features that are specifically required to meet Part A of these guidelines. (Level AAA)
The accessibility of the documentation is covered by Guideline A.1.1 and A.1.2 .
Rationale:
Choosing Web content technologies which support the
possibility of accessible authoring is the first step in ensuring that the
Web content produced is accessible. a critical first
step.
B.1.1.1 Tool Choice
of Technologies (Level A): Technologies: Any
Web content Only accessible
technologies that are ever automatically selected by the authoring tool can conform to WCAG Level A. . (Level A)
B.1.1.2 Author Choice
of Technologies (Level A): Technologies: If the authoring tool provides authors
with Web content
technology options, technology
options that can conform to
WCAG Level A are listed with at least as much prominence
as , then any other options and the tool guides the author towards the
most accessible technology for the task. (Level A) B.1.1.3 Tool Choice of
Technologies (Level AA): Any Web content technologies that is
automatically selected by the authoring tool can conform to WCAG
Level AA. (Level AA) B.1.1.4 Author Choice of Technologies (Level
AA): If the authoring tool provides authors with Web content
technology options, technology options that
can conform to WCAG Level AA are
listed with at least as much prominence as
any other options and the tool guides the author towards the most
accessible technology suitable
for the task. (Level AA) B.1.1.5 Tool Choice
of Technologies (Level AAA): Any Web content technologies that is
automatically selected by the authoring tool can conform to WCAG
Level AAA. (Level AAA) B.1.1.6 Author Choice of Technologies (Level
AAA): If the authoring tool provides authors with Web content
technology options, technology options that can conform to WCAG
Level AAA task are listed with at least as much prominence prominent as any other options and the tool guides the author towards the most
accessible technology
for the task. options . (Level AAA) A)
Rationale: Accessibility
information is critical to maintaining comparable levels of
accessibility across transformations and
conversions. conversions .
B.1.2.1 Target Preserves
Accessibility Information Information: : If the target
Web content technology of the output of a transformation or conversion can preserve *recognized* recognized accessibility
information that is required for that Web content to conform to WCAG 2.0 Level A,
then the accessibility
information is preserved and available for end users
in the resulting content. outputted Web content . (Level A)
B.1.2.x B.1.2.2 Target
Cannot Preserve Accessibility Information: If the
target Web content technology of the output of a the transformation or conversion cannot preserve *recognized* recognized accessibility
information that is required for that Web content to conform to WCAG 2.0 Level A,
then both of the authoring tool (Level A): following are true:
B.1.2.2 B.1.2.3
Accessibility Information Preservation (Enhanced): If the
authoring tool performs transformations or conversions during an authoring session,
session , then any accessibility
information in the pre-transformation/conversion pre- transformation /
conversion
content that is required for
the Web content to conform to WCAG 2.0 Level AA
or AAA is preserved and available for end users in the
resulting content. outputted Web content . (Level AA)
B.1.2.3 B.1.2.4
Notification Prior to Deletion: If the authoring tool automatically
deletes any author-generated
content for any reason, then at least one of the following is
true (Level AA):
Rationale: Authoring tools that automatically generate content that is not accessible
impose additional repair tasks on
authors. authors .
See Also: If accessibility information is required from authors during the automatic generation process, see Guideline B.2.1 . If templates or other pre-authored content are involved, see Guideline B.2.5 .
B.1.3.1 Automatic
Accessible (Level A): If the authoring
tool automatically generates content, content ,
then that Web
content meets WCAG 2.0 Level A prior to publishing .
B.1.3.2 Automatic
Accessible (Level AA): If the authoring
tool automatically generates content, content ,
then that Web
content meets WCAG 2.0 Level AA prior to publishing . (Level AA)
B.1.3.3 Automatic
Accessible (Level AAA): If the authoring
tool automatically generates content, content ,
then that Web
content meets WCAG 2.0 Level AAA prior to publishing . (Level AAA)
[JR: removed Applicabily note]
Rationale: By guiding
authors from the outset towards the
creation and maintenance of accessible content, Web
content ,Web content accessibility
problems are mitigated and less repair and retrofit effort is required.
See also: For more
information on how to prompt, prompt , see
ATAG 2.0 Techniques - Appendix A: Prompting for Different Types of
Accessibility Information. Repair features (see
Guidelin B.2.3)
B.2.3 )
are also an important aspect of author
guidance. guiding authors .
B.2.1.1 Guide Accessible (Level A): If the authoring tool automatically prompts authors for any information as Web content is being added or updated (e.g., by an image modification dialog), then automatic prompts are also included for any accessibility information required for that content to meet WCAG 2.0 Level A (Level A).
B.2.1.3 B.2.1.2 Guide
Accessible (Level AA): If the
authoring tool automatically prompts authors for
any information as Web
content is being added or updated (e.g., by an image
modification dialog), then automatic
prompts are also included for any accessibility
information required for that content to
meet WCAG 2.0 Level AA (Level AA).
B.2.1.5 B.2.1.3 Guide
Accessible (Level AAA): If the
authoring tool automatically prompts authors for
any information as Web
content is being added or updated (e.g., by an image
modification dialog), then automatic
prompts are also included for any accessibility
information required for that content to
meet WCAG 2.0 Level AAA (Level AAA).
Rationale: 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.
See also: For more information, see ATAG 2.0 Techniques - Appendix A: Levels of Checking Automation .
B.2.2.1 Check
Accessibility (Level A): At least one individual check is
associated with each WCAG 2.0 Level A Success Criterion that the
authoring
tool has the functionality to modify (e.g., a an HTML authoring
tool that inserts images should check for alt text; a
video authoring
tool that can with the ability to edit
captions text
tracks should check for them).
captions ). (Level A)
B.2.2.2
Availability: Checking is available
prior to publishing in a manner appropriate to the
workflow of the authoring
tool. tool . (Level A)
B.2.2.3 Help Authors
Locate: For any checks that require author judgment
to determine whether a potential Web content accessibility
problem is correctly identified (i.e., manual checking and semi-automated checking), checking ), the
relevant Web
content is identified (e.g., displaying the surrounding
text, "Is a sign language interpretation provided?")
content, displaying line numbers,
etc. ) (Level A)
B.2.2.4 Help Authors Decide: For any checks that require author judgment to determine whether a potential Web content accessibility problem is correctly identified (i.e., manual checking and semi-automated checking ), instructions are provided to help authors to decide. (Level A)
B.2.2.5 Check Accessibility (Level AA): At least one individual check is associated with each WCAG 2.0 Level AA Success Criterion that the authoring tool has the functionality to modify. (Level AA)
B.2.2.6 View
Status: If the authoring
tool records Web content accessibility
problems found during checking,
checking , then a list of
any accessibility problems is available to authors prior to the
end of
the authoring session. session . (Level
AA)
B.2.2.7 Save Status for
Repair: If repair assistance is
not provided during checking , authors have the option to save
the a list
of Web content accessibility
problems to facilitate interoperability between checking and repair.
repair . (Level AA)
B.2.2.8 Metadata for
Discovery: If the authoring
tool records accessibility status, then authors have the
option to associate this status with the
Web
content as metadata to facilitate resource discovery by
end users. users . (Level AA)
B.2.2.9 Check Accessibility (Level AAA): At least one individual check is associated with each WCAG 2.0 Level AAA Success Criterion that the authoring tool has the functionality to modify. (Level AAA)
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.
B.2.3.1 Repair Accessibility (Level A): For each WCAG 2.0 Level A Web content accessibility problem that is identifiable during checking (required in Guideline B.2.2 ), repair assistance is provided. (Level A)
B.2.3.2 Repair
Accessibility (AA): For each WCAG 2.0 Level AA
Web content accessibility
problem that is identifiable during checking, checking ,repair assistance is
provided. (Level AA)
B.2.3.3 Repair
Accessibility (AAA): For each WCAG 2.0 Level
AAA Web content accessibility
problem that is identifiable during checking, checking ,repair assistance is
provided. (Level AAA)
Rationale: Improperly
generated equivalent alternatives
alternative content can create accessibility
problems and interfere with accessibility checking.
@@http://lists.w3.org/Archives/Public/w3c-wai-au/2008JulSep/0083.html@@
checking .
B.2.4.1 Accept, Modify, Reject: Editable: Authors have the opportunity are able to accept, modify,
or reject any authoring tool-supplied equivalent modify alternative
, prior to insertion. content for
non-text
content .This includes types
of alternative content that
may not typically displayed on screen by user agents . (Level
A)
B.2.4.2 Edit Existing : Automated
suggestions: If
During the authoring session ,
the authoring tool is capable of adding equivalent alternatives
can automatically suggest alternative content for a type of non-text objects then authors content can edit the
equivalent alternatives. (Level A) B.2.4.3 Acceptable Sources:
Authoring tools only supply equivalent alternatives from
under the following sources conditions:
(Level AA): A)
(c)
Null when Appropriate: B.2.4.3 Let user
agents repair: null equivalent
alternatives After the end of an authoring
session ,the authoring
tool does not attempt to
repair alternative content for non-text objects content
using text content that are recognized by is equally
available to user
agents (e.g., the filename is not used). (Level A)
B.2.4.4 Special Values: The authoring tool as only used follows
recommendations on special values for pure decoration, or (d) Audio, Video, or CART Analysis:
automatic video or audio analysis alternative content (e.g., speech recognition). in
HTML4, alt="" denotes images that should be ignored by
assistive
technology ). (Level A)
B.2.4.4 Save for
Reuse: Authors can store, for future
reuse, both of have the
following author-assigned equivalent
alternatives (as applicable) (Level AAA): (a) Text
Alternatives: option
of having any recognized plain text
text alternatives alternative content that the
authoring tool stores directly they
enter (e.g., alternative
short text labels, long text descriptions), and (b) Other Alternatives:
referenced synchronized alternatives or accessible alternatives to
synchronized media that the authoring tool stores as URIs (e.g.,
captions descriptions) stored for
video, sign language interpretation
videos). future reuse. (Level
AA)
Note: Equivalent
alternatives should not be automatically generated
This guideline applies when non-text
content is specified by
authors from unreliable sources (e.g., file names should not be used as text
alternatives). an author inserts an image). When non-text
content is automatically added by
the authoring
tool ,Guideline B.1.3 applies.
Rationale: Templates and other pre-authored content (e.g., clip
art, synchronized media, widgets, etc.) that are not accessible
impose additional repair tasks on
authors. authors .
B.2.5.1 Templates "A" Accessible: If the authoring tool automatically selects templates or pre-authored content, then the selection meets WCAG 2.0 Level A when used. (Level A)
B.2.5.2 Provide Accessible
Templates: If the authoring
tool provides templates, templates , then there
are accessible template options for a range of
template uses. (Level A)
B.2.5.3 Template Selection Mechanism: If authors are provided with a template selection mechanism , then both of the following are true (Level A):
B.2.5.4 Templates "AA" Accessible: If the authoring tool automatically selects templates or pre-authored content, then the selection meets WCAG 2.0 Level AA when used. (Level AA)
B.2.5.5 New
Templates: If authors can use the
authoring tool to create new
templates for use by a template
selection mechanism, mechanism , they have the option to record
the accessibility status of the new templates. templates . (Level AA)
B.2.5.6 Templates in
Repository: If the authoring
tool provides a repository of templates, templates , then each of the templates has a recorded accessibility status. (Level
AA)
B.2.5.7 Pre-Authored Content Selection Mechanism: If authors are provided with a selection mechanism for pre-authored content other than templates (e.g., clip art gallery, widget repository, design themes), then both of the following are true (Level AA):
B.2.5.8 Pre-Authored Content in Repository: If the authoring tool provides a repository of pre-authored content, then each of the content objects has a recorded accessibility status. (Level AA)
B.2.5.9 Templates "AAA" Accessible: If the authoring tool automatically select templates or pre-authored content, then the selection meets WCAG 2.0 Level AAA when used. (Level AAA)
Templates may be complicated to check for accessibility due to their inherent incompleteness. The accessibility status of templates is instead measured by the accessibility of Web content (in the final Web content technology ) created through their proper use.
Rationale: Some When authors are most
likely learning a new authoring
tool ,they may find and learn
to use the first and easiest authoring action they encounter in the authoring tool user interface that achieves
their intended mainstream rendered outcome
. outcome. Since they may be unaware of
the issue of accessibility, it is preferable that accessible Web content be an additional unintended outcome, rather than
inaccessible content.
B.3.1.1 Accessible Options
Prominent (Level A) : If authors are provided with
multiple options for an authoring task, give equal or greater prominence to any options that will result in Web content conforming to *WCAG* WCAG 2.0 Level A.
A are at least
as prominent as options that will not.
B.3.1.1 Accessible Options
Prominent (Level AA) : If authors are provided with
multiple options for an authoring task, give equal or greater prominence to any options that will result in Web content conforming to *WCAG* WCAG 2.0 Level AA.
AA are at least
as prominent as options that will not.
B.3.1.1 Accessible Options
Prominent (Level AAA) : If authors are provided with
multiple options for an authoring task, give equal or greater prominence to any options that will result in Web content conforming to *WCAG* WCAG 2.0 Level AAA. AAA are at least
as prominent as options that will not.
Rationale: When accessibility
considerations are a natural part of the workflow, workflow , they become a routine part of
authoring.
B.3.2.1 Sequencing
Features: Function Features that sequences authoring actions for authors (e.g.,
wizards) "wizard"-type mechanisms) provide any
accessibility prompts relevant to the content
being edited at or before the first opportunity to successfully
complete the function. sequence. (Level AA)
B.3.2.2 Sequenced
Instructions: Instructions (e.g., tutorials ,
reference manuals, design guides) that consist of a sequence of
steps for authors to follow include the relevant
accessibility accessible authoring practices in the sequence
before the first opportunity to successfully complete the sequence.
(Level AA)
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. interface .
B.3.3.1 Active by
Default: All accessible content
support features are active
turned on by default. (Level A)
B.3.3.2 Reactivate
Option: If authors deactivate turn off an
accessible content
support feature, feature , then they can always reactivate turn on the
feature. (Level A)
B.3.3.3 Deactivation
Warning: If authors deactivate an
accessible content
support feature, feature , then the authoring
tool informs them that this may increase the risk of content accessibility
problems . (Level AA)
B.3.3.4 At Least as
Prominent: Accessible
content support features are at least as prominent
to authors as comparable features
related to other types of Web content problems (e.g., invalid
markup, markup , syntax errors, spelling and grammar
errors). (Level AA)
Rationale: Without documentation of the features that
support the production of accessible content (e.g., prompts for text
alternatives, accessibility checkers),
checking tools), some authors may not be able to find or
use them.
B.3.4.1 Instructions: Instructions for using the accessible content support features appear in the documentation . (Level A)
B.3.4.2 Accessible Authoring Tutorial: A tutorial on the accessible authoring process that is specific to the authoring tool is provided. (Level AAA)
Rationale: Demonstrating accessible authoring as routine practice will encourage its acceptance by some authors .
B.3.5.1 Model Accessible
Practice (Minimum): Any examples of authoring practices in the documentation (e.g., markup, markup , screen shots of WYSIWYG editing
views) demonstrate WCAG 2.0 Level A accessible authoring
practices . (Level AA)
B.3.5.2 Model "AA" Accessible Practice (Enhanced): Any examples of authoring practices in the documentation demonstrate WCAG 2.0 Level AA accessible authoring practices. (Level AAA)
An exception to these success criteria is allowed for examples that are specifically intended to demonstrate inaccessible practices to be avoided.
This section is normative .
Conformance means that the authoring
tool satisfies the success criteria
defined in the guidelines section. This
conformance section describes conformance, conformance and lists the conformance
requirements.
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).
As with WCAG 2.0 ,a number of conditions that must be met for a Success Criterion to be included in ATAG 2.0. These include:
The Success Criteria were assigned to one of the three levels of conformance by the working group after taking into consideration a wide range of interacting issues. Some of the common factors evaluated when setting the level in Part A included:
Some of the common factors evaluated when setting the level in Part B included:
Authoring tools may claim "full" or "partial" conformance to ATAG 2.0. In either case, a level is also claimed which depends on the level of the success criteria that have been satisfied.
"Full" ATAG 2.0 Conformance: This type of conformance claim 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 content produced by the authoring tools (Part B: Support the production of accessible content):"Partial" ATAG 2.0 Conformance: Authoring Tool User Interface: This type of conformance claim is intended to be used when developers have initially focussed on the accessibility of the authoring tool to authors (Part A: Make the authoring tool user interface accessible):
"Partial" ATAG 2.0 Conformance: Content Production: This type of conformance claim is intended to be used when developers have initially focussed on the accessibility of the Web content produced by the authoring tool to end users (Part B: Support the production of accessible content):
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 towards "Full" Conformance.
A conformance claim is an assertion by a claimant that an authoring tool has satisfied the requirements of a chosen ATAG 2.0 conformance profile .
Developers of authoring tools that do not yet conform fully to a particular ATAG 2.0 conformance level are encouraged to publish a statement on progress towards conformance. This statement would be the same as a conformance claim except that this statement would specify an ATAG 2.0 conformance level that is being progressed towards, rather than one already satisfied, and report the progress on success criteria not yet met. The author of a "Progress Towards Conformance" Statement is solely responsible for the accuracy of their statement. Developers are encouraged to provide expected timelines for meeting outstanding success criteria within the Statement.
Neither W3C, WAI, nor WAI-AUWG take any responsibility for any aspect or result of any ATAG 2.0 conformance claim that has not been published under the authority of the W3C, WAI, or WAI-AUWG.
This section is normative .
This appendix contains definitions for all of the significant/important/unfamiliar terms used in the normative parts of this specification, including terms used in the Conformance section. Except where indicated by "[ ]", the source of these definitions is the AUWG, developed with a goal of clarity, detail, understanding, and completeness. Every attempt has been made to find appropriate definitions for these terms from other sources before such development by the AUWG. All these terms are linked at least from their first usage in the specification. Terms that have designations of "[ ]" beside them are taken from the indicated W3C specifications. Where a definition so referenced is not suitable or adequate for the ATAG2.0, it may be modified as described herein. Please consult http://www.w3.org/TR/qaframe-spec/ for more information on the role of definitions in specification quality.
This section is informative .
There are two recommended ways to refer to the "Authoring Tool Accessibility Guidelines 2.0" (and to W3C documents in general):
In almost all cases, references (either by name or by link) should be to a specific version of the document. W3C will make every effort to make this document indefinitely available at its original address in its original form. The top of this document includes the relevant catalog metadata for specific references (including title, publication date, "this version" URI , editors' names, and copyright information).
An XHTML 1.0 paragraph including a reference to this specific document might be written:
<p>
<cite><a href="http://www.w3.org/TR/2008/WD-ATAG20-20090105/">
"Authoring Tool Accessibility Guidelines 2.0,"</a></cite>
J. Richards, J. Spellman, eds.,
W3C Recommendation, http://www.w3.org/TR/ATAG20/.
The <a href="http://www.w3.org/TR/ATAG20/">latest version</a> of this document is available at http://www.w3.org/TR/ATAG20/.</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 .
This section is informative .
For the latest version of any W3C specification please consult the list of W3C Technical Reports at http://www.w3.org/TR/. Some documents listed below may have been superseded since the publication of this document.
Note: In this document, bracketed labels such
as "[WCAG20]" link to the corresponding entries in this section.
These labels are also identified as references through markup. markup .
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, Charles McCathieNevile, Matt May, Matthias Müller-Prove, Liddy Nevile, Graham Oliver, Wendy Porch, Bob Regan, Chris Ridpath, Gregory Rosmaita, Michael Squillace, Heather Swayne, Gregg Vanderheiden, Carlos Velasco, and Jason White.
This document would not have been possible without the work of