Post on 04-Apr-2018
7/29/2019 Essential Components of Web Accessibility
1/113
Essential Components of Web Accessibility
Introduction
How the Components Relate
Interdependencies Between Components
Guidelines for Different Components
This document shows how Web accessibility depends on several components
working together and how improvements in specific components could substantially
improve Web accessibility. It also shows how the WAI guidelines address these
components.
Introduction
It is essential that several different components of Web development andinteraction work together in order for the Web to be accessible to people with
disabilities. These components include:
content - the information in a Web page or Web application, including:
natural information such as text, images, and sounds
code or markup that defines structure, presentation, etc.
Web browsers, media players, and other "user agents"
assistive technology, in some cases - screen readers, alternative keyboards,switches, scanning software, etc.
users' knowledge, experiences, and in some cases, adaptive strategies using the
Web
developers - designers, coders, authors, etc., including developers with disabilities
and users who contribute content
authoring tools - software that creates Web sites
evaluation tools - Web accessibility evaluation tools, HTML validators, CSSvalidators, etc.
How the Components Relate
7/29/2019 Essential Components of Web Accessibility
2/113
Web developers usually use authoring tools and evaluation tools to create Web
content.
People ("users") use Web browsers, media players, assistive technologies, or other
"user agents" to get and interact with the content.
Interdependencies Between Components
There are significant interdependencies between the components; that is, the
components must work together in order for the Web to be accessible. Forexample, for alternative text on images:
Technical specifications address alternative text (for example, HTML defines the
alternative text attribute (alt) of the image element (img))
WAI guidelines - WCAG, ATAG, and UAAG, described below - define how to
implement alternative text for accessibility in the different components
Developers provide the appropriate alternative text wording
Authoring tools enable, facilitate, and promote providing alternative text in a Webpage
Evaluation tools are used to help check that alternative text exists
User agents provide human and machine interface to the alternative text
Assistive technologies provide human interface to the alternative text in various
modalities
7/29/2019 Essential Components of Web Accessibility
3/113
Users know how to get the alternative text from their user agent and/or assistive
technology as needed
The Implementation Cycle
When accessibility features are effectively implemented in one component, the
other components are more likely to implement them.
When Web browsers, media players, assistive technologies, and other user agents
support an accessibility feature, users are more likely to demand it and developers
are more likely to implement it in their content.
When developers want to implement an accessibility feature in their content, theyare more likely to demand that their authoring tool make it easy to implement.
When authoring tools make a feature easy to implement, developers are more
likely to implement it in their content.
When an accessibility feature is implemented in most content, developers and users
are more likely to demand that user agents support it.
When One Component is Weak
If an accessibility feature is not implemented in one component, there is littlemotivation for the other components to implement it when it does not result in an
accessible user experience. For example, developers are unlikely to implement an
accessibility feature that authoring tools do not support and that most browsers or
assistive technologies do not implement consistently.
7/29/2019 Essential Components of Web Accessibility
4/113
If one component has poor accessibility support, sometimes other components can
compensate through "work-arounds" that require much more effort and are not
good for accessibility overall. For example,
developers can do more work to compensate for some lack of accessibility support
in authoring tools; for example, coding markup directly instead of through a tool
users can do more work to compensate for some lack of accessibility support in
browsers, media players, and assistive technology and lack of accessibility of
content; for example, using different browsers or assistive technologies to
overcome different accessibility issues
However, in most cases the works-arounds are not implemented and the result is
still poor accessibility. Additionally, sometimes poor accessibility support in one
component cannot be reasonably overcome by other components and the result is
inaccessibility, making it impossible for some people with disabilities to use a
particular Web site, page, or feature.
Guidelines for Different Components
The World Wide Web Consortium (W3C) Web Accessibility Initiative (WAI) develops
Web accessibility guidelines for the different components:
Authoring Tool Accessibility Guidelines (ATAG) addresses authoring tools
Web Content Accessibility Guidelines (WCAG) addresses Web content, and is used
by developers, authoring tools, and accessibility evaluation tools
7/29/2019 Essential Components of Web Accessibility
5/113
User Agent Accessibility Guidelines (UAAG) addresses Web browsers and media
players, including some aspects of assistive technologies
WAI guidelines are based on the fundamental technical specifications of the Web,
and are developed in coordination with:
W3C technical specifications (HTML, XML, CSS, SVG, SMIL, etc.)
Document Information
Version: 1.3 August 2005
Editor: Shawn Lawton Henry. Graphic artist: Michael Duffy. This information is
under development with the Education and Outreach Working Group (EOWG).
[Contacting WAI] Feedback welcome towai-eo-editors@w3.org
Copyright 1994-2010 W3C (MIT, ERCIM, Keio), All Rights Reserved. W3C
liability, trademark, document use and software licensing rules apply. Your
interactions with this site are in accordance with our public and Member privacy
statements.
Authoring Tool Accessibility Guidelines (ATAG) 2.0
W3C Working Draft 08 July 2010
mailto:wai-eo-editors@w3.orgmailto:wai-eo-editors@w3.orgmailto:wai-eo-editors@w3.orgmailto:wai-eo-editors@w3.org7/29/2019 Essential Components of Web Accessibility
6/113
This version:
http://www.w3.org/TR/2010/WD-ATAG20-20100708/
Latest version:
http://www.w3.org/TR/ATAG20/
Previous version:
http://www.w3.org/TR/2009/WD-ATAG20-20091029/
Editors:
Jan Richards, Adaptive Technology Resource Centre, University of Toronto
Jeanne Spellman, W3C
Jutta Treviranus, Adaptive Technology Resource Centre, University of Toronto
Previous Editors:
Matt May (until June 2005 while at W3C)
Copyright 2010 W3C (MIT, ERCIM, Keio), All Rights Reserved. W3C liability,
trademark and document use rules apply.
Abstract
This specification provides guidelines for designing web content authoring tools that
are both (1) more accessible to authors with disabilities and (2) designed to enable,
support, and promote the production of accessible web content by all 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).
Status of This Document
W3C Public Working Draft of ATAG 2.0
This is the W3C Last Call Working Draft of 8 July 2010. This draft integrates
changes made as a result of comments received on the 29 October 2009 PublicWorking Draft.
Publication as a Last Call Working Draft indicates that 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
ATAG 2.0 was published 14 March 2003. Since then, the AUWG has published nine
7/29/2019 Essential Components of Web Accessibility
7/113
Working Drafts and one previous Last Call Working Draft, addressed hundreds 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 changes from the 29 October 2009 draft include:
The ATAG Working Group (AUWG) has approved a number of requests for changes
to improve the clarity of the document.
The conformance section now specifically waives "accessibility-supported ways 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 content is
created.
The success criteria "B.2.1.1 Decision Support" has been changed to clarify the
responsibilities of the developer of the authoring tool as to which technologiesrequire warnings, and to link to the conformance claim for more information.
The success criteria "B.2.2.1 Check Accessibility (WCAG Level A)" has been
changed to make it more flexible. The authoring tool will now require a check for
success criteria that the author has the ability to violate, instead of being required
to test every success criteria.
The Working Group seeks feedback on the following points for this draft:
Does ATAG 2.0 address the shortcomings 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 be
effective?
Do users with disabilities think that their needs have been addressed with regard to
Section A?
Is the conformance claim process usable by developers of authoring tool software?
Comments on this working draft are due on or before 2 September 2010.
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.
7/29/2019 Essential Components of Web Accessibility
8/113
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.
Table of Contents
Abstract
Status of This Document
Introduction
ATAG 2.0 Layers of Guidance
Understanding Levels of Conformance
Integration of Accessibility Features
ATAG 2.0 Guidelines
PART A: Make the authoring tool user interface accessible
7/29/2019 Essential Components of Web Accessibility
9/113
Principle A.1: Authoring tool user interfaces must follow applicable accessibility
guidelines
Principle A.2: Editing views must be perceivable
Principle A.3: Editing views must be operable
Principle A.4: Editing views must be understandable
PART B: Support the production of accessible content
Principle B.1: Production of accessible content must be enabled
Principle B.2: Authors must be supported in the production of accessible content
Principle B.3: Accessibility solutions must be promoted and integrated
Conformance
Relationship to the Web Content Accessibility Guidelines (WCAG) 2.0
Levels of Conformance
Conformance Claims
"Progress Towards Conformance" Statement
Disclaimer
Appendix A: Glossary
Appendix B: How to refer to ATAG 2.0 from other documents
Appendix C: References
Appendix D: Acknowledgments
Appendix E: Checklist
Appendix F: Comparison of ATAG 1.0 guidelines to ATAG 2.0
Introduction
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 authoring tools that they develop more accessible to people
with disabilities, including blindness and low vision, deafness and hearing loss,
7/29/2019 Essential Components of Web Accessibility
10/113
learning disabilities, cognitive limitations, motor difficulties, speech difficulties, and
others.
Accessibility, from an authoring tool perspective, includes addressing the needs of
two (potentially overlapping) user groups with disabilities:
authors of web content, whose needs are met by ensuring that the authoring tool
user interface itself is accessible (addressed by Part A of the guidelines), and
end users of web content, whose needs are met by ensuring that all authors are
enabled, supported, and guided towards producing accessible web content
(addressed by Part B of the guidelines).
Notes:
The term "authoring tools" has a specific definition in ATAG 2.0. The definition,
which includes several normative notes, appears in the Glossary.
ATAG 2.0 recommends that authoring tools be capable of producing web content
that conforms with WCAG 2.0. However, WCAG 2.0 notes that even content that
conforms to the highest level of WCAG 2.0 (i.e., Level AAA) may not be "accessible
to individuals with all types, degrees, or combinations of disability, particularly in
the cognitive language and learning areas". Development of authoring tools that
address more specialized needs is encouraged, but is beyond the scope of this
document.
ATAG 2.0 does not include standard usability recommendations, except where they
have a significantly greater impact on people with disabilities than on other people.
Authoring tools are just one aspect of web accessibility. For an overview of the
different components of accessibility and how they work together see:
Essential Components of Web Accessibility
Web Content Accessibility Guidelines (WCAG) Overview
User Agent Accessibility Guidelines (UAAG) Overview
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.
7/29/2019 Essential Components of Web Accessibility
11/113
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
normative applicability notes that apply to all of the success criteria within that part
(see Part A Applicability Notes, Part B Applicability Notes).
Principles: Each of the two parts includes several high-level principles that organize
the guidelines.
Guidelines: Under the principles are guidelines. The guidelines provide the basic
goals that authoring tool developers should work toward in order to make authoring
tools more accessible to both authors and end users of web content with different
disabilities. The guidelines are not testable, but provide the framework and overall
objectives to help authoring tool developers understand the success criteria. Each
guideline includes a brief rationale for why the guideline was included.
Success Criteria: For each guideline, testable success criteria are provided to allow
ATAG 2.0 to be used where requirements and conformance testing are necessary
such as in design specification, purchasing, regulation, and contractual agreements.
In order to meet the needs of different groups and different situations, multiple
levels of full and partial conformance are defined (see Levels of Conformance).
Implementing ATAG 2.0 document: The Implementing ATAG 2.0 document provides
additional non-normative information for each success criterion, including a
description of the intent of the success criterion, examples and links to relatedresources.
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 WCAG2.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
7/29/2019 Essential Components of Web Accessibility
12/113
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 accessibleweb 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 of the common factors evaluated when setting the level in Part B included:
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.
7/29/2019 Essential Components of Web Accessibility
13/113
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 integrate features that support accessible authoring with the "look-and-feel"
of 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 applicability notes in this section are normative.
PART A: Make the authoring tool user interface accessible
Applicability Notes:
Scope of authoring tool user interface: The Part A success criteria apply to all
aspects of the authoring tool user interface that are under the control of the
authoring tool developer. 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 display the web content being edited in a way that is
accessible to authors with disabilities (e.g., ensuring that a text alternative 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., if an image in the content lacks a label),
then this would not be considered a deficiency in the accessibility of the authoring
tool user interface.
User agent features: Web-based authoring tools may rely on user agent features
(e.g., keyboard navigation, find functions, display preferences, undo features, etc.)
to satisfy success criteria. If a conformance claim is made, the claim cites the user
agent.
7/29/2019 Essential Components of Web Accessibility
14/113
Features for meeting Part A must be accessible: The Part A success criteria apply to
the entire authoring tool user interface, including any features added to meet the
success criteria in Part A (e.g., documentation, search functions, etc.). The only
exemption is for preview features, as long as they meet Guideline A.3.7. Previews
are treated differently than editing views because all authors, including those with
disabilities, benefit when preview features accurately reflect the actual functionality
of user agents.
PRINCIPLE A.1: Authoring tool user interfaces must follow applicable accessibility
guidelines
Guideline A.1.1: [For the authoring tool user interface] Ensure that web-based
functionality is accessible. [Implementing A.1.1]
Rationale: When authoring tools or parts of authoring tools (e.g., an online help
system) 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): Web-based authoring tool user
interfaces conform to WCAG 2.0 Level A. (Level A) [Implementing A.1.1.1]
A.1.1.2 Web-Based Accessible (WCAG Level AA): Web-based authoring tool user
interfaces conform to WCAG 2.0 Level AA. (Level AA) [Implementing A.1.1.2]
A.1.1.3 Web-Based Accessible (WCAG Level AAA): Web-based authoring tool user
interfaces conform to WCAG 2.0 Level AAA. (Level AAA) [Implementing A.1.1.3]
Guideline A.1.2: [For the authoring tool user interface] Ensure that non-web-basedfunctionality is accessible. [Implementing A.1.2]
Rationale: When authoring tools or parts of authoring 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 platform conventions that support
accessibility will facilitate access by all authors, including those using assistive
technologies.
A.1.2.1 Non-Web-Based Accessible: Non-web-based authoring tool user interfaces
follow accessibility standards and/or platform conventions that support accessibility.
(Level A) [Implementing A.1.2.1]
Note: If a conformance claim is made, the claim cites the accessibility standards
and/or platform conventions that were followed.
PRINCIPLE A.2: Editing views must be perceivable
7/29/2019 Essential Components of Web Accessibility
15/113
Guideline A.2.1: [For the authoring tool user interface] Make alternative content
available to authors. [Implementing A.2.1]
Rationale: Some authors require access to alternative content in order to interact
with the web content that they are editing.
A.2.1.1 Recognized Alternative Content: If recognized alternative content is
available for editing view content renderings, then the alternative content is
provided to authors. (Level A) [Implementing A.2.1.1]
Guideline A.2.2: [For the authoring tool user interface] Editing view presentation
can be programmatically determined. [Implementing A.2.2]
Rationale: Some authors need access to the editing view presentation because this
may be used to convey both status information added by the authoring tool (e.g.,
underlining misspelled words) and, within content renderings, information about the
end user experience of the web content being edited.
A.2.2.1 Purpose of Added Presentation: If an editing view modifies the presentation
of web content to provide additional information to authors, then that additional
information can be programmatically determined. (Level A) [Implementing A.2.2.1]
A.2.2.2 Access to Text Presentation (Minimum): If an editing view (e.g., WYSIWYG
view) renders any of the following presentation properties for text, then those
properties can be programmatically determined: (Level A) [Implementing A.2.2.2]
(a) Text Font; and
(b) Text Style (e.g., italic, bold); and
(c) Text Color; 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 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 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 the web content to be
published. (Level A) [Implementing A.2.3.1]
7/29/2019 Essential Components of Web Accessibility
16/113
PRINCIPLE A.3: Editing views must be operable
Guideline A.3.1: [For the authoring tool user interface] Provide keyboard access to
authoring features. [Implementing A.3.1]
Rationale: Some authors with limited mobility or visual disabilities are not able to
use a mouse, and instead require full keyboard access.
A.3.1.1 Keyboard Access (Minimum): All functionality of the authoring tool is
operable through a keyboard interface, except where editing web content properties
that encode continuous input. (Level A) [Implementing A.3.1.1]
Note 1: This exception relates to the nature of web content, not the usual input
technique. For example, setting the path of a freehand curve is exempt, while
setting the endpoints of a straight line is not.
Note 2: This should not be interpreted as discouraging mouse input or other input
methods in addition to the keyboard interface.
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, then focus can be moved away from that
component using standard keyboard navigation commands (e.g., TAB key); and
(b) In Editing Views that Render Web Content: If an editing view renders web
content (e.g., WYSIWYG view), then a documented keyboard command is provided
that will always restore keyboard focus to a known location (e.g., the menus).
A.3.1.3 Keyboard Shortcuts: Keyboard shortcuts are provided. (Level AA)
[Implementing A.3.1.3]
A.3.1.4 Keyboard Access (Enhanced): All functionality of the authoring tool is
operable through a keyboard interface. (Level AAA) [Implementing A.3.1.4]
A.3.1.5 Customize Keyboard Access: Keyboard access to the authoring tool can be
customized. (Level AAA) [Implementing A.3.1.5]
A.3.1.6 Present Keyboard Commands: Authoring tool user interface controls can be
presented with any associated keyboard commands. (Level AAA) [Implementing
A.3.1.6]
Guideline A.3.2: [For the authoring tool user interface] Provide authors with enough
time. [Implementing A.3.2]
7/29/2019 Essential Components of Web Accessibility
17/113
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 fast reaction speed, such as clicking on a moving target.
A.3.2.1 Data Saved (Minimum): If the authoring tool includes authoring session
time limits, then the authoring tool saves all submitted content edits made byauthors. (Level A) [Implementing A.3.2.1]
A.3.2.2 Timing Adjustable: If a time limit is set by the authoring tool, then at least
one of the following is true: (Level A) [Implementing A.3.2.2]
(a) Turn Off: Authors are allowed to turn off the time limit before encountering it;
or
(b) Adjust: Authors are allowed to adjust the time limit before encountering it over
a wide range that is at least ten times the length of the default setting; or
(c) Extend: Authors are warned before time expires and given at least 20 seconds
to extend the time limit with a simple action (e.g., "press the space bar"), and
authors are allowed to extend the time limit at least ten times; or
(d) Real-time Exception: The time limit is a required part of a real-time event (e.g.,
a collaborative authoring system), and no alternative to the time limit is possible;
or
(e) Essential Exception: The time limit is essential and extending it would invalidate
the activity; or
(f) 20 Hour Exception: The time limit is longer than 20 hours.
A.3.2.3 Static Pointer Targets: User interface components that accept pointer input
are either stationary or authors can pause the movement. (Level A) [Implementing
A.3.2.3]
A.3.2.4 Content Edits Saved (Extended): The authoring tool can be set to save all
content edits made by authors. (Level AAA) [Implementing A.3.2.4]
Guideline A.3.3: [For the authoring tool user interface] Help authors avoid flashing
that could cause seizures. [Implementing A.3.3]
Rationale: Flashing can cause seizures in authors with photosensitive seizure
disorder.
A.3.3.1 Static View Option: Rendering of time-based content (e.g., animations) in
editing views can be turned off. (Level A) [Implementing A.3.3.1]
7/29/2019 Essential Components of Web Accessibility
18/113
Guideline A.3.4: [For the authoring tool user interface] Enhance navigation and
editing via content structure. [Implementing A.3.4]
Rationale: Some authors who have difficulty typing or operating the mouse benefit
when authoring tools make use of the structure present in web content to simplify
the tasks of navigation and editing the content.
A.3.4.1 Edit By Structure: Editing views for structured web content include editing
mechanism(s) that can make use of the structure. (Level A) [Implementing
A.3.4.1]
A.3.4.2 Navigate By Structure: Editing views for structured web content include
navigation mechanism(s) that can make use of the structure. (Level A)
[Implementing A.3.4.2]
Guideline A.3.5: [For the authoring tool user interface] Provide text search of the
content. [Implementing A.3.5]
Rationale: Some authors who have difficulty typing or operating the mouse benefit
from the ability to use text search to navigate to arbitrary points within the web
content being authored.
A.3.5.1 Text Search: Authors can perform text searches of web content as follows:
(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;
Note: If the current editing view is not able to display the results of a search, then
the authoring tool may provide a mechanism to switch to a different editing view to
display the results;
and
(b) Bi-Directional: The search can be made forwards or backwards; and
(c) Case Sensitive: The search can be in both case sensitive and case insensitive
modes.
Guideline A.3.6: [For the authoring tool user interface] Manage preference settings.
[Implementing A.3.6]
7/29/2019 Essential Components of Web Accessibility
19/113
Rationale: Providing the ability to save and reload sets of keyboard and display
preference settings benefits authors who have needs that differ over time (e.g., due
to fatigue).
A.3.6.1 Save Settings: Any authoring tool display settings and control settings are
saved between authoring sessions. (Level AA) [Implementing A.3.6.1]
A.3.6.2 Respect Platform Settings: The authoring tool respects platform display
settings and control settings. (Level AA) [Implementing A.3.6.2]
Note: As per Success Criterion A.2.3.1, authors' display settings must still be
independent of the web content being edited.
A.3.6.3 Multiple Sets: Authors can save and reload multiple sets of any authoring
tool display settings and control settings. (Level AAA) [Implementing A.3.6.3]
A.3.6.4 Preferences Assistance: The authoring tool includes a mechanism to help
authors configure any preference settings related to Part A of this document. (Level
AAA) [Implementing A.3.6.4]
Guideline A.3.7: [For the authoring tool user interface] Ensure that previews are as
accessible as existing user agents. [Implementing A.3.7]
Rationale: Preview features are provided in many authoring tools because the
workflow of authors often includes periodically checking how user agents will
display the web content to end users. Authors with disabilities need to be able to
follow the same workflow.
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: If a preview is provided, then at least one of the following is true:
(Level A) [Implementing A.3.7.2]
(a) Third-Party User Agent: The preview makes use of an existing third-party user
agent; or
(b) UAAG (Level A): The preview conforms to the User Agent Accessibility
Guidelines Level A [UAAG].
PRINCIPLE A.4: Editing views must be understandable
Guideline A.4.1: [For the authoring tool user interface] Help authors avoid and
correct mistakes. [Implementing A.4.1]
7/29/2019 Essential Components of Web Accessibility
20/113
Rationale: Some authors 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.
(Level A) [Implementing A.4.1.1]
Note 1: It is acceptable to collect a series of text entry actions (e.g., typed words, a
series of backspaces) into a single reversible authoring action.
Note 2: It is acceptable for certain committing actions (e.g., "save", "publish") to
make all previous authoring actions irreversible.
A.4.1.2 Undo Setting Changes: Actions that modify authoring tool settings are
either reversible or include a warning to authors that the action is irreversible.
(Level A) [Implementing A.4.1.2]
A.4.1.3 Undo is Reversible: Authors can immediately reverse the most recent
"undo" action(s). (Level AA) [Implementing A.4.1.3]
Guideline A.4.2: [For the authoring tool user interface] Document the user interface
including all accessibility features. [Implementing A.4.2]
Rationale: Some authors may not be able to understand or operate the authoring
tool user interface without proper accessible documentation.
A.4.2.1 Document Accessibility Features: All features that are specifically required
to meet Part A of this document (e.g. keyboard shortcuts, text search, etc.) are
documented. (Level A) [Implementing A.4.2.1]
A.4.2.2 Document All Features: All features of the authoring tool are documented.
(Level AA) [Implementing A.4.2.2]
PART B: Support the production of accessible content
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: For author-generated content,
the requirements of Part B only apply during authoring sessions. For example, if the
author includes a third-party feed in their web content, the authoring tool is not
required to provide checking for web content accessibility problems in that feed
after the end of the authoring session. In contrast, for automatically-generated
content, Part B continues to apply after the end of the authoring session. For
7/29/2019 Essential Components of Web Accessibility
21/113
example, if the site-wide templates of a content management system are updated,
these would be required to meet the accessibility requirements for automatically-
generated content.
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 tomeet the requirements of Part B (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 to meet the
success criteria in Part B (e.g., checking tools, repair tools, tutorials,
documentation, etc.).
Multiple author roles: Some authoring tools include multiple author roles, each with
different views and content editing permissions (e.g., a content management
system may separate the roles of designers, content authors, and quality assurers).
In these cases, the Part B success criteria apply to the authoring tool as a whole,
not to the view provided to any particular author role.
PRINCIPLE B.1: Production of accessible content must be enabled
Guideline B.1.1: Support web content technologies that enable the creation of
content that is accessible. [Implementing B.1.1]
Rationale: For the purposes of this document, WCAG 2.0 defines the accessible web
content requirements. To support accessible web content production, at minimum,
it must be possible to produce web content that conforms with WCAG 2.0 using the
authoring tool.
B.1.1.1 Accessible Content Production (WCAG Level A): Authors can use the
authoring tool to produce web content that conforms to WCAG 2.0 Level A. (Level
A) [Implementing B.1.1.1]
B.1.1.2 Accessible Content Production (WCAG Level AA): Authors can use the
authoring tool to produce web content that conforms to WCAG 2.0 Level AA. (Level
AA) [Implementing B.1.1.2]
B.1.1.3 Accessible Content Production (WCAG Level AAA): Authors can use the
authoring tool to produce web content that conforms to WCAG 2.0 Level AAA.
(Level AAA) [Implementing B.1.1.3]
Guideline B.1.2: Ensure that the authoring tool preserves accessibility information.
[Implementing B.1.2]
7/29/2019 Essential Components of Web Accessibility
22/113
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): Any accessibility information
(WCAG 2.0 Level A) recognized in the input to any web content transformation is
preserved as accessibility information in the output, if allowed by the web contenttechnology of the output. (Level A) [Implementing B.1.2.1]
B.1.2.2 End Product Cannot Preserve Accessibility Information: If the web content
technology of the output of a web content transformation cannot preserve
recognized accessibility information (WCAG 2.0 Level A) (e.g., saving a structured
graphic to a raster image format), then at least one of the following are true: (Level
A) [Implementing B.1.2.2]
(a) Option to Save: authors have the option to save the accessibility information in
another way (e.g., as a "comment", as a backup copy of the input); or
(b) Warning: authors are warned that this will result in web content accessibility
problems in the output.
B.1.2.3 Preserve Accessibility Information (Enhanced): Any accessibility information
(up to WCAG 2.0 Level AAA) recognized in the input to any web content
transformation is preserved as accessibility information in the output. (Level AA)
[Implementing 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) [Implementing B.1.2.4]
(a) Preserve Accessibility Information: The authoring tool only automatically deletes
web content that it can detect is not accessibility information; or
(b) Notification Option: Authors have the option to receive notification before
deletion; or
(c) No Deletion Option: Authors have the option to prevent automatic deletion by
the authoring tool.
Guideline B.1.3: Ensure that automatically generated content is accessible.[Implementing B.1.3]
Rationale: Authoring tools that automatically generate content that is not accessible
impose additional repair tasks on authors.
7/29/2019 Essential Components of Web Accessibility
23/113
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 the authoring tool
automatically generates content, then that web content conforms to WCAG 2.0Level A prior to publishing. (Level A) [Implementing B.1.3.1]
Note: This success criterion only applies to the automated behavior specified by the
authoring tool developer. It does not apply when actions of 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.2 Accessible Auto-Generated Content (Level AA): If the authoring tool
automatically generates content, then that web content conforms to 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 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 Accessible Auto-Generated Content (Level AAA): If the authoring tool
automatically generates content, then that web content conforms to WCAG 2.0
Level AAA prior to publishing. (Level AAA) [Implementing B.1.3.3]
Note: This 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.).
PRINCIPLE B.2: Authors must be supported in the production of accessible
content
Guideline B.2.1: Guide authors to create accessible content. [Implementing B.2.1]
Rationale: By guiding authors from the outset towards the creation and
maintenance of accessible web content, web content accessibility problems are
mitigated and less repair effort is required.
B.2.1.1 Decision Support: If the authoring tool provides the option of producing a
web content technology for publishing for which the authoring tool does not provide
7/29/2019 Essential Components of Web Accessibility
24/113
support for the production of accessible content, then both of the following are
true: (Level A) [Implementing B.2.1.1]
(a) Warning: 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 a list 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]
B.2.1.3 Other Technologies: If the authoring tool can insert web content that it
cannot subsequently edit, then authors can associate accessibility information with
that web content. (Level A) [Implementing B.2.1.3]
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 Level A): If the authoring tool provides authors
with the ability to add or modify web content so that any WCAG 2.0 Level A
Success Criterion can be violated, then accessibility checking for those success
criteria is provided (e.g., an HTML authoring tool that inserts images should checkfor alternative text; a video authoring tool with the ability to edit text tracks should
check for captions). (Level A) [Implementing B.2.2.1]
Note: Automated 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 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.2 Availability: Checking is available prior to publishing in a manner
appropriate to the workflow of the authoring tool. (Level A) [Implementing B.2.2.2]
B.2.2.3 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
7/29/2019 Essential Components of Web Accessibility
25/113
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 web content accessibility problem is correctly
identified (i.e., manual checking and semi-automated checking), the relevantcontent is identified (e.g., highlighting the affected content, displaying line
numbers, etc.) (Level A) [Implementing B.2.2.4]
B.2.2.5 Check Accessibility (WCAG Level AA): If the authoring tool provides authors
with the ability to add or modify web content so that any WCAG 2.0 Level AA
Success Criterion can be violated, then accessibility checking for those success
criteria is provided. (Level AA) [Implementing B.2.2.5]
Note: Automated 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 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. (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 or a 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 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.)
B.2.2.8 Check Accessibility (WCAG Level AAA): 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 is possible (and encouraged) for
many types of web content accessibility problems. However, manual checking is the
minimum requirement to meet this 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.
7/29/2019 Essential Components of Web Accessibility
26/113
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 the
utility 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
content accessibility problem that is identifiable during checking (as required by
Guideline B.2.2), repair assistance is provided. (Level A) [Implementing B.2.3.1]
Note: 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, the
authoring tool provides authors with instructions for repairing problems, which
authors must carry out by themselves. For more information on repair, see
Implementing ATAG 2.0 - Appendix C: Levels of Repair Automation.
B.2.3.2 Repair Accessibility (WCAG Level AA): For each WCAG 2.0 Level AA web
content accessibility problem 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]
Note: 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, the
authoring tool provides authors with instructions for repairing problems, which
authors must carry out by themselves. For more information on repair, see
Implementing ATAG 2.0 - Appendix C: Levels 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) for many
types of web content accessibility problems. However, manual repair is the
minimum requirement to meet this success criterion. In manual repair, theauthoring tool provides authors with instructions for repairing problems, which
authors must carry out by themselves. For more information on repair, see
Implementing ATAG 2.0 - Appendix C: Levels of Repair Automation.
Guideline B.2.4: Assist authors with managing alternative content for non-text
content. [Implementing B.2.4]
7/29/2019 Essential Components of Web Accessibility
27/113
Rationale: Improperly generated alternative content can create accessibility
problems and interfere with accessibility checking.
See Also: This guideline applies when non-text content is specified by authors (e.g.,
inserts an image). When non-text content is automatically added by the authoring
tool, see Guideline B.1.3.
B.2.4.1 Editable: Authors are able to modify alternative content for non-text
content. This includes types of alternative content that may not typically be
displayed on screen by user agents. (Level A) [Implementing B.2.4.1]
B.2.4.2 Automated Suggestions: During the authoring session, the authoring tool
can automatically suggest alternative content for non-text content only under the
following conditions: (Level A) [Implementing B.2.4.2]
(a) Author Control: Authors have the opportunity to accept, modify, or reject the
suggested alternative content prior to insertion; and
(b) Relevant Sources: The suggested alternative content is only derived from
sources designed to fulfill the same purpose (e.g., suggesting the value of an
image's "description" metadata field as a long description).
B.2.4.3 Let User Agents Repair: After the end of an authoring session, the
authoring tool does not attempt to repair alternative content for non-text content
using text value that is equally available to user agents (e.g., the filename is not
used). (Level A) [Implementing B.2.4.3]
B.2.4.4 Save for Reuse: Authors have the option of having any recognized plain
text alternative content that they enter (e.g., short text labels, long descriptions)
stored for future reuse. (Level AA) [Implementing B.2.4.4]
Guideline B.2.5: Assist authors with accessible templates and other 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 theeffort required of authors, and demonstrating the importance of accessible web
content.
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]
7/29/2019 Essential Components of Web Accessibility
28/113
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 Accessible Templates: 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.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 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]
(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.
B.2.5.5 New Templates: If authors can use the authoring tool to create new
templates for use by a template selection mechanism, they have the option to
record the accessibility status of the new templates. (Level AA) [Implementing
B.2.5.5]
B.2.5.6 Pre-Authored Content Selection Mechanism: If authors are provided with a
selection mechanism for pre-authored content other than templates (e.g., clip art
gallery, widget repository, design themes), then both of the following are true:
(Level AA) [Implementing B.2.5.6]
(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.
7/29/2019 Essential Components of Web Accessibility
29/113
B.2.5.7 Templates in Repository: If the authoring tool provides a repository of
templates, then each of the templates has a recorded accessibility status. (Level
AAA) [Implementing B.2.5.7]
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 recordedaccessibility status. (Level AAA) [Implementing B.2.5.8]
B.2.5.9 Templates Accessible (WCAG Level AAA): If the authoring tool automatically
selects templates or pre-authored content, then the selections conform to WCAG
2.0 Level AAA when used. (Level AAA) [Implementing B.2.5.9]
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.
PRINCIPLE B.3: Accessibility solutions must be promoted and integrated
Guideline B.3.1: Ensure that accessible authoring actions are given prominence.
[Implementing B.3.1]
Rationale: When authors are learning a new authoring tool, they may find and learn
to use the first authoring action they encounter that achieves their intended
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 (WCAG Level A): If authors are provided with
a choice of authoring actions for achieving the same authoring outcome (e.g.,
styling text), then options that will result in web content conforming to WCAG 2.0
Level A are at least as prominent as options that will not. (Level A) [Implementing
B.3.1.1]
B.3.1.2 Accessible Options Prominent (WCAG Level AA): If authors are provided
with a choice of authoring actions for achieving the same authoring outcome (e.g.,
styling text), then options that will result in web content conforming to WCAG 2.0
Level AA are at least as prominent as options that will not. (Level AA)
[Implementing B.3.1.2]
B.3.1.3 Accessible Options Prominent (WCAG Level AAA): If authors are provided
with a choice of authoring actions for achieving the same authoring outcome (e.g.,
styling text), then options that will result in web content conforming to WCAG 2.0
Level AAA are at least as prominent as options that will not. (Level AAA)
[Implementing B.3.1.3]
7/29/2019 Essential Components of Web Accessibility
30/113
Guideline B.3.2: Ensure that features of the authoring tool supporting the
production of accessible content are available. [Implementing B.3.2]
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.
B.3.2.1 Active by Default: All accessible content support features are turned on by
default. (Level A) [Implementing B.3.2.1]
B.3.2.2 Reactivate Option: If authors turn off an accessible content support feature,
then they can always turn the feature back on. (Level A) [Implementing B.3.2.2]
B.3.2.3 Deactivation Warning: If authors turn off an accessible content support
feature, then the authoring tool informs them that this may increase the risk of
content accessibility problems. (Level AA) [Implementing B.3.2.3]
B.3.2.4 At Least as Prominent: Accessible content support features are at least as
prominent as comparable features related to other types of web content problems
(e.g., invalid markup, syntax errors, spelling and grammar errors). (Level AA)
[Implementing B.3.2.4]
Guideline B.3.3: Ensure that features of the authoring tool supporting the
production of accessible content are documented. [Implementing B.3.3]
Rationale: Without documentation of the features that support the production of
accessible content (e.g., prompts for text alternatives, accessibility checking tools),
some authors may not be able to use them.
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.1 Model Accessible Practice (WCAG Level A): A range of examples in the
documentation (e.g., markup, screen shots of WYSIWYG editing views)
demonstrate WCAG 2.0 Level A accessible authoring practices. (Level A)
[Implementing B.3.4.1]
7/29/2019 Essential Components of Web Accessibility
31/113
B.3.4.2 Model Accessible Practice (WCAG Level AA): A range of examples in the
documentation (e.g., markup, screen shots of WYSIWYG editing views)
demonstrate WCAG 2.0 Level AA accessible authoring practices. (Level AA)
[Implementing B.3.4.2]
B.3.4.3 Model Accessible Practice (WCAG Level AAA): A range of examples in thedocumentation (e.g., markup, screen shots of WYSIWYG editing views)
demonstrate WCAG 2.0 Level AAA accessible authoring practices. (Level AAA)
[Implementing B.3.4.3]
Conformance
This section is normative.
Conformance means that the authoring tool satisfies the 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 producing accessible web content (in Part B).
Note on "accessibility-supported ways of using technologies":
Part of conformance to WCAG 2.0 is the requirement that "only accessibility-
supported ways of using technologies are relied upon to satisfy the [WCAG 2.0]
success criteria. Any information or functionality that is provided in a way that is
not accessibility supported is also available in a way that is accessibility supported."
In broad terms, WCAG 2.0 considers a web content technology to be accessibility
supported when (1) the way that the web content technology is used is supported
by users' assistive technology and (2) the web content technology has accessibility-
supported user agents that are available to end users.
This concept is not easily extended to authoring tools because many authoring tools
can be installed and used in a variety of environments with differing availabilities
for assistive technologies and user agents (e.g., private intranets versus public
websites, monolingual sites versus multilingual sites, etc.). Therefore:
For the purposes of ATAG 2.0 conformance, the accessibility-supported requirement
is waived.
7/29/2019 Essential Components of Web Accessibility
32/113
Once an authoring tool has been installed and put into use, it is 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.
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 Level A success criteria.
Full ATAG 2.0 Conformance at Level AA
The authoring tool satisfies all of the Level A and Level AA success criteria.
Full ATAG 2.0 Conformance at Level AAA
The authoring tool satisfies all of the success criteria.
And the Part A Applicability Notes and Part B 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 userinterface accessible):
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
implied about Part B.
7/29/2019 Essential Components of Web Accessibility
33/113
Partial ATAG 2.0 Conformance Level AA: Authoring Tool User Interface
The authoring tool satisfies all of the 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 success criteria in Part A. Nothing is implied
about Part B.
And the Part A 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 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 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 success criteria in Part B. Nothing is implied
about Part A.
And the Part B 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
"Full" Conformance.
Web Content Technologies Produced:
Authoring tools conform to ATAG 2.0 with respect to the production of specific web
content technologies (e.g., Full Level A conformance with respect to the production
of XHTML 1.0, Partial Level AA Conformance: Content Production with respect to
the production of SVG 1.1).
7/29/2019 Essential Components of Web Accessibility
34/113
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.
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):
Conditions on Conformance Claims
At least one version of the conformance claim must be published on the web as a
document meeting Level A of WCAG 2.0. A suggested metadata description for this
document is "ATAG 2.0 Conformance Claim".
Whenever the claimed conformance level is published (e.g., product information
web site), the URI for the on-line published version of the conformance claim must
be included.
The existence of a conformance claim does not imply that the W3C has reviewedthe 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
7/29/2019 Essential Components of Web Accessibility
35/113
Conformance level satisfied.
Authoring tool information: The name of the authoring tool and sufficient additional
information to specify the version (e.g., vendor name, version number (or version
range), required patches or updates, human language of the user interface or
documentation).
Note: If the authoring tool is a collection of software components (e.g., a markup
editor, an image editor, and a validation tool), then information must be provided
separately for each component, although the conformance claim will treat them as
a whole. As stated above, the Claimant has sole responsibility for the conformance
claim, not the developer of any of the software components.
Web content technologies produced.
A list of the web content technologies produced by the authoring tool that the
Claimant is including in the conformance claim. For each web content technology,provide information on how the web content technology might be used to create
accessible web content (e.g., provide links to technology-specific techniques).
A list of any web content technologies produced by the authoring tool that the
Claimant is not including in the conformance claim.
Declarations: For each success criterion:
A declaration of whether or not the success criterion has been satisfied; or
A declaration that the success criterion is not applicable and a rationale for why not.
Platform(s): The platform(s) upon which the authoring tool was evaluated:
For user agent platform(s) (used to evaluate web-based authoring tool user
interfaces): provide the name and version information of the user agent(s).
For platforms that are not user agents (used to evaluate non-web-based authoring
tool user interfaces): provide the name and version information of the platform(s)
(e.g., operating system, etc.) and the name and version of the platform
accessibility architecture(s) employed.
Optional Components of an ATAG 2.0 Conformance Claim
A description of the authoring tool that identifies the types of editing views that it
includes.
A description of how the ATAG 2.0 success criteria were met where this may not be
obvious.
7/29/2019 Essential Components of Web Accessibility
36/113
"Progress Towards 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
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 beingprogressed 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.
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 A: Glossary
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. Please consult http://www.w3.org/TR/qaframe-spec/ for
more information on the role of definitions in specification quality.
Accessibility problem
ATAG 2.0 refers to two types of accessibility problems:
authoring tool user interface accessibility problem: An aspect of an authoring tool
user interface that does not meet a success criterion in Part A of ATAG 2.0.
web content accessibility problem: An aspect of web content that does not meet a
WCAG 2.0 success criterion.
accessibility information
Any information that web content is required to contain in order to conform with a
particular level of WCAG 2.0 (e.g., text alternatives for images, role and state
information for widgets, relationships within complex tables, captions for audio).
accessible content support features
Any features of an authoring tool that directly support authors in increasing the
accessibility of the content being edited (i.e., features added to meet any of the
7/29/2019 Essential Components of Web Accessibility
37/113
success criteria in Principle B.2: Authors must be supported in the production of
accessible content).
Alternative content
Web content that is used in place of other content that a person may not be able to
access. Alternative content fulfills essentially the same function or purpose as the
original content. Examples include text alternatives for non-text content, captions
for audio, audio descriptions for video, sign language for audio, media alternatives
for time-based media. See WCAG 2.0 for more information.
ASCII art
A picture created by a spatial arrangement of characters or glyphs (typically from
the 95 printable characters defined by ASCII).
Assistive technology
Software (or hardware), separate from the authoring tool, that provides
functionality to meet the requirements of users with disabilities. Some authoring
tools may also provide direct accessibility features. Examples of assistive
technologies include, but are not limited to, the following:
screen magnifiers, and other visual reading assistants, which are used by people
with visual, perceptual and physical print disabilities to change text font, size,
spacing, color, synchronization with speech, etc. in order improve the visual
readability of rendered text and images;
screen readers, which are used by people who are blind to read textual information
through synthesized speech or Braille;
text-to-speech software, which is used by some people with cognitive, language,
and learning disabilities to convert text into synthetic speech;
speech recognition software, which may be used by people who have some physical
disabilities;
alternative keyboards, which are used by people with certain physical disabilities to
simulate the keyboard (including alternate keyboards that use head pointers, single
switches, sip/puff and other special input devices);
alternative pointing devices, which are used by people with certain physical
disabilities to simulate mouse pointing and button activations.
audio
7/29/2019 Essential Components of Web Accessibility
38/113
The technology of sound reproduction. Audio can be created synthetically (including
speech synthesis), recorded from real world sounds, or both.
authors
People who use an authoring tool to create or modify web content for use by other
people. This may include content authors, designers, programmers, publishers,
testers, etc. working either alone or collaboratively (see also Part B Applicability
Note 5). A person only qualifies as an author of some given content if (1) the
authoring tool supports the relevant web content technology used to implement
that content and (2) the person has author permission for that content.
author permission
Whether a person has a right to modify given web content. In other words, whether
they qualify as an author of the content. Some authoring tools are capable of
managing authoring permissions in order to prevent unauthorized modifications.
authoring action
Any action that authors can take using the authoring tool user interface that results
in creating or editing web content (e.g., typing text, deleting, inserting an element,
applying a template). Most authoring tool user interfaces also enable actions that
do not edit content (e.g., setting preferences, viewing documentation).
authoring outcome
The content or content modifications that result from authoring actions. Authoring
outcomes are cumulative (e.g., text is entered, then styled, then made into a link,
then given a title).
authoring practice
An approach that authors follow to achieve a given authoring outcome. (e.g.,
controlling presentation with style sheets). Depending on the design of an authoring
tool, authoring practices may be chosen by the authors or by the authoring tool. An
accessible authoring practice is one in which the authoring outcome conforms to
WCAG 2.0. Some accessible authoring practices require accessibility information.
authoring session
A state of the authoring tool in which web content can be edited by an author. The
end of an authoring session is the point at which the author has no further
opportunity to make changes without starting another session. The end of an
authoring session may be determined by authors (e.g., closing a document,
publishing) or by the authoring tool (e.g., when the authoring tool transfers editing
7/29/2019 Essential Components of Web Accessibility
39/113
permission to another author on a collaborative system). Note that the end of the
authoring session is distinct from publishing. Automatic content generation may
continue after the end of both the authoring session and initial publishing (e.g.,
content management system updates).
authoring tool
Any software, or collection of software components, that authors can use to create
or modify web content for use by other people.
Examples of authoring tools: ATAG 2.0 applies to a wide variety of web content
generating applications, including, but not limited to:
web page authoring tools (e.g., WYSIWYG HTML editors)
software for directly editing source code (see note below)
software for converting to web content technologies (e.g., "Save as HTML" featuresin office suites)
integrated development environments (e.g., for web application development)
software that generates web content on the basis of templates, scripts, command-
line input or "wizard"-type processes
software for rapidly updating portions of web pages (e.g., blogging, wikis, online
forums)
software for generating/managing entire web sites (e.g., content managementsystems, courseware tools, content aggregators)
email clients that send messages in web content technologies
multimedia authoring tools
debugging tools for web content
software for creating mobile web applications
Web-based and non-web-based: ATAG 2.0 applies equally to authoring tools of web
content that are web-based, non-web-based or a combination (e.g., a non-web-based markup editor with a web-based help system, a web-based content
management system with a non-web-based file uploader client).
Real-time publishing: ATAG 2.0 applies to authoring tools with workflows that
involve real-time publishing of web content (e.g., some collaborative tools). For
these authoring tools, conformance to Part B of ATAG 2.0 may involve some
7/29/2019 Essential Components of Web Accessibility
40/113
combination of real-time accessibility supports and additional accessibility supports
available after the real-time authoring session (e.g., the ability to add captions for
audio that was initially published in real-time). For more information, see the
Implementing ATAG 2.0 - Appendix E: Real-time content production.
Text Editors: ATAG 2.0 is not intended to apply to simple text editors that can beused to edit source content, but that include no support for the production of any
particular web content technology. In contrast, ATAG 2.0 can apply to more
sophisticated source content editors that support the production of specific web
content technologies (e.g., with syntax checking, markup prediction, etc.).
authoring tool user interface
The display and control mechanism that authors use to operate the authoring tool
software. User interfaces may be non-web-based or web-based or a combination
(e.g., a non-web-based authoring tool might have web-based help pages):
authoring tool user interface (non-web-based): Any parts of an authoring tool user
interface that are not implemented as web content and instead run directly on a
platform that is not a user agent, such as Windows, Mac OS, Java Virtual Machine,
etc.
authoring tool user interface (web-based): Any parts of an authoring tool user
interface that are implemented using web content technologies and are accessed by
authors vi