W3C Public
Working Draft of ATAG 2.0
This is the W3C Last Call Working
Draft of 8 July 2010. 26 April 2011. This draft integrates changes made
as a result of comments received on the 29
October 2009 Public Working Draft. Publication as a
8 July 2010 Last Call Working
Draft indicates that the Draft. The Authoring Tool Accessibility Guidelines
Working Group (AUWG) believes it has
addressed all substantive issues and that the
document is stable. The first public Working Draft of
refined ATAG 2.0 was published 14 March 2003. Since then,
with the AUWG has
published nine Working Drafts and one previous Last Call Working
Draft, addressed hundreds contributions
of public commenters. A summary of issues and developed implementation support information
for the guidelines. See How WAI Develops Accessibility Guidelines
through the W3C Process for more
background on document maturity levels.
Substantial substantive changes
from the 29 October 2009 draft include:
follows:
The ATAG Working Group (AUWG) has
approved a number of requests for changes to improve
A more specific requirement that the
clarity editing
view of the document. authoring tool also render the alternatives to
time-based media ( A.2.1.2 Alternatives for Rendered Time-Based
Media );
The conformance section now specifically
waives "accessibility-supported ways An
enhanced requirement to make rendered text properties available to
assistive technologies ( A.2.2.2 Access to Rendered Text Properties
);
- A new level-AAA requirement to allow
navigation by programmatic relationships as in a programming
iIntegrated development environment (IDE) ( A.3.4.2 Navigate by Programmatic
Relationships ); and
- A modified approach to automatic
generation of
using technologies" from
WCAG 2.0 for evaluating ATAG 2.0 conformance, because WCAG 2.0
accessibility support is typically not evaluated until the
web content ( B.1.1.1 ; B.1.1.2 ) and
content transformations ( B.1.2.1 ; B.1.2.2 ; and
B.1.2.3
) that is created. more nuanced and in
some cases enables accessibility checking to be
employed;
The success criteria "B.2.1.1 Decision
Support" has been changed to clarify the responsibilities of the
developer A re-organization of
all the authoring
tool as success criteria related
to which technologies require warnings,
checking and repair to link to
consolidate them under one guideline
("Authors must be supported in improving the conformance claim for more information.
accessibility of existing content");
and
The success criteria "B.2.2.1 Check
Accessibility (WCAG Level A)" has been changed Clarifications to make it
more flexible. The the definitions of
" authoring tool will now require " and
" authors " regarding
when a check for success criteria that
the author has the ability to violate, instead of being required to
test every success criteria. web
application should be treated as an authoring tool.
The Working Group seeks feedback on the following points for
this draft:
- Does
ATAG 2.0 address the
shortcomings definition of ATAG 1.0?
Since authoring tool developers will
need to use ATAG 2.0 in conjunction with WCAG 2.0, are the
documents sufficiently similar in style and approach to
clearly delineate which kinds of authoring
tools can potentially be effective? considered
conforming toATAG 2.0?
Do users with disabilities think that
their needs have been addressed with regard Is it clear where ATAG 2.0 applies to Section A? integrated or
stand-alone accessibility checkers?
Is Does ATAG
Part A address the conformance claim
process usable by developers needs of authoring tool
software? people with different types
of disabilities? We encourage people with disabilities to review
and provide feedback.
Comments on this working draft are due on or before
2 September 2010 24 May 2011 . Comments on the draft
should be sent to public-atag2-comments@w3.org
( Public
Archive ).
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 (ATAG) 1.0 [ATAG10] is the stable,
referenceable version. This Working Draft does not supersede ATAG
1.0.
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 the their 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.
Accessibility, from an authoring tool perspective, includes
addressing the needs of two (potentially
overlapping) 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., (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
including two parts , overall principles , general guidelines ,
testable success criteria and an Implementing ATAG 2.0
document. 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.
Each part
includes Both parts include
normative applicability notes "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:
Each of the
two parts includes 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 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.
All of these layers of guidance (parts,
principles, guidelines, success criteria, and the Implementing ATAG
2.0 document) work together to provide guidance on how to make
authoring tools more accessible. Authoring tool developers are
encouraged to review all of the layers.
Understanding 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). As with WCAG 2.0 , there are a
number of conditions that must be met for a success criterion to be
included in ATAG 2.0. These include: For Part A , all success
criteria must present authoring tool user interface-related
accessibility issues . In other words, the user interface issue
must cause a proportionately greater problem for authors with
disabilities than it causes authors without disabilities and must
be specific to authoring tool software, as opposed to software in
general. For Part
B , all success criteria must present accessible web content
production issues . In other words, the issue must be specific to
the production of accessible web content by authoring tools, as
opposed to the production of web content in general. All success
criteria must also be testable . This is important since otherwise
it would not be possible to determine whether an authoring tool met
or failed to meet the success criteria. The success criteria can be
tested by a combination of machine and human evaluation as long as
it is possible to determine whether a success criterion has been
satisfied with a high level of confidence. 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: whether the success criterion
is essential (in other words, if the success criterion is not met,
then even assistive technology cannot make the authoring tool user
interface accessible) whether it is possible to satisfy the success
criterion for all types of authoring tools that the success
criteria would apply to (e.g., text editors, WYSIWYG editors,
content management systems, etc.) whether the success criterion
would impose limits on the "look-and-feel" and/or function of
authoring tools (e.g., limits on the function, design, aesthetic or
freedom of expression of authoring tool developers ) whether there
are workarounds for authors with disabilities if the success
criterion is not met Some more
information, see
Understanding Levels of the common factors evaluated when setting the level in
Part B included: Conformance
.
whether the success criterion is essential
(in other words, if the success criterion is not met, then even
authors with a high degree of accessibility expertise would be
unlikely to produce accessible web content using an authoring tool)
whether it is possible to satisfy the success criterion for the
production of all web content technologies that the success
criteria would apply to. whether the success criterion requires
features that would reasonably be used by authors . whether the
success criterion would impose limits on the "look-and-feel" and/or
function of authoring tools (e.g., limits on the function, design,
aesthetic or freedom of expression of authoring tool developers
)
Integration of Accessibility
Features
When implementing ATAG 2.0, it is
recommended that authoring tool
developers closely should carefully integrate features that support
accessible authoring with into the same
"look-and-feel" of 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 "authoring
tool user interface: interface": The Part A success criteria
apply to all aspects of the authoring tool user interface that are under the control of concerned with producing the authoring tool developer "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
web
content accessibility problems: The authoring tool is responsible for
ensuring that editing views editing-views display the web content being edited
in a way that is accessible to authors with
disabilities (e.g., (e.g. ensuring that a
text alternative alternatives in the content can be
programmatically
determined ). However, where an authoring tool user
interface accessibility problem is caused directly by
a web content accessibility problem in
the content being edited (e.g.,
(e.g. if an image in the content lacks
a label), 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., (e.g. keyboard
navigation, find functions, display preferences, undo features,
etc.) to satisfy success criteria. If a conformance claim is made, the claim cites 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., (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
editing-views because all authors,
including those with disabilities, benefit when preview features
accurately reflect the actual
functionality of user agents.
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 (For the authoring tool user interface] interface)
Ensure that web-based functionality is accessible. [
Implementing A.1.1 ]
Rationale: When authoring
tools or (or parts of authoring tools
(e.g., an online help system) 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 Level A): (WCAG): Web-based
authoring tool user interfaces conform
to meet the WCAG 2.0 Level A. (Level
A) success criteria. [
Implementing A.1.1.1 ] A.1.1.2 Web-Based Accessible (WCAG Level AA): Web-based
authoring tool user interfaces conform to
The WCAG 2.0
Level AA. A
success criteria are met (Level AA) [
Implementing A.1.1.2 ] A.1.1.3 Web-Based Accessible (WCAG
A); or
The WCAG 2.0 Level AAA): Web-based authoring tool user interfaces conform
to A and Level AA success criteria are
met (Level AA); or
The WCAG 2.0 Level AAA. A, Level AA, and Level
AAA success criteria are met (Level AAA) [ Implementing A.1.1.3 ] AAA).
Guideline
A.1.2: [For (For the authoring tool user interface] interface)
Ensure that non-web-based functionality is accessible. [
Implementing A.1.2 ]
Rationale: When authoring
tools or (or parts of authoring tools tools) are
non-web-based
(e.g., a client-side file uploader for a
web-based content management system), , following
existing accessibility standards and/or
guidelines and implementing communication
with platform
conventions that support accessibility
will facilitate services facilitates access by all authors , including
those using assistive technologies
.
PRINCIPLE A.2: Editing views
Editing-views must be perceivable
Guideline
A.2.1: [For (For the authoring tool user interface] 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 (For the authoring tool user interface] Editing view interface) Editing-view presentation can be
programmatically determined. [
Implementing A.2.2 ]
Rationale: Some authors need access
to details about the editing view
editing-view presentation because this may be , via their assistive technology, when that presentation
is used to convey both status
information added by the authoring tool
(e.g., (e.g. underlining
misspelled words) and, within content
renderings , or provide
information about how the end
user will experience of the web content being
edited. edited .
A.2.2.1 Purpose of Added Presentation: Editing-View Status Information: If an
editing view
editing-view modifies the presentation of web content to provide additional information
to authors , convey status information, then that additional 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 ]
A.2.2.2 Access to Rendered Text Presentation
(Minimum): Properties:
If an editing view (e.g., WYSIWYG
a text property
view) is
both renders any of the following presentation properties for
text, then those properties can be programmatically determined :
(Level A) [ Implementing A.2.2.2 rendered ] (a) Text Font
; and (b) Text Style (e.g., italic, bold); and (c) Text Color ; editable and (d) Text Size .
A.2.2.3 Access to Text Presentation (Enhanced): If an editing view
(e.g., WYSIWYG view) renders any presentation properties for text,
then those properties the
property can be programmatically
determined . (Level AAA) [ Implementing A.2.2.3 ] Guideline A.2.3:
[For the authoring tool user interface] Ensure the independence of
authors' display preferences. [ Implementing A.2.3 ] Rationale:
Some authors need to set their own display settings in a way that
differs from the presentation that they want to define for
communicated by the published web content . A.2.3.1 Independence of Display:
Authors can set their own display settings for editing views
(including WYSIWYG views ) without affecting supported platform accessibility service ,then the web content to be
published property is programmatically determinable . (Level A)
[
Implementing A.2.3.1 A.2.2.2 ]
PRINCIPLE A.3: Editing views
Editing-views must be operable
Guideline
A.3.1: [For (For the authoring tool user interface] 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 full keyboard
access. 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
editing web content properties that encode
continuous 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: This The path exception relates to the nature of web content, underlying function, not the usual input technique. For example, setting if using handwriting
to enter text, the path of a freehand
curve is exempt, while setting input
technique (handwriting) requires path-dependent input, but
the endpoints of a straight line is
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 be interpreted as
discouraging discourage providing
mouse input or other input methods in addition to the keyboard interface. operation.
A.3.1.2 No
Content 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
the keyboard, a keyboard
interface , then focus can be moved away from that
component using standard only a keyboard navigation
commands (e.g., TAB key); 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 Editing-Views that
Render
Web
Content : If an editing
view editing-view renders
web content (e.g., (e.g. WYSIWYG view), then a documented keyboard command is
provided that will always restore
moves the editing-view keyboard focus
to a known location (e.g., (e.g. the menus).
start of the editing-view).
Guideline
A.3.2: [For (For the authoring tool user interface] 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
requiring a that
require fast reaction speed,
speeds, such as clicking on a moving
target.
A.3.2.1 Data Content Edits Saved (Minimum): If the
authoring tool includes authoring session time limits, then the
authoring tool saves all submitted
content 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., (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., (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.
Guideline
A.3.3: [For (For the authoring tool user interface] 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 Rendering render of
visual time-based content (e.g., animations) in editing views can be
turned off. paused and can be set to not play automatically.
(Level A) [
Implementing A.3.3.1 ]
Guideline
A.3.4: [For (For the authoring tool user interface] 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 (For the authoring tool user interface] 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 as follows: 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 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 editing-view to display the
results; and results. (b) Bi-Directional: 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. modes;
and (d) No Match:
Authors are informed when no results are
found.
Guideline
A.3.6: [For (For the authoring tool user interface] 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., (e.g. due to fatigue).
Guideline
A.3.7: [For (For the authoring tool user interface] 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 to be able to
follow the same workflow.
opportunity to check their work.
A.3.7.1 Return Mechanism: If a
preview is provided, then authors can return from the preview using
only keyboard commands. (Level A) [ Implementing A.3.7.1 ] A.3.7.2
Preview: Preview
(Minimum): If a preview is provided,
then at least one of the following is true: (Level A) [
Implementing A.3.7.2 A.3.7.1 ] (a) Third-Party Pre-existing User Agent: The preview
makes use of an existing third-party
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
Editing-views must be
understandable
Guideline
A.4.1: [For (For the authoring tool user interface] interface)
Help authors avoid and correct mistakes. [
Implementing A.4.1 ]
Rationale: Some authors who have difficulty making fine movements
with disabilities may be prone more susceptible
to input errors due to factors such as
difficulty making unintended
actions. fine movements and speech
recognition system errors.
A.4.1.1 Undo Content
Changes: Changes
Reversible (Minimum): For Authoring authoring
actions are either reversible by an "undo"
function or include a warning to authors that ,
one of the action
is irreversible . 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., (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
Note 2: (b) Warn and
Confirm: It The authoring tool includes a warning to authors that the action is acceptable for certain committing actions (e.g., "save",
"publish") irreversible and
requires authors to make all previous
authoring actions irreversible. confirm
the action before proceeding.
A.4.1.2 Undo Setting
Changes: Changes
Reversible: Actions that
If actions modify authoring tool settings settings, then one
of the following are either
reversible 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 include
(b) Warn and Confirm: The authoring tool includes a warning to authors that the action is irreversible
. (Level A) [ Implementing A.4.1.2
] and requires
authors to confirm the action or save the current settings before
proceeding.
Guideline
A.4.2: [For (For the authoring tool user interface] 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 .
A.4.2.1 Document Accessibility Features:
All features that are specifically
required must be present to meet
Part A of this
document ATAG 2.0 (e.g. keyboard
shortcuts, text search, etc.) are documented . (Level A) [
Implementing A.4.2.1 ]
Note: The accessibility of the documentation is covered
by Guideline
A.1.1 and Guideline A.1.2 .
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 .
-
Applicability
after the end of an authoring session: Developer control: For author-generated content , the requirements of
The Part B success criteria only apply during authoring sessions. For example, if the author
includes a third-party feed in their web content ,
to the authoring
tool as it is provided by the developer .This
does not required to provide checking
for web content accessibility problems 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.).
-
in that
feed Applicability after the end
of the an
authoring session . In contrast,
session: Authoring
tools are responsible for
automatically-generated the accessibility of web content , Part B
continues to apply that they
automatically
generate after the end
of the an
author's authoring session.
session (see Success Criterion B.1.1.1 ). For example, if the developer changes the site-wide templates of a content management system are updated, 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.,
(e.g. an authoring tool could make use
of a third-party software accessibility checking and repair 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
added that must be present to meet the success criteria
in Part B (e.g., (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., (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: Production of
Fully automatic processes must produce
accessible content must be enabled
Guideline
B.1.1: Support web content technologies that
enable the creation of Ensure
automatically specified content that is accessible. [
Implementing B.1.1 ]
Rationale: For the
purposes of this document, WCAG 2.0 If authoring
tools defines the accessible web
content automatically requirements. To support accessible web content
production, at minimum, it must be possible to produce
specify web content that conforms with WCAG 2.0 is
not accessible, then additional repair using the
authoring tool tasks are imposed
on authors .
B.1.1.1 Accessible
Content Production (WCAG Level A):
Auto-Generation After Authoring Sessions
(WCAG): Authors can use have the
authoring tool default
option to produce that, when web content
that conforms to WCAG 2.0 is automatically generated
Level A. (Level A) for publishing after
the end of an authoring
session ,it is accessible web content (WCAG) .
[
Implementing B.1.1.1 ]
Note: 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 .
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.1.1.2 Accessible
Content Production (WCAG Level AA):
Auto-Generation During Authoring Sessions
(WCAG): Authors can use have the
authoring tool default
option to produce that, when web content
that conforms to WCAG 2.0 is automatically generated
Level AA. (Level AA) 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) B.1.1.3 Accessible Content Production (WCAG Level
AAA): without author input;
or (b) Prompting:
Authors During
the automatic generation process, authors are prompted for any
required accessibility information (WCAG) can use ; 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 to produce web content that conforms prompts authors to perform
accessibility checking. The WCAG 2.0 Level
AAA. A success
criteria are met (Level AAA) [
Implementing B.1.1.3 ] 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 that the authoring tool
preserves accessibility information. 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 Preserve Accessibility
Information (Minimum): Restructuring
and Recoding Transformations (WCAG): Any accessibility information ( WCAG 2.0 Level A)
recognized in If the input to any web content transformation authoring
tool is preserved as accessibility
information in the output, if allowed by the web content
technology provides restructuring transformations or re-coding transformations ,then at least one of the output. (Level A) 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. B.1.2.2 End Product Cannot Preserve
Accessibility Information: (a)
Preserve: If the web content
technology of the output of a web content transformation cannot
preserve recognized accessibility Accessibility information (WCAG) ( WCAG 2.0 Level
A) (e.g., saving a structured graphic to a raster image format),
then at least one of is preserved
in the following are true: (Level A) [
Implementing B.1.2.2 ] output;
or (a) Option to Save:
(b) Warning: author s Authors have
the default option to save the be warned
that accessibility information in
another way (e.g., as may be lost (e.g.
when saving a "comment", as
vector graphic into a backup copy of raster image
format); or (c) Automatic
Checking: After the
input); transformation, accessibility checking is automatically
performed; or (b) Warning: (d) Checking Suggested: After the transformation, the authoring tool
prompts authors are warned that this
will result in web content to
perform accessibility problems in the
output. 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).
(b) Notification
Option: Authors have the option to receive notification
before deletion; or (c) No Deletion Option: PRINCIPLE B.2: Authors have
the option to prevent automatic deletion by the authoring
tool. must be supported in producing
accessible content
Guideline
B.1.3: B.2.1: Ensure that
automatically generated accessible content production is accessible. possible.
[
Implementing B.1.3 B.2.1 ]
Rationale: Authoring
tools that automatically generate content that is not accessible
impose additional repair tasks on 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 Accessible
Auto-Generated Content (WCAG Level A): If Rationale: For the
authoring tool automatically generates
content , then that web content conforms to purposes of this document, WCAG 2.0 Level A prior
to publishing . (Level A) [ Implementing B.1.3.1 ] Note: This
success criterion only applies to the automated behavior specified
by defines the authoring tool developer . It does not apply when
actions of authors prevent generation of accessible web content
(WCAG) (e.g.,
authors might set less strict preferences, ignore prompts for
accessibility information , provide faulty accessibility
information, write their own automated scripts, etc.). B.1.3.2
Accessible Auto-Generated Content (Level AA): If the authoring tool
automatically generates requirements.
To support accessible web content ,
then that production, at minimum, it
must be possible to produce web content
that conforms to with WCAG 2.0 Level AA prior
to publishing . (Level AA) [ Implementing B.1.3.2 ] Note: This
success criterion only applies to the automated behavior specified
by using the authoring tool developer . It does not
apply when actions of the authors prevent generation of accessible
web content (e.g., authors might set less strict preferences,
ignore prompts for accessibility information , provide faulty
accessibility information, write their own automated scripts,
etc.).
B.1.3.3 B.2.1.1 Accessible Auto-Generated Content (Level AAA): Possible
(WCAG): If the authoring
tool automatically generates content ,
then that places restrictions on
the web content conforms to that
authors can specify, then those restrictions do not
prevent WCAG
2.0 Level AAA prior to publishing .
(Level AAA) success criteria
from being met: [
Implementing B.1.3.3 B.2.1.1 ] Note: This The WCAG 2.0 Level A success criterion only applies to the automated behavior
specified by the authoring tool developer . It does not apply when
actions of the authors prevent generation of accessible web content
(e.g., authors might set less strict preferences, ignore prompts
for accessibility information , provide faulty accessibility
information, write their own automated scripts, etc.).
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).
PRINCIPLE B.2: Authors must be supported in
the production of accessible content
Guideline
B.2.1: B.2.2: Guide authors to create produce
accessible content. [
Implementing B.2.1 B.2.2 ]
Rationale: By guiding authors from the
outset towards 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.1.1 Decision
Support: B.2.2.1 Accessible Option
Prominence (WCAG): If the
authoring tool provides the option of producing a web content
technology for publishing for which the authoring tool does not
provide support for the production of accessible content , then
both of the following are true: (Level A) [ Implementing B.2.1.1 ]
(a) Warning: Authors authors are warned that
the authoring tool does not provide support for the production of
accessible content for that technology; and (b) List: From the
warning, authors can access provided
with a list choice of technologies for
which the authoring tool does provide support for the production of
accessible content . B.2.1.2 Set Accessible Properties: Mechanisms
that set web content properties (e.g., attribute values, etc.) also
can be used to set the accessibility-related properties. (Level A)
[ Implementing B.2.1.2 ] actions B.2.1.3 Other
Technologies: If for achieving
the same authoring tool
outcome can
insert (e.g. styling text), then
options that will result in accessible web content (WCAG) that it cannot
subsequently edit, then authors can associate accessibility
information are at least
as prominent with as options that web
content. will not. (Level A)
[
Implementing B.2.1.3 B.2.2.1 ] Guideline B.2.2: Assist authors in checking for
accessibility problems. [ Implementing B.2.2 ] 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.2.2.1 Check Accessibility (WCAG The WCAG 2.0 Level
A): If the authoring tool provides authors
with the ability to add A success
criteria are met (Level A); or modify
web content so that any
The WCAG 2.0 Level A Success Criterion can be violated, then accessibility
checking for those and Level AA
success criteria is provided (e.g., an HTML
authoring tool that inserts images should check for alternative
text; a video authoring tool with the ability to edit text tracks
should check for captions ). are
met (Level A) [ Implementing B.2.2.1 ]
Note: Automated AA); or
The WCAG 2.0 Level A, Level AA, and
semi-automated checking is possible (and
encouraged) for many types of web content accessibility problems .
However, manual checking is the minimum requirement to meet
this Level AAA success
criterion. In manual checking, the authoring
tool provides authors with instructions for detecting problems,
which authors must carry out by themselves. For more information on
checking, see Implementing ATAG 2.0 - Appendix B: Levels of
Checking Automation . criteria are met
(Level AAA).
B.2.2.2 Availability:
Setting Accessibility Properties
(WCAG): Checking is available
prior to publishing in a manner appropriate to the workflow
of If the authoring tool
. (Level A) [ Implementing B.2.2.2 ] B.2.2.3
Help Authors Decide: For any checks that require author
judgment provides mechanisms to
determine whether a potential
set web content accessibility problem is correctly identified (i.e.,
manual checking and semi-automated checking properties ),
instructions (e.g. attribute values,
etc.), then mechanisms are also
provided to help authors decide whether it is
correctly identified. (Level A) [ Implementing B.2.2.3 ] B.2.2.4
Help Authors Locate: For any checks that require author judgment to
determine whether a potential set
web content properties related to
accessibility problem is correctly identified (i.e., manual checking
and semi-automated checking ), the relevant content is identified
(e.g., highlighting the affected content, displaying line numbers,
etc.) (Level A) information
(WCAG) : [
Implementing B.2.2.4 B.2.2.2 ]
Note: Success Criterion
B.4.1.4 B.2.2.5 Check Accessibility
(WCAG Level AA): If addresses the
authoring tool provides authors with
prominence of the ability to add or modify web content so that any
mechanisms. The WCAG 2.0 Level
AA Success Criterion can be violated, then
accessibility checking for those A success criteria is
provided. are met (Level
AA) [ Implementing B.2.2.5 ] Note:
Automated A); or
The WCAG 2.0 Level A and semi-automated checking is possible (and encouraged) for
many types of web content accessibility problems . However, manual
checking is the minimum requirement to meet this Level AA success criterion.
In manual checking, the authoring tool provides authors with
instructions for detecting problems, which authors must carry out
by themselves. For more information on checking, see Implementing
ATAG 2.0 - Appendix B: Levels of Checking Automation . B.2.2.6
Status Report: Authors can receive an accessibility status report
based on the results of the accessibility checks .
criteria are met (Level AA) [ Implementing B.2.2.6 ] Note: The format of the
accessibility status is not specified. For example, the status
might be a listing of problems detected AA); or a
The WCAG 2.0 conformance level, etc. B.2.2.7 Metadata Production:
Authors have the option of associating accessibility checking
results with the web content as metadata. Level A, Level AA, and Level AAA success criteria are
met (Level AA) [ Implementing B.2.2.7 ]
Note: The metadata format that is implemented will dictate the
nature of the associated results (e.g., specific check results,
summary conformance claims, etc.) AAA).
B.2.2.8 Check Accessibility (WCAG Level
AAA): B.2.2.3 Technology Decision
Support: If the authoring
tool provides authors with the
ability to add or modify web content so that
any WCAG 2.0 Level AAA Success Criterion can be violated, then
accessibility checking for those success criteria is provided.
(Level AAA) [ Implementing B.2.2.8 ] Note: Automated and
semi-automated checking option is possible (and
encouraged) for many types of producing
a web content
accessibility problems . However, manual
checking technology
is the minimum requirement to meet this
success criterion. In manual checking, the authoring tool provides
authors for publishing with instructions for detecting problems, which authors must carry out by themselves. For more
information on checking, see Implementing ATAG 2.0 - Appendix B:
Levels of Checking Automation . Guideline B.2.3: Assist authors in
repairing accessibility problems. [ Implementing B.2.3 ] Rationale:
Repair as an integral part of the authoring process greatly enhances tool does not provide support
for the utility production of checking and
increases the likelihood that accessibility problems will be
properly addressed. B.2.3.1 Repair Accessibility (WCAG Level A):
For each WCAG 2.0 Level A web accessible content accessibility problem that is identifiable during
checking (as required by Guideline B.2.2 ), repair assistance is
provided. , then both of the
following are true: (Level A) [
Implementing B.2.3.1 B.2.2.3 ]
Note: (a)
Warning: Automated
and semi-automated repair is possible (and
encouraged) for many types of web content accessibility problems.
However, manual repair Authors
is the minimum requirement to meet this
success criterion. In manual repair, are warned that the authoring tool provides authors with instructions does not provide support for repairing problems, which authors must carry out by
themselves. For more information on repair, see Implementing ATAG
2.0 - Appendix C: Levels the
production of Repair Automation .
B.2.3.2 Repair Accessibility (WCAG Level AA): For each WCAG 2.0
Level AA web accessible content
accessibility problem for that is identifiable
during checking (as required by Success Criterion B.2.2.5 ), repair
assistance is provided. (Level AA) [ Implementing B.2.3.2 ]
technology; and
Note: (b)
List: Automated and
semi-automated repair is possible (and encouraged) for many types
of web content accessibility problems. However, manual repair is
the minimum requirement to meet this success criterion. In manual
repair, From the authoring tool provides authors with instructions for
repairing problems, which warning, authors must carry
out by themselves. For more information on repair, see Implementing
ATAG 2.0 - Appendix C: Levels can
access a list of Repair Automation .
B.2.3.3 Repair Accessibility (WCAG Level AAA): For each WCAG 2.0
Level AAA web content accessibility problem that is identifiable
during checking (as required by Success Criterion B.2.2.8 ), repair
assistance is provided. (Level AAA) [ Implementing B.2.3.3 ] Note:
Automated and semi-automated repair is possible (and
encouraged) technologies for
many types of web content accessibility
problems. However, manual repair is the minimum requirement to meet
this success criterion. In manual repair, which the authoring tool provides authors with instructions does provide support for repairing problems, which authors must carry out by
themselves. For more information on repair, see Implementing ATAG
2.0 - Appendix C: Levels the
production of Repair Automation
accessible content .
Guideline
B.2.4: B.2.3: Assist authors with managing alternative
content for non-text content. [
Implementing B.2.4 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.,
(e.g. inserts an image). When non-text
content is automatically added by the authoring tool , see Guideline B.1.3 B.1.1 .
Guideline
B.2.5: B.2.4: Assist authors with accessible templates and other pre-authored content.
templates. [
Implementing B.2.5 B.2.4 ]
Rationale: Providing accessible templates and other pre-authored
content (e.g., (e.g. clip art, synchronized media, widgets, etc.)
can have several benefits, including: immediately improving the
accessibility of
web content being
edited, edited , reducing the effort required
of authors , and demonstrating the importance
of accessible web content. content
(WCAG) .
B.2.5.1 Templates
Accessible (WCAG Level A): If the authoring tool automatically
selects templates or pre-authored content, then the selections
conform to WCAG 2.0 Level A when used. (Level A) [ Implementing
B.2.5.1 ] Note: Templates may not pass accessibility checks due to
their inherent incompleteness. The accessibility status of a
template should instead be measured by the accessibility of
completed web content (in the final web content technology )
created when the template is used properly.
B.2.5.2 Provide B.2.4.1 Accessible Templates: Template Options
(WCAG): If the authoring
tool provides templates , then there
are accessible
template options for a range of template uses. (Level A)
[
Implementing B.2.5.2 B.2.4.1 ]
B.2.5.3
Templates Accessible (WCAG Level AA): If the authoring tool
automatically selects templates or pre-authored content, then the
selections conform to WCAG 2.0 Level AA when used. (Level AA) [
Implementing B.2.5.3 ] Note: Templates may not pass accessibility
checks due to their inherent incompleteness. The accessibility
status of a template should instead be measured by the
accessibility of completed web content (in the final web content
technology ) created when the template is used properly.
B.2.5.4 B.2.4.2
Template Selection Mechanism: If authors are provided
with a template
selection mechanism , then both of the following are true:
(Level AA) [
Implementing B.2.5.4 B.2.4.2 ] (a) Indicate: The
selection mechanism indicates the accessibility status of templates (if known); and (b) Prominence: Any
accessible
template options are at least as prominent as
other template options.
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.,
(e.g. clip art gallery, widget
repository, design themes), then both of the following are true:
(Level AA) [
Implementing B.2.5.6 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.7 Templates in
Repository: B.2.5.2 Pre-Authored
Content Accessibility Status: If the authoring tool provides a
repository of templates , pre-authored content, then each of the templates content
objects has a recorded accessibility status. (Level AAA)
[
Implementing B.2.5.7 B.2.5.2 ]
B.2.5.8 Pre-Authored Content
PRINCIPLE B.3: Authors must be
supported in Repository: If
improving the authoring tool provides a repository of pre-authored
content, then each accessibility
of the existing content objects has
a recorded
Guideline B.3.1: Assist authors in checking for
accessibility status. (Level AAA)
problems. [
Implementing B.2.5.8 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.2.5.9 Templates Accessible
(WCAG Level AAA): B.3.1.1 Checking
Assistance (WCAG): If the authoring
tool automatically selects
templates provides authors
or pre-authored content, then
with the selections conform ability to add or
modify web
content so that a WCAG 2.0 Level AAA when
used. (Level AAA) success criterion can
be violated, then accessibility checking for that
success criterion is provided (e.g. an HTML authoring tool that
inserts images should check for alternative text; a video authoring tool
with the ability to edit text tracks should check for
captions). [
Implementing B.2.5.9 B.3.1.1 ]
Note: Templates may not pass
accessibility checks Automated due to their
inherent incompleteness. The accessibility status of a template
should instead be measured by the accessibility and semi-automated checking is possible (and encouraged) for many types of
completed web
content accessibility problems
.However, manual checking
(in is the
final web content technology ) created
when minimum requirement to meet this
success criterion. In manual checking, the template is used properly. authoring tool provides authors with
instructions for detecting problems, which authors must carry out
by themselves. For more information on checking, see
Implementing ATAG 2.0 - Appendix B: Levels of
Checking Automation .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.3: Accessibility
solutions must be promoted and integrated B.3.1.2 Help Authors Decide: For checks Guideline B.3.1:
Ensure that accessible authoring
actions require authors to decide
whether a potential web content accessibility
problem is correctly identified
(i.e. manual checking and semi-automated checking ), instructions are given
prominence. provided from the check
that describe how to make the decision. (Level A)
[
Implementing B.3.1 B.3.1.2 ] Rationale: When
B.3.1.3 Help Authors
Locate: For checks that require authors are
learning to decide whether a
new authoring tool , they may find
potential web content accessibility
problem is correctly identified
(i.e. manual checking and learn semi-automated checking
), the relevant content is
identified to use the first authoring action authors. (Level A) [
Implementing B.3.1.3 they encounter that achieves their intended outcome.
Since they may be unaware ]
Note: Depending on the nature of the issue editing-view and the
scope of accessibility, it is
preferable that accessible the
potential web content be an additional
unintended outcome, rather than inaccessible content.
accessibility problem, identification might
involve highlighting elements or renderings of elements, displaying
line numbers, or providing instructions.
B.3.1.1 Accessible Options
Prominent (WCAG Level A) : If B.3.1.4
Status Report: authors Authors
are provided with a choice can receive an accessibility status report based on the
results of authoring actions for
achieving the same authoring outcome
(e.g., styling text), then options that will result in web content
conforming to WCAG 2.0 Level A are at least as prominent as options
that will not. accessibility
checks . (Level
A) AA)
[
Implementing B.3.1.1 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.2 Accessible Options
Prominent (WCAG Level AA) : If B.3.1.5 Metadata
Production: authors
are provided with a choice of authoring actions Authors for
achieving have the same authoring outcome (e.g., styling text), then
options option that will result
in of associating accessibility
checking results with the web content
conforming to WCAG 2.0 Level AA are at
least as prominent as options that will
not. metadata. (Level AA)
[
Implementing B.3.1.2 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.)
B.3.1.3 Accessible Options Prominent (WCAG Level AAA) :
If Guideline B.3.2: Assist
authors in repairing accessibility
problems. [
Implementing B.2.3 are provided with a choice of authoring actions
]
Rationale:
Repair for achieving as an integral
part of the same authoring
outcome (e.g., styling text), then
options process greatly enhances the
utility of checking and increases
the likelihood that accessibility problems will result in web content be
properly addressed.
PRINCIPLE B.4: Authoring tools must promote
and integrate their accessibility features
Guideline
B.3.2: B.4.1: Ensure that features
of the authoring tool supporting
availability of features that support
the production of accessible content are
available. content. [
Implementing B.3.2 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.3.3: B.4.2: Ensure that features
of the authoring tool supporting documentation promotes the production of
accessible content are documented.
content. [
Implementing B.3.3 B.4.2 ]
Rationale: Without documentation of the features that
support the production of accessible content (e.g., (e.g. prompts for text alternatives, accessibility checking tools), some authors may not be
able to use them. B.3.3.1 Instructions:
Instructions for using the accessible content support features
appear in the documentation . (Level A) [ Implementing B.3.3.1 ]
B.3.3.2 Accessible Authoring Tutorial: A tutorial on an accessible
authoring process that is specific to the authoring tool is
provided. (Level AAA) [ Implementing B.3.3.2 ] Guideline B.3.4:
Ensure that any authoring practices demonstrated in documentation
are accessible. [ Implementing B.3.4 ] Rationale:
Demonstrating accessible authoring as routine practice will
encourage its acceptance by some authors .
B.3.4.2 Model Accessible
Practice (WCAG Level AA): B.4.2.3
Tutorial: A range of examples
in the documentation (e.g., markup , screen shots of WYSIWYG
editing views ) demonstrate WCAG 2.0 tutorial Level AA
on an accessible authoring practices . process that is
specific to the authoring
tool is provided. (Level
AA) AAA)
[
Implementing B.3.4.2 B.4.2.3 ]
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
conformance 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 towards toward producing accessible 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] 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." supported ." In broad terms, WCAG 2.0
considers a web content
technology to be accessibility
supported "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., (e.g. private
intranets versus public websites, monolingual sites versus
multilingual sites, etc.). Therefore:
For the purposes of ATAG 2.0
conformance, does
not include the accessibility-supported requirement is waived. requirement. As a result, ATAG 2.0 success criteria do
not refer to WCAG 2.0 "conformance", but instead refer to "meeting
WCAG 2.0 success criteria".
Once an authoring tool has been installed and put into use, it
is 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
towards 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., (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): 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., (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
may be anyone (e.g., authoring
tool developers , journalists, other third parties).
Claimants are solely responsible for the accuracy of their
claims (including claims that include
products for which they are not responsible) and keeping
claims up to date.Claimants are encouraged to
claim conformance to the most recent version of the Authoring Tool
Accessibility Guidelines Recommendation.
Required Components of an ATAG 2.0
Conformance Claim
- Claimant name and affiliation
.
- Date of the claim.
- Guidelines title , version
and URI
- Conformance level
satisfied.
- Authoring tool information: The name of the
authoring tool and sufficient
additional information to specify the version
(e.g., (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., (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., (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 editing-views that it includes.
- A description of how the ATAG 2.0 success criteria were
met where this may not be obvious.
"Progress Towards 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 towards 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 towards, toward, rather than one already satisfied, and
report the progress on success criteria not yet met. The author of
a "Progress Towards 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
D : 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)
Ann McMeekin Alastair Campbell (Nomensa)
- Cherie Ekholm (Microsoft)
- Alex Li (Microsoft)
- Alessandro Miele (Invited
Expert)
- Sueann Nichols (IBM)
- Greg Pisocky (Adobe)
- Sarah Pulis (Media Access
Australia)
- Jan Richards
(Adaptive Technology
Resource Centre, University of Toronto) (Inclusive Design Institute, OCAD University)
- Andrew Ronksley (Royal National Institute for the Blind)
- Roberto Scano (IWA/HWG)
- Jeanne Spellman (W3C)
- Jutta Treviranus (WG Chair;
Adaptive
Technology Resource Centre, University of Toronto)
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 Loughbor 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.