This section is informative, except where noted.
This is a Working Draft of the Authoring Tool Accessibility Guidelines
(ATAG) version 2.0. This document includes recommendations for assisting
developers to make their authoring tools more accessible to a
wide range of people with disabilities, including blindness and low vision,
deafness and hearing loss, learning disabilities, cognitive limitations,
limited movement, speech difficulties, and others. However, even authoring
tools that conform to ATAG 2.0 may not be able to address the needs of people
with all types, degrees and combinations of disabilities.
In order to achieve accessibility, authoring tools must address the needs
of two (potentially overlapping) user groups:
- authors of Web
content, whose needs are met by ensuring the authoring tool user
interface itself is accessible (see 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, with the assumption that many authors will not be familiar with
the specific needs of end users with disabilities (see Part B of the
guidelines).
The guidelines do not include standard usability recommendations except
where they have a significantly greater impact on people with disabilities
than on other people.
Note that even content that conforms at the highest level (AAA) will not
be accessible to individuals with all types, degrees, or combinations of
disability, particularly in the cognitive language and learning areas.
Creation of authoring tools that address the specialized needs of these
communities for is encouraged, but is outside the scope of this document.
These guidelines have been written to address the requirements of many
different audiences, including, but not limited to:
- Web content authoring tool developers,
- Web content authoring tool users (authors),
- Web content authoring tool purchasers, and
- policy makers.
ATAG 2.0 defines an "authoring
tool" as any software, or collection of
software components, that authors can use to create or modify Web content for
use by other people.
===================
ATAG 2.0 defines an authoring tool as any application, part of an
application, or collection of applications that authors interact with to
create, modify or assemble Web content to be used by other people.
These guidelines apply to the functions of the authoring tool that present
authoring choices to the author or makes choices on behalf of the author.
These guidelines do not apply to when the author has no editorial control.
The definition applies to all or part of the following types of
applications:
- WYSIWYG editors, plain text editors (embedded and stand-alone)
- conversion tools, software that can output Web content technologies
(e.g., "Save as HTML")
- blogging tools, wikis, online forums, emailers that produce
Web-content
- multimedia authoring tools
- scripting tools, widget development environment
- content management systems, courseware tools, content aggregators
- site management tools
- etc.
Note 1: Synchronous tools (e.g., chats, collaboration
tools, whiteboards, etc.), especially those that archive as Web content, are
considered authoring tools and can be made more accessible for both
participants and users of the stored archives. While not all parts of ATAG
2.0 will usefully apply, some techniques
for real-time content production are available.
Note 2: Guidelines in this document that require the ability
of authors to modify content in some way always assume that the author has
editorial control.
===========================
For example, in a CMS system managing a portal, the
widget that selects the RSS feed would be covered by ATAG, but the data
coming in on the RSS feed would not apply. In a large document management
system, the components that allowed entry or selection of alternative formats
would apply, but the components that displayed dynamic content where there is
no editorial control, would not apply.
However, the definition excludes cases in which:
- the authoring tool lacks authoring functionality...
- authors lack permission to edit content
- authors lack knowledge about future changes to
content (e.g., media files to be submitted by end users, aggregated news
feeds, etc.)
For example, ATAG does not apply to a component that
imports documents into a document share system, or a portal that aggregates
RSS feeds. ATAG does apply to the portal management widget that selects the
RSS.
assemble?
These guidelines apply to the functions in which
authoring choices the authoring tool presents to the author or makes on
behalf of the author.
This definition can cover components such as :
- IN
- Typing text
- Authoring choice
- Creating templates
- Setting stylesheets
- Create controls
- OUT
- Pulling in stuff that is out of control
- JT:
- Interact with human author
- Choices under control of tool
Components of Web
Accessibility
Authoring tools are just one aspect of
accessibility. For an overview of the different components of accessibility
and how they work together see:
Organization of
the ATAG 2.0 Document
Two Parts
ATAG 2.0 is divided into two parts, each reflecting a key aspect of
accessible authoring tools. Part A includes principles and associated
guidelines that are related to ensuring accessibility of the authoring tool user
interface to authors
with disabilities. Part B contains
principles and guidelines related to ensuring support by authoring tools for
the creation of accessible Web content by
any author (not
just those with disabilities) to end users with disabilities.
Part A: Make the authoring tool user
interface accessible
The guidelines and success criteria in Part A are organized around the
following four principles, adapted from the four principles in WCAG 2.0:
- Authoring tool must
facilitate access by assistive technology - Assistive technologies can
only provide augmented display and control to their users if the relevant
information is made available by authoring toolsusing common protocols.
- Authoring tool must be
perceivable - Authors with a wide range of abilities must be
able to perceive its user interface components.
- Authoring tool must
be operable - Authors
with a wide range of abilities must be able to operate its user interface
components.
- Authoring tool must be
understandable - Authors with a wide range of abilities must
be able to understand the user interface components that they can
perceive and operate.
Part B: Support the production of
accessible content
There are three principles in Part B:
- Production of
accessible content must be enabled - The creation of accessible content is
dependent on the combined actions of the authoring tool and the author. This guideline
specifies the responsibilities that rest exclusively with the tool.
- Authors must be supported
in the production of accessible content - Actions may be
taken at the author's initiative that may result in accessibility
problems. The authoring tool should include features that provide
support and guidance to authors in these situations, so that accessible authoring
practices can be followed and accessible web content can
be produced.
- Accessibility solutions
must be promoted and integrated -Authoring tools should
encourage the discovery of tools, features, or functionality which
support accessible authoring practices, while at the same time,
integrating functions related to accessibility in order to ensure that
authors make them common practice.
Note: While the requirements in Part B do not deal with
the accessibility of the authoring tool user interface per se, it
should be noted that any of the features (e.g., checker, tutorial) added to
an authoring tool to meet the Part B success criteria must also meet the user
interface accessibility requirements of Part
A.
Success Criteria
Under each guideline there are success criteria that describe specifically
what must be achieved in order to conform. They are similar to the
"checkpoints" in ATAG 1.0. Each success criterion is written as a statement
that will be either true or false when a specific authoring tool is tested against it.
While all of the ATAG 2.0 success criteria are written to be testable and
some test automation may be possible, human testing will usually be required.
In order to meet the needs of different groups and different situations,
three levels of conformance are defined: A (lowest), AA, and AAA
(highest).
Each of the success criteria has a link to the Techniques document that
provides:
- "Sufficient" techniques for meeting
the success criteria, and @@define@@
- optional "Advisory" techniques.@@define@@
Note: Any success criteria that are judged not applicable
to a particular authoring tool are treated as satisfied for conformance
purposes, as long as a rationale is provided.
Levels of
Conformance
Authoring tools may claim full conformance to ATAG 2.0 at one of three
"full" conformance levels. The level achieved depends on the level of the success criteria that have been
satisfied. The full conformance levels are:
- Full ATAG 2.0 Conformance at Level "A"
The authoring tool satisfies all of the Level A success criteria.
- Full ATAG 2.0 Conformance at Level "Double-A"
The authoring tool satisfies all of the Level A and Level AA success criteria.
- Full ATAG 2.0 Conformance at Level "Triple-A"
The authoring tool satisfies all of the success criteria.
@@Maybe remove partial@@
In addition, a "partial conformance" claim option is available in cases
where an authoring tool has satisfied all of the success criteria at a
specified level in one of the two Parts of the document (i.e., "Part A: Make
the authoring tool user interface accessible" and "Part B: Support the
production of accessible content"). The partial conformance levels are:
- Partial ATAG 2.0 Conformance Level "A": Authoring Tool User
Interface
The authoring tool satisfies all of the Level A success criteria in Part A. Nothing
is claimed about Part B.
- Partial ATAG 2.0 Conformance Level "Double-A": Authoring Tool
User Interface
The authoring tool satisfies all of the Level A and Level AA success criteria in Part A.
Nothing is claimed about Part B.
- Partial ATAG 2.0 Conformance Level "Triple-A": Authoring Tool
User Interface
The authoring tool satisfies all of the success
criteria in Part A. Nothing is claimed about Part B.
- 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 claimed about Part A.
- Partial ATAG 2.0 Conformance Level "Double-A": Content
Production"
The authoring tool satisfies all of the Level A and Level AA success criteria in Part B.
Nothing is claimed about Part A.
- Partial ATAG 2.0 Conformance Level "Triple-A": Content
Production"
The authoring tool satisfies all of the success
criteria in Part B. Nothing is claimed about Part A.
Note: The Working Group remains committed to the guiding
principle that: "Everyone should have the ability to create and access
Web content". Therefore, it is recommended that partial conformance be
claimed as a step towards full conformance.
Relationship to the Web
Content Accessibility Guidelines (WCAG) @@rephrase@@
The ATAG 2.0 conformance relies upon Web Content Accessibility "Benchmark" documents to
precisely specify what an evaluator interprets "accessible Web content" to
mean for the particular Web content technologies that
an authoring tool produces and, in the case of Web-based
tools, is implemented using.
The primary recommended reference for the Web Content Accessibility
"Benchmark" is a version of the W3C Web Content Accessibility
Guidelines (WCAG), due to the quality of the documents and the process under
which they were developed (See Note on other
Accessibility Standards). At the time of publication, version 1.0 of WCAG
is a W3C Recommendation [WCAG10], and version 2.0 is a W3C Candidate Recommendation
[WCAG20]. Although a Web Content
Accessibility "Benchmark" document may use either version of WCAG, developers
should give consideration to the following:
- The latest version of WCAG will be the most accurate with respect to
state-of-the-art technologies and accessibility best practices. Older
versions of WCAG may include requirements that are no longer necessary,
due to advances in user agent
technology.
- The versions of WCAG differ with respect to the technologies for which there are published
WCAG technique documents. This is important because the techniques
documents may be useful when constructing Web Content Accessibility
"Benchmark" documents as required by ATAG 2.0.
- The versions of WCAG differ in the degree to which they match the
legislation and policies that drive author requirements. Many authors
will be seeking to use authoring tools to create Web content that meets
legislation, corporate policies, etc. It is likely that as WCAG
progresses, so too will legislation and policies, albeit at an uneven
pace. Authoring tool developers may, therefore, consider supporting both
versions of WCAG in the interim.
ATAG 2.0
Guidelines
PART A: Make
the authoring tool user interface accessible
Applicability:
In some cases, success criteria in Part A may apply equally well to both
authoring tool functionalities that reflect the content being edited and those functionalities
that do not. When it is necessary to remove ambiguity about the scope of a
success criterion, the criterion will include one of the following labels:
- Content
Dependent: These success criteria apply only to functionality that
reflects the content being edited (e.g., content renderings, the document object), which the author may
have created with a different tool and that the authoring tool may or may
not recognize.
Accessibility
problems in the content dependent user interface that are due to accessibility
problems in the content are exempt from the usual requirements (e.g.,
if image markup content lacks a text label, it is permissible for a WYSIWYG rendering of
that image to lack a label).
- Content
Independent: These success criteria apply only to functionality
that does not vary according to the "content being edited" (e.g., the
authoring tool's menus, user preferences, and documentation).
PRINCIPLE A.1: Authoring tools must follow
applicable specifications and conventions
Guideline A.1.1 [For the authoring tool user
interface] Ensure that Web-based functionality is accessible. [Techniques]
Rationale: In addition to generally
improving the accessibility of the authoring tool user interface,
implementing Web-based functionality
(e.g., editing
views, documentation) using accessible Web content
facilitates communication with assistive technologies via user agents.
Applicability Note: This guideline does not apply to non-Web-based
authoring tool user interfaces, but does includes any parts of
non-Web-based authoring tools that are Web-based (e.g., help systems).
Level A Success Criteria for Guideline
A.1.1
Level AA Success Criteria for Guideline
A.1.1
- A.1.1.2 Web-Based "AA" Accessible:
Web-based authoring tool user interfaces meet WCAG level "AA".
Level AAA Success Criteria for Guideline
A.1.1
- A.1.1.3 Web-Based "AAA" Accessible:
Web-based authoring tool user interfaces meet WCAG level "AAA".
Guideline A.1.2 [For the authoring tool user
interface] Ensure that non-Web-based functionality is accessible. [Techniques]
Applicability Note: This guideline does not apply to Web-based authoring tool user interfaces.
Level A Success Criteria for Guideline
A.1.2
- A.1.2.1 Non-Web-Based "A" Accessible:
Meet, at a minimum level, all applicable
platform and accessibility standards and conventions.@@we need to ensure "functional
equivalency"@@
Level AA Success Criteria for Guideline
A.1.2
- (No level AA success criteria for Guideline A.1.2)
Level AAA Success Criteria for Guideline
A.1.2
- (No level AAA success criteria for Guideline A.1.2)
Guideline A.2.1
[For the authoring tool user interface] Provide access to alternative
equivalents in the content. [Techniques]
Rationale: People who have difficulty
perceiving non-text objects are often
able to access text alternatives of the
same information because there are a variety of ways to display text (e.g.,
magnification, enhancement, text-to-speech, Braille output)
Applicability Note: Since the first success criteria only
applies when non-text objects are rendered in an editing view. This exempts
plain text editors.
Level A Success
Criteria for Guideline A.2.1
Guideline A.2.3 [For the authoring tool
user interface] Ensure that the interface can be presented in different ways.
[Techniques]
Rationale: Authors need to have access to and control over both
the functional significance of presentation and also, in the context of
authoring, the presentation that will be experienced by the end user. This is especially important for user
interface components that do not implement an accessibility platform
architecture or leverage existing implementations (e.g. custom user interface
components built via JavaScript and CSS). Some authors require display settings that differ from the
presentation that they intend to define for
the published content (e.g., using a high
contrast setting during editing content that is not intended to be high
contrast).
Level A Success Criteria for Guideline
A.2.3
- A.2.4.1 Independence of Display: Editing
views that usually have their display characteristics set by
rendering the content being edited (e.g., WYSIWYG editing views) allows the authors' visual and audio display settings to
override these characteristics without affecting the content (e.g.,
markup, stylesheets, etc.) being edited.
- A.2.3.3 Purpose of Added Presentation:
If the authoring tool modifies the presentation of the content being
edited, then the functional purpose for the modification is made
available via the platform (e.g., if misspelled text is underlined, the
fact that it is misspelled is made available).
- A.2.3.4 Access to Text Presentation
(Minimum): If an editing view
(e.g., WYSIWYG) renders any of the following
text presentation properties and those properties are editable by any
editing view (e.g., instruction
level), then the properties are made available via the platform:
- (a) font,
- (b) style (e.g., italic, bold),
- (c) color, and
- (d) size.
Level AA Success Criteria for Guideline
A.2.3
- (No level AA success criteria for Guideline A.2.3)
Level AAA Success Criteria for Guideline
A.2.3
- A.2.3.7 Access to Text Presentation
(Enhanced): Any text presentation properties (text size,
positioning, etc.) that are rendered in an editing view (e.g., WYSIWYG editing views ) and editable by any
editing view are available via the platform.
PRINCIPLE A.3:
Authoring tool user interface must be operable
Guideline
A.3.1 [For the authoring tool user interface] Enhance keyboard access to
authoring features. [Techniques]
Rationale: Providing alternate keyboard
accessibility provides access for people with limited mobility and people
with visual disabilities, who cannot rely on hand-eye coordination for
navigating the user interface.
Conformance Note: Web-based
authoring tool user interface functionality may rely on the keyboard
navigation functions of the user agent listed in the conformance profile to satisfy some of these success
criteria.
Level A Success Criteria for Guideline
A.3.1
- A.3.1.6 Accelerator Keys: If the
authoring tool includes any of the following functions, authors can
enable key-plus-modifier-key (or single-key) access to them (where
allowed by the operating environment):
- (a) open help system,
- (b) open new content,
- (c) open existing content,
- (d) save content,
- (e) close content,
- (f) cut/copy/paste,
- (g) undo/redo, and
- (h) open find/replace function.
- A.3.1.3 Available Keystrokes: Authors
can always determine the currently available keystrokes (e.g., from a
central location such as a list in the help system or a distributed
location such as associating shortcuts with menu items). [UAAG 2.0]
- A.3.1.4 Standard Text Area Conventions:
Editing views that allow text entry support the standard text area
conventions for the platform including, but not necessarily limited to:
character keys, backspace/delete, insert, "arrow" key navigation, page
up/page down, navigate to start/end, navigate by paragraph,
shift-to-select mechanism, etc.
Level AA Success Criteria for Guideline
A.3.1
Level AAA Success Criteria for Guideline
A.3.1
Guideline
A.3.2 [For the authoring tool user interface] Enable time-independent
interaction. [Techniques]
Rationale: People who have difficulty
typing, operating the mouse, or processing information can be prevented from
using systems with short time limits.
Applicability Note: Several of the success criteria in
this guideline only apply when there are time limits put on the author, which
is currently not very common for authoring tools.
Level A
Success Criteria for Guideline A.3.2
- A.3.2.1 Data Saved: If the authoring
tool ends an authoring session due
to a time limit (e.g., authenticated session expires), then the authors
have the "pre-settable" option to save the
content being edited. For Web-Based Authoring
Tools, this applies to any content that has already been submitted to
the application by the user agent.
- A.3.2.2 Timing Adjustable: If the
authoring tool is responsible for imposing a time limit on authoring
sessions (e.g., to mediate collaborative authoring), then authors can extend the
time limit.
- A.3.2.3 Moving
Targets: If components that act
as targets for authors' actions (e.g., are clickable, accept
drag-and-drop actions) are capable of movement, then authors can stop
that movement.
Level AA
Success Criteria for Guideline A.3.2
- (No level AA success criteria for Guideline A.3.2)
Level
AAA Success Criteria for Guideline A.3.2
- A.3.2.4 No Time Limits: Authors have
the option to remove time limits on authoring sessions.
Guideline
A.3.3 [For the authoring tool user interface] Help authors avoid flashing
that could cause seizures.[Techniques]
Rationale: Flashing can cause seizures
in people with photosensitive epilepsy.
Level A
Success Criteria for Guideline A.3.3
- A.3.3.2 Blinking Request: If an editing view renders content such the
authoring tool recognizes as blinking or flashing (e.g.
blink
element), then
the author has the option to turn off this blinking or flashing.
Level
AA Success Criteria for Guideline A.3.3
- (No level AA success criteria for Guideline A.3.3)
Level AAA Success Criteria for Guideline
A.3.3
Guideline A.3.4
[For the authoring tool user interface] Enhance navigation and editing via
content structure. [Techniques]
Rationale: People who have difficulty
typing or operating the mouse benefit when the structure that may be inherent
in certain content can be used to navigate more efficiently within editing views and to perform edits.
Level A
Success Criteria for Guideline A.3.4
Level AA
Success Criteria for Guideline A.3.4
- A.3.4.2 Navigate By Element Type (content display): If an
editing view displays a structured element set, authors can move the
editing focus forward/backward to the next identical or closely related
(e.g., in the case of headers) element.
- @@Navigate identicals@@
- @@Navigate headings@@
- A.3.4.3 Navigate Tree Structures (content display): If an
editing view displays a structured element set, authors can, with a
simple action, move the editing focus from any element to other elements
in the set with any of the following relationships (if they exist):
- (a) Parent: the element immediately
above,
- (b) Child: the first element
immediately below,
- (c) Previous Sibling: the element
immediately preceding at the same level, and
- (d) Next Sibling: the element
immediately following at the same level.
Level AAA
Success Criteria for Guideline A.3.4
- (No level AAA success criteria for Guideline A.3.4)
Guideline A.3.5 [For the
authoring tool user interface] Provide text search. [Techniques]
Rationale: People who have difficulty
typing or operating the mouse benefit from the ability to navigation to
arbitrary points within editing views.
Level A Success
Criteria for Guideline A.3.5
- (No level A success criteria for Guideline A.3.5)
Level AA Success
Criteria for Guideline A.3.5
- A.3.5.1 Text Search (content display): A text
search function is provided that meets the following conditions:
- (a) Search All Editable: can search
any textual information (including text content, text alternatives for non-text objects, metadata,
markup) that is editable using the
authoring tool.
- (b) Bi-Directional: can search
backwards and forwards. [UAAG
2.0]
- (c) Case Sensitive: can search in
both case sensitive and case insensitive modes. [UAAG 2.0]
- (d) May Switch Views: permissible
for the authoring tool to switch editing
views to display the search results (e.g., from WYSIWYG to instruction level in order to
display markup).
Level AAA Success
Criteria for Guideline A.3.5
- (No level AAA success criteria for Guideline A.3.5)
Note: Web-based authoring
tool user interface functionality may rely on the "find" function of the
user agent
listed in the conformance profile to help perform
the searches.
Guideline A.3.6 [For the authoring tool user
interface] Manage preference settings. [Techniques]
Rationale: Providing the ability to
save and reload sets of keyboard and display preference settings benefits
people using multi-user tools as well as people who have needs that differ
over time (e.g., due to fatigue).
Level A Success Criteria for Guideline
A.3.6
- (No level A success criteria for Guideline A.3.6)
Level AA Success Criteria for Guideline
A.3.6
- A.3.6.1 Save Settings (user interface "chrome"): Preference
settings are stored for any of the following that the authoring tool
controls (i.e., not controlled by the platform):
Level AAA Success Criteria for Guideline
A.3.6
- A.3.6.2 Multiple Sets (user interface "chrome"): Choosing
between multiple sets of preferences (e.g., personal profiles, personal
settings) are supported for any of the following that the authoring tool
controls (i.e., not controlled by the platform):
- A.3.6.3 Options Wizard (user interface "chrome"): Authors are provided with an accessibility
option-setting "wizard" to configure options related to Part A.
Guideline A.3.7 [For
the authoring tool user interface] Ensure that previews are as accessible as
existing user agents. [Techniques]
Rationale: Preview features are provided in many
authoring tools because the workflow of authors often includes periodically checking how
content will appear to end users in a user agent. Authors with disabilities need
to be able to follow the same workflow.
Note: Previews are treated differently
than editing views because authors, including
those with disabilities, will not be well-served if preview features diverge
too much from the actual functionality of available user agents. Therefore,
preview features are exempted from necessarily having to meet all of the
other requirements in Part A of this
guidelines document, if they meet this guideline.
Level A Success
Criteria for Guideline A.3.7
- A.3.7.1 Return Mechanism (user interface "chrome"): If a preview is provided,
then a keyboard accessible mechanism for returning from the preview
(i.e., moving focus back from, exiting from) is provided and is
documented in the help system.
- A.3.7.2 Preview (user
interface "chrome", content
display): If a preview is provided, then it meets at least
one of the following:
- (a) Existing User Agent: the
preview makes use of an existing user agent that is specified in
the conformance profile (e.g., opening
the content in a third-party browser or browser component),
- (b) Part A.1: the preview meets all of the
Level A guidelines in Part A of
these guidelines, or
- (c) UAAG: the preview conforms to
the User Agent Accessibility Guidelines [UAAG].
Level AA Success
Criteria for Guideline A.3.7
- (No level AA success criteria for Guideline A.3.7)
Level AAA
Success Criteria for Guideline A.3.7
- (No level AAA success criteria for Guideline A.3.7)
PRINCIPLE ???
Guideline A.4.3 [For the
authoring tool user interface] Help users avoid and correct mistakes. [Techniques]
Rationale: People who have difficulty
making fine movements may be prone to making unintended actions.
Note 1: Web-based authoring
tool user interface functionality may rely on the "undo" function of the
user agent
listed in the conformance profile to perform the
undo function for some editing actions that do not involve server
communication (e.g., typing in a text area).
Note 2: It is acceptable to collect text entry actions
(e.g., typed words, a series of backspaces) into a single reversible
authoring action.
Level A Success Criteria
for Guideline A.4.3
- A.4.3.1 Undo Content Changes (content display): Authoring actions are either reversible by an "undo" function or
include a warning to authors that the action is
irreversible. The authoring tool may have certain committing actions
(e.g., "save" function) that reset the undo history.
- A.4.3.2 Undo Setting Changes (user interface "chrome"): Actions that
modify authoring tool settings are either reversible or include a warning to the
author that the setting modification is irreversible.
Level AA Success
Criteria for Guideline A.4.3
Level AAA Success
Criteria for Guideline A.4.3
Guideline A.4.4 [For
the authoring tool user interface] Document the user interface including all
accessibility features. [Techniques]
Rationale: While intuitive user
interface design is valuable to many authors, some
people may still not be able to understand or be able to operate the authoring tool user interface
without proper documentation.
Level A Success
Criteria for Guideline A.4.4
- A.4.4.1 Accessible Format: At least one
version of the documentation is either:
- (a) "A" Accessible: Web content and
conforms to a minimum level of Web
content accessibility (although it is not necessary for the
documentation to be delivered on-line), or
- (b) Accessible Platform Format: not
Web content and conforms to a published accessibility benchmark that
is identified in the conformance claim
(e.g., when platform-specific documentation systems are used).
- A.4.4.2 Document Accessibility
Features: All features (other than documentation) that are
specifically required to meet Part A of these guidelines (e.g.
keyboard shortcuts, text search, etc.) are documented.
Level AA Success
Criteria for Guideline A.4.4
- (No level AA success criteria for Guideline A.4.4)
Level AAA
Success Criteria for Guideline A.4.4
- (No level AAA success criteria for Guideline A.4.4)
PART
B: Support the production of accessible content
Applicability:
Authoring Tools should guide the
author make choices that produce accessible content for the end user. If the
author and tool(s) in collaboration have the ability to produce content that
is accessible then they should aim to achieve this by conforming to Part B.
In situations where the author has no control over the content being
produced, (e.g. a feed being drawn in from another site), this content can be
deemed exempt from part B.
An authoring tool can be used in
conjunction with other software tools to form an authoring system. (e.g. a
authoring tool wiki could be used with a 3rd party software accessibility
checking and repair program.) An authoring tool is only expected to produce
accessible content for the technologies it has the ability to create or edit
(e.g. a tool that imports video content is not required to caption that
video), however, the tool should support and guide the author to create or
edit alternatives (e.g. links to transcripts, alternative text for
images).
While the production of accessible content is always
recommended, conformance claims are only made in reference to the benchmarked Web content technologies
identified in the conformance claim.
@@- Authors may only reasonably be expected to make
decisions about content that they have information about. Therefore,
authoring decisions that would require specific knowledge about content that
is unknown to author at the time of authoring (e.g., descriptions of media
files to be submitted by end users, aggregated news feeds, etc.) are exempt
from Part B.@@
@@ - Support for accessible authoring is only required for "Authored
Technologies" and those accessibility practices that take place in an
"Authored Technology", but are related to the "Referenced Technologies"
(e.g., alt text for images) with the exception that support for creating
"(Conforming) Alternate Versions" is not required.@@
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. [Techniques]
Rationale: Make it
easier for the author to create accessible content by choosing technologies
which support that.
Note: Understanding how content can be
made accessible in the technologies your tool outputs will be useful in
designing authoring support. Therefore, consider
creating/locating benchmark documents for technology(ies) that your authoring
tool outputs and Favor technologies with strong accessibility
capabilities.
to provide accessible WCT
among your choices of WCT, provide a choice of WCT with accessible WCT given
priority or selected by default, inform authors about which WCT are more
accessible, inform authors when they are choosing less accessible
WCT.
Applicability Note: This
guideline only applies when benchmarked technologies are available for
authoring the particular type of content required (e.g., text, images,
synchronized media).
Level A Success Criteria for Guideline
B.1.1
- B.1.1.1 Tool Choice of Technologies: If
the authoring tool automatically selects Web content technologies, then
the selection is a benchmarked
technologythat can conform to WCAG Level A.
If the authoring tool make automatic decisions
about technologies for the author, the technologies must have the
potential to be used to create accessible content.
- B.1.1.2 Author Choice of Technologies:
If the authoring tool provides authors with technology options, benchmarked technology options that can conform to WCAG Level A are listed with
at least as much prominence as any other optionsand the tool guides the author towards the most
accessible technology for the task. If
the author makes decisions about technologies for themselves, the tool
must provide guidance about which have the potential to be used to create
accessible content.
- The tool should guide the author towards the most
accessible technology for the task.
Level AA Success Criteria for Guideline
B.1.1
- B.1.1.3 Tool Choice of Technologies: If
the authoring tool automatically selects Web content technologies, then
the selection is a technology that can conform to WCAG Level AA.
- B.1.1.4 Author Choice of Technologies:
If the authoring tool provides authors with technology options,
technology options that can conform to WCAG Level AA are listed with at
least as much prominence as any other options and the tool guides the
author towards the most accessible technology for the task.
Level AAA Success Criteria for
Guideline B.1.1
- B.1.1.5 Tool Choice of Technologies: If
the authoring tool automatically selects Web content technologies, then
the selection is a technology that can conform to WCAG Level AAA.
- B.1.1.6 Author Choice of Technologies:
If the authoring tool provides authors with technology options,
technology options that can conform to WCAG Level AAA are listed with at
least as much prominence as any other options and the tool guides the
author towards the most accessible technology for the task.
Guideline B.1.2 Ensure that the authoring
tool preserves accessibility information. [Techniques]
Rationale: Accessibility information
is critical to maintaining comparable levels of accessibility across
transformations and conversions.@@aggregated
feeds@@
Level A Success Criteria for Guideline
B.1.2
- B.1.2.1 Transformation or Conversion
(Minimum): If the authoring tool performs transformations or conversions, then for recognized accessibility
information at least one of the following is true:
- (a) Preserve in Output: any
accessibility information in the pre-transformation/conversion content
is preserved and available for end users in the resulting content;
- (b) Preserve Input and Notify: a copy of the
pre-transformation/conversion accessibility information is retained
(e.g., as a "comment", by saving a backup copy) and the authors are
notified of the location; or
- (c) Author Queried: the author is
queried for an action for each piece of accessibility information
that will not be preserved.
Level AA Success Criteria for Guideline
B.1.2
- B.1.2.2 Transformation or Conversion
(Enhanced): If the authoring tool performs transformations or conversions, then any recognized
accessibility information in the pre-transformation/conversion content is
preserved and available for end users in the resulting content;
- B.1.2.3 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:
- (a) Preserve Accessibility
Information: the authoring tool can detect that the content
is not accessibility
information;
- (b) Notification Option: authors
have the option to receive notification before deletion; or
- (c) No Deletion Option: authors
have the option to turn off the automatic deletion.
Level AAA Success Criteria for
Guideline B.1.2
- (No level AAA success criteria for Guideline B.1.2)
Guideline B.1.3 Ensure that automatically
generated content is accessible. [Techniques]
Rationale: Authoring tools that automatically generate content that is not
accessible impose additional repair tasks on authors.
Related: 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.
Applicability Note 1: This guideline does not apply to
any accessibility
problems that informed authors have specifically allowed (e.g., by
setting less strict preferences) (see Guideline B.3.3 for more on informing the
author).
Applicability Note 2: This guideline does not apply when
authors have caused the accessibility problem(s) (e.g., by ignoring prompts
for accessibility information,
providing faulty information, etc.).
Level A Success Criteria for Guideline
B.1.3
- B.1.3.1 Automatic "A" Accessible: If
the authoring tool automatically
generates content, then that content
meets WCAG level A at the conclusion of
the automatic generation process (e.g., when inserted into the existing
content).
Level AA Success Criteria for Guideline
B.1.3
- B.1.3.2 Automatic "AA" Accessible: If
the authoring tool automatically generates content, then that content
meets the WCAG level AA at the
conclusion of the automatic generation process.
Level AAA Success Criteria
for Guideline B.1.3
- B.1.3.3 Automatic "AAA" Accessible: If
the authoring tool automatically generates content, then that content
meets the WCAG level AAA at the
conclusion of the automatic generation process.
PRINCIPLE B.2: Authors must be supported
in the production of accessible content
@@Preamble: Principle B.2 applies to
situations in which the application processes that interact with a human
authors, and the authoring choices that author is making or the authoring
choices under the control of the authoring tool. Authoring choices include
choice of style sheets, templates, scripts, etc
Guideline B.2.1 Guide
authors to create accessible content. [Techniques]
Rationale: By guiding the authors from the outset
towards the creation and maintenance of accessible content, accessibility
problems are mitigated and less repair and retrofit effort is required.@@Link to technique appendix!@@
Level A Success
Criteria for Guideline B.2.1
- B.2.1.1 Guide "A" Accessible: If authors are cued for
any information as content is being added or updated
(e.g., by an image modification dialog), then the tool also prominently cues for any accessibility
information required for that content to meet WCAG level A.
- B.2.1.2 Warn "A" Accessible: If an authoring action or instruction will
always lead to the creation of content that cannot be made to meet WCAG level A other than by making an
alternative version, then a warning is displayed.
Level AA Success
Criteria for Guideline B.2.1
- B.2.1.3 Guide "AA" Accessible: If
authors are cued for any information as content is being added or
updated, then the tool also prominently cues for accessibility
information required for that content to meet WCAG level AA.
- B.2.1.4 Warn "AA" Accessible: If an
authoring action or instruction will always lead to the creation of
content that cannot be made to meet WCAG level
AA other than by making an alternative version, then a warning is
displayed.
Level AAA Success
Criteria for Guideline B.2.1
- B.2.1.5 Guide "AAA" Accessible: If
authors are cued for any information as content is being added or
updated, then the tool also prominently cues for accessibility
information required for that content to meet WCAG level AAA.
- B.2.1.6 Warn "AAA" Accessible: If an
authoring action or instruction will always lead to the creation of
content that cannot be made to meet WCAG level
AAA other than by making an alternative version, then a warning is
displayed.
Guideline B.2.2 Assist authors
in checking for accessibility problems. [Techniques]
Rationale: Checking as an integrated function of the authoring
tool helps make authors
aware of accessibility
problems during the authoring process, so they can be immediately
addressed. @@JR: "authoring system" instead of
"authoring tool" to make more clear?@@
Note: While automated checking or more
advanced implementations of semi-automated checking may
improve the authoring experience, only manual
checking is minimally required to meet the success criteria for this
guideline.
Applicability Note: This guideline does not apply if the
authoring tool controls the authoring process to an extent that it is not
possible for authors to
introduce accessibility problems.
Note: Content that the author knows will change (e.g.,
aggregated feeds) or can't control (e.g., later user comments) will be exempt
from guiding/checking/repair.@@at top@@
Note: It is a good design decision for tools to remember
author answers to questions to prompts and checks.
Level A Success Criteria for
Guideline B.2.2
- B.2.2.1 Check "A" Accessibility: An
individual check is associated with each level
"A" WCAG Success Criterionthat the tool has
the functionality to modify (e.g., a tool that can edit captions should
check for them). Excessively general
checks (e.g., "does the page meet all of the requirements?") are not
acceptable.
- B.2.2.2 Check Before Publish: Checking is available prior to publishing in a manner appropriate to the
workflow of the authoring tool.
- B.2.2.2 Identify
Range: The appropriate range (e.g., element, group of elements,
entire file, site, Web application, etc.) for each potential
accessibility problem is identified. Note: JS thinks that having
this as a requirement precludes "on the fly" checking.
B.2.2.3 Identify the Scope: Comprehensive checks (e.g. a final
summary check of the output to be published) identifies the range (e.g.
elements, files, application) that is being checked.
- For manual checks, it is acceptable to save
author judgements. @@Move to AA@@
- Define "capabiltity to augment" - define
"unreasonable" , "reasonable to augment" "ability to augment"
- B.2.2.4 Help Authors Decide: For any
checks that require author judgment to determine whether a potential accessibility
problem is correctly identified (i.e., manual checking and semi-automated checking),
instructions are provided to help authors to decide.
Level AA Success Criteria
for Guideline B.2.2
- B.2.2.5 Check "AA" Accessibility: An
individual check is associated with each level
AA WCAG Success Criterion that the tool has the
functionality to modify (e.g., a tool that can edit captions should check
for them).
- B.2.2.6 Provide
Summary List of Problems: If the authoring tool records
accessibility problems found during checking, then a list of any
accessibility problems is available to authors prior to the end of the
authoring session.
- B.2.2.7 Save Status for Repair: If repair assistance is not provided during checking
, authors have the option to save the list to facilitate
interoperability between checking and repair.
- B.2.2.8 Record
Metadata for Discovery: If the authoring tool records
accessibility status, then authors have the option to associate this
status with the content as metadata to facilitate resource discovery by
end users.
Level AAA Success
Criteria for Guideline B.2.2
- B.2.2.9 Check "AAA" Accessibility: An
individual check is associated with each level AAA WCAG Success Criterion
that the tool has the functionality to modify
(e.g., a tool that can edit captions should check for them).
Guideline B.2.3 Assist
authors in repairing accessibility problems. [Techniques]
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.
Conformance Note: While automated repairing or more
advanced implementations of semi-automated repairing may
improve the authoring experience, only manual
repairing is minimally required to meet the success criteria for this
guideline.
Applicability Note: This guideline does not apply if the
authoring tool controls the authoring process to an extent that it is not
possible for authors to
introduce accessibility problems
Level A Success Criteria
for Guideline B.2.3
Level AA Success
Criteria for Guideline B.2.3
- B.2.3.2 Repair "AA" Accessibility: For
each accessibility problem that is identifiable during checking, repair
assistance is provided for conforming to WCAG
level AA.
Level AAA Success
Criteria for Guideline B.2.3
- B.2.3.3 Repair "AAA" Accessibility:
For each accessibility problem that is identifiable during checking,
repair assistance is provided for conforming to
WCAG level A.
Guideline B.2.4 Assist
authors to manage, edit, and reuse equivalent alternatives for non-text
objects. [Techniques]
Rationale: Improperly generated
equivalent alternatives can create accessibility problems and interfere with
accessibility checking.
Level A Success
Criteria for Guideline B.2.4
Level AA Success
Criteria for Guideline B.2.4
- B.2.4.3 Acceptable Sources: Authoring
tools only supply equivalent alternatives from the following sources:
- (a) Author-Entered: equivalent
alternatives previously entered by authors for the same non-text
object (e.g., by the same author, or another author on a
collaborative system),
- (b) From Object Database:
equivalent alternatives stored with the non-text object in an object
database (or equivalent),
- (c) Null when Appropriate: null
equivalent alternatives for non-text objects that the authoring tool
recognizes are only used for pure
decoration, or
- (d) Audio, Video, or CART Analysis:
automatic video or audio analysis (e.g., speech recognition).
Level AAA Success
Criteria for Guideline B.2.4
- B.2.4.4 Save for Reuse: Authors can
store, for future reuse, both of the following author-assigned equivalent
alternatives (as applicable):
Note: Equivalent alternatives should not be automatically generated from unreliable
sources (e.g., file names should not be used as text alternatives).
Guideline B.2.5 Assist authors with
accessible templates and other pre-authored content. [Techniques]
Rationale: As with
automatically-generated content (see Guideline B.1.3), templates and other pre-authored content (e.g., clip
art, synchronized media, widgets, etc.) that are not accessible impose
additional repair tasks on authors.
Applicability Note: Templates
may be complicated to check for accessibility due to their inherent
incompleteness. The accessibility status of templates is instead measured by
the accessibility of content (in the final technology) created through their
proper use.
Level A Success Criteria for Guideline
B.2.5
- B.2.5.1 Templates "A" Accessible: If
the authoring tool automatically selects templates or pre-authored content, then the
selection meets WCAG level A when
used.
- 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.
- B.2.5.3 Template Selection Mechanism:
If authors are
provided with a template
selection mechanism, then both of the following are true:
- (a) Indicate: the selection
mechanism indicates the accessibility status of templates (if
known),
- (b) Prominence: any accessible
template options have prominence that is comparable with
that of other options in the selection mechanism.
Level AA Success Criteria for
Guideline B.2.5
- B.2.5.4 Templates "AA" Accessible: If
the authoring tool automatically selects templates or pre-authored
content, then the selection meets the WCAG
level AA when used.
- 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.
- B.2.5.6 Templates in Repository: If the
authoring tool provides a repository of templates, then each of the
templates has a recorded accessibility status.
- B.2.5.7 Pre-Authored Content Selection
Mechanism: If authors are provided with a selection mechanism
for pre-authored content other than templates (e.g., clip art gallery,
widget repository, design themes), then both of the following are true:
- (a) Indicate: the selection
mechanism indicates the accessibility status of the pre-authored
content (if known),
- (b) Prominence: any accessible
options have prominence that is comparable with
that of other options in the selection mechanism.
- B.2.5.8 Pre-Authored Content in
Repository: If the authoring tool provides a repository of
pre-authored content, then each of the content objects has a recorded
accessibility status.
Level AAA Success Criteria for
Guideline B.2.5
- B.2.5.9 Templates "AAA" Accessible: If
the authoring tool automatically select templates or pre-authored
content, then the selection meets WCAG level
AAA when used.
Appendix D: Acknowledgments
Appendix
Editors:
- Jan Richards (Adaptive Technology Resource Centre, University of
Toronto)
- Roberto Scano (IWA/HWG
Participants
active in the AUWG at the time of publication:
- Tim Boland (National Institute for Standards and Technology)
- Ann McMeekin (Invited Expert)
- Greg Pisocky (Adobe)
- Jan Richards (Adaptive Technology Resource Centre, University of
Toronto)
- Andrew Ronksley (Royal National Institute for the Blind)
- Roberto Scano (IWA/HWG)
- Reed Shaffner (Microsoft)
- Dana Simberkoff (HiSoftware Inc.)
- Jeanne Spellman (W3C)
- Michael Squillace (IBM)
- Jutta Treviranus (WG Chair; Adaptive Technology Resource Centre,
University of Toronto)
Other
previously active AUWG participants and other contributors to ATAG 2.0:
Kynn Bartlett, Giorgio Brajnik, Judy Brewer, Wendy Chisholm, Daniel
Dardailler, Geoff Deering, Barry A. Feigenbaum, Katie Haritos-Shea, Kip
Harris, Phill Jenkins, Len Kasday, Marjolein Katsma, William Loughborough,
Karen Mardahl, Charles McCathieNevile, Matt May, Matthias Müller-Prove,
Liddy Nevile, Graham Oliver, Wendy Porch, Bob Regan, Chris Ridpath, Gregory
Rosmaita, Heather Swayne, Gregg Vanderheiden, Carlos Velasco, and Jason
White.
This document would not have been possible without the work of those who contributed to
ATAG 1.0.
This publication has been funded in part with Federal funds from the U.S.
Department of Education under contract number ED05CO0039. 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.