[Contents] [Guidelines]
Implementing ATAG 2.0
A guide to understanding and
implementing Authoring Tool Accessibility Guidelines 2.0
W3C Editors' Draft 13 April
2011
- This version:
- http://www.w3.org/WAI/AU/2011/ED-IMPLEMENTING-ATAG20-20110413/
- Latest version:
- http://www.w3.org/TR/IMPLEMENTING-ATAG20/
- Previous version:
- http://www.w3.org/WAI/AU/2011/ED-IMPLEMENTING-ATAG20-20110211/
- Editors:
- Jutta Treviranus, Inclusive Design Institute,
OCAD University
- Jan Richards, Inclusive Design Institute,
OCAD University
- Jeanne Spellman, W3C
- Previous Editors:
- Tim Boland, NIST
- 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.
This document provides non-normative information to authoring tool
developers who wish to satisfy the success criteria in the Authoring Tool Accessibility Guidelines
(ATAG) 2.0 [ATAG20]. This document includes
additional information about the intent of the success criteria, examples of
how the success criteria might be satisfied, and references to other related
resources.
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).
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.
Implementing ATAG 2.0 is an essential guide to understanding and using Authoring Tool Accessibility Guidelines
(ATAG) 2.0 [ATAG20]. Although the normative
definitions and requirements for ATAG 2.0 can all be found in the ATAG 2.0
document itself, the concepts and provisions may be new to some people.
Implementing ATAG 2.0 provides a non-normative extended commentary on each
guideline and each success criterion to help readers better understand the
intent and how the guidelines and success criteria work together. It also
provides illustrative examples for each success criterion.
This is not an introductory document. It is a detailed technical description
of the guidelines and their success criteria. See Authoring Tool Accessibility
Guidelines (ATAG) Overview for an introduction to ATAG 2.0, supporting
technical documents, and educational material.
Implementing ATAG 2.0 is organized by guideline. There is an
Implementing Guideline X.X.X section for each guideline. The rationale
for the guideline is listed there.
Each Implementing Guideline X.X.X section is then followed by an
Implementing Success Criterion X.X.X.X section for each success
criterion of that guideline. Each of these sections contains:
- Success criterion as it appears in ATAG 2.0
- Intent of the success criterion
- Examples
- Related resources
Links are provided from each Guideline in ATAG 2.0 directly to each
Implementing Guideline X.X.X in this document. Similarly, there is a
link from each success criterion in ATAG 2.0 to the Implementing Success
Criterion X.X.X.X section in this document.
Notes:
- The Working Group encourages authoring tool developers
to carefully consider the examples provided, where appropriate. However,
these examples do not provide a final definition of ATAG 2.0 conformance
and it is possible to meet the guideline requirements without implementing
these examples. The Working Group encourages implementers to submit
example implementations. These examples will be considered for inclusion in
future versions of this document.
- Some "Examples" include "mockups". These are for informative purposes
only and do not imply endorsement of similar tools or suggest that the
mockups represent the best or only implementations.
- "Related Resources" are for information purposes only, no endorsement is
implied.
- For links to information on different disabilities and assistive
technologies, see Disabilities on
Wikipedia.
ATAG 2.0 Layers of
Guidance
The individuals and organizations that may use ATAG 2.0 vary widely and
include authoring tool developers, authoring tool users (authors), authoring tool
purchasers, and policy makers. In order to meet the varying needs of this
audience, several layers of guidance are provided:
- Parts: ATAG 2.0 is divided into two parts, each
reflecting a key aspect of accessible authoring tools. Part A relates to ensuring the accessibility of authoring tool user interfaces to
authors with disabilities. Part B relates to ensuring
support by authoring tools for the creation, by any author (not just those
with disabilities), of web content that is accessible to end
users with disabilities. Both parts include normative
"Conformance Applicability Notes" that apply to all of the success criteria
within that part (see Part A Conformance
Applicability Notes, Part B Conformance
Applicability Notes).
- Principles: Under each part are several high-level
principles that organize the guidelines.
- Guidelines: Under the principles are guidelines. The
guidelines provide the basic goals that authoring tool developers should
work toward in order to make authoring tools more accessible to both
authors and end users of web content with different disabilities. The
guidelines are not testable, but provide the framework and overall
objectives to help authoring tool developers understand the success
criteria. Each guideline includes a brief rationale for why the guideline
was included.
- Success Criteria: For each guideline, testable success
criteria are provided to allow ATAG 2.0 to be used where requirements and
conformance testing are necessary, such as in design specification,
purchasing, regulation, and contractual agreements. In order to meet the
needs of different groups and different situations, multiple levels of full
and partial conformance are defined (see Levels of
Conformance).
- Implementing ATAG 2.0 document: The Implementing
ATAG 2.0 document provides additional non-normative information for
each success criterion, including a description of the intent of the
success criterion, examples and links to related resources.
Understanding Levels of Conformance
In order to ensure that the process of using ATAG 2.0 and WCAG 2.0 together in the development of authoring tools is as simple as
possible, ATAG 2.0 shares WCAG 2.0's three level
conformance model: Level A (lowest), AA (middle), AAA (highest).
As with WCAG 2.0, there are a number of
conditions that must be met for a success criterion to be included in ATAG 2.0.
These include:
- For Part A, all success criteria must present
authoring tool user interface-related accessibility
issues. In other words, the user interface issue must cause a
proportionately greater problem for authors with disabilities than it causes
authors without disabilities and must be specific to authoring tool
software, as opposed to software in general.
- For Part B, all success criteria must present
accessible web content production issues. In other words,
the issue must be specific to the production of accessible web content (WCAG)
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. WYSIWYG editors, wikis, 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 content (WCAG)
using an authoring tool)
- whether it is possible to satisfy the success criterion for the
production of all web content
technologies that the success criteria would apply to.
- whether the success criterion requires features that would
reasonably be used by authors.
- whether the success criterion would impose limits on the "look-and-feel"
and/or function of authoring tools (e.g. limits on the function, design,
aesthetic or freedom of expression of authoring tool
developers)
Integration of Accessibility
Features
When implementing ATAG 2.0, authoring tool developers
should carefully integrate features that support accessible authoring into the
same "look-and-feel" as other features of the authoring
tool. Close integration has the potential to:
- produce a more seamless product;
- leverage the existing knowledge and skills of authors;
- make authors more receptive to new accessibility-related authoring
requirements; and
- reduce the likelihood of author confusion.
Implementing ATAG 2.0 Guidelines
The success criteria and the conformance applicability notes are included
here for informative purposes. See Authoring Tool
Accessibility Guidelines 2.0 [ATAG20] for the normative version
of this information.
Implementing
PART A: Make the authoring tool user interface accessible
- Scope of "authoring tool user interface": The Part
A success criteria apply to all aspects of the authoring
tool user interface that are concerned with producing the "included" web content technologies. This
includes views of the web content being edited
and features that are independent of the content being edited, such as
menus, button bars, status bars, user preferences, documentation, etc.
- Reflected content accessibility problems: The authoring tool is responsible for
ensuring that editing-views display the web content being edited
in a way that is accessible to authors with disabilities (e.g. ensuring
that text alternatives
in the content can be programmatically
determined). However, where an accessibility problem is caused directly by the content
being edited (e.g. if an image in the content lacks a text alternative),
then this would not be considered a deficiency in the accessibility of the
authoring
tool user interface.
- Developer control: The Part A success criteria only
apply to the authoring
tool user interface as it is provided by the developer. It does not
apply to any subsequent modifications by parties other than the authoring
tool developer (e.g. by plug-ins, user modifications, etc.).
- User agent features: Web-based authoring tools may rely on user
agent features (e.g. keyboard navigation, find functions, display
preferences, undo features, etc.) to satisfy success criteria. If a conformance claim is made, the claim must cite the
user agent.
- Features for meeting Part A must be accessible: The
Part A success criteria apply to the entire authoring
tool user interface, including any features added to meet the success
criteria in Part A (e.g. documentation, search functions, etc.). The only
exemption is for preview features, as long as they meet the
relevant success criteria in Guideline A.3.7.
Previews are treated differently than editing-views because all authors,
including those with disabilities, benefit when preview features accurately
reflect the functionality of user agents that are actually in use by end users.
Implementing PRINCIPLE A.1: Authoring tool user
interfaces must follow applicable accessibility guidelines
Implementing Guideline A.1.1: (For the authoring tool
user interface) Ensure that web-based functionality is accessible. [Return
to Guideline]
Rationale: When authoring
tools (or parts of authoring tools) are web-based,
conforming to WCAG 2.0 will facilitate access by
all authors, including those using assistive technologies.
Implementing Success Criterion A.1.1.1 Web-Based
Accessible (WCAG): Web-based
authoring tool user interfaces meet the WCAG
2.0 success criteria.
The WCAG 2.0 Level A success criteria are met (Level
A); or
The WCAG 2.0 Level A and Level AA success criteria are met (Level AA); or
The WCAG 2.0 Level A, Level AA, and Level AAA success criteria are met (Level
AAA).
Intent
of Success Criterion A.1.1.1:
The intent of this success criterion is to ensure that authoring tool user
interfaces that are fully or partially web-based are accessible to authors with
disabilities. Since WCAG 2.0 already provides requirements for the
accessibility of web content, including web applications, those guidelines are
referenced to avoid duplication of requirements.
Examples of Success Criterion A.1.1.1:
- Wiki: A web-based wiki application is
designed to conform to WCAG 2.0 Level A. During development, all parts of
the user interface (including editing-views rendering test content) are
tested by the developer using an accessibility evaluation harness for web
applications. Periodically, the application is also tested by authors using
assistive technologies.
- Web-based help system: A non-web-based
authoring tool includes a web-based help system. Each page in the help
system is based on a template that was designed to conform to WCAG 2.0
Level A (when used) and the developer ensures that each help page passes an
accessibility checker before being published. The developer confirms the
accessibility of the final help system by spot-checking sample pages.
Related
Resources for Success Criterion A.1.1.1:
Implementing Guideline A.1.2: (For the authoring tool
user interface) Ensure that non-web-based functionality is accessible. [Return
to Guideline]
Rationale: When authoring
tools (or parts of authoring tools) are non-web-based,
following existing accessibility guidelines and implementing communication with
platform accessibility
services facilitates access by all authors, including those using
assistive technologies.
Implementing Success Criterion A.1.2.1 Accessibility
Guidelines: Non-web-based
authoring tool user interfaces follow user interface accessibility
guidelines for the platform. (Level A)
Note: If a conformance claim is made, then the
claim must cite the accessibility guidelines followed.
Intent
of Success Criterion A.1.2.1:
The intent of this success criterion is to ensure that authoring tool user
interfaces that are not web applications are accessible to authors with
disabilities. Existing accessibility guidelines are referenced because:
- accessibility guidelines already exist for many platforms,
- this wording allows developers the flexibility to conform with
accessibility legislation in their markets.
- the note that conformance claims must cite the accessibility guidelines
that were followed should encourage developers to refrain from implementing
obscure or weak requirements.
Note: Developers should see the documents listed in the "Related
Resources for Success Criterion A.1.2.1" section, below. Unless extenuating
circumstances exist (e.g. a document has been superseded, the platform has
undergone major architectural changes), the listed resources should be assumed
to be relevant to the platforms listed.
Examples of Success Criterion A.1.2.1:
- Mobile authoring tool: The developer of
an authoring tool on the iPhone platform follows the guidance in the
"Accessibility Programming Guide for iPhone OS".
Related
Resources for Success Criterion A.1.2.1:
- The following is a non-exhaustive list of accessibility guidelines for
various platforms (for additional information related to keyboard
shortcuts, see Success Criterion A.3.1.3):
- The following is a non-exhaustive list of general software accessibility
guidelines:
Implementing Success Criterion A.1.2.2 Platform
Accessibility Services: Non-web-based
authoring tools implement communication with platform accessibility
services. (Level A)
Note: If a conformance claim is made, then the
claim must cite the platform accessibility service(s) implemented.
Intent
of Success Criterion A.1.2.2:
The intent of this success criterion is to ensure that authoring tool user
interfaces that are not web applications are accessible to authors with
disabilities who use assistive technologies that communicate with software via
platform accessibility services. The requirement is stated generally because
the specifics of what constitutes a platform accessibility service will differ
on each platform.
The note that conformance claims must cite the platform accessibility
service(s) implemented should encourage developers to refrain from implementing
services that are not supported by assistive technologies.
Examples of Success Criterion A.1.2.2:
- WYSIWYG editor on Mac OS: A WYSIWYG text
editor is designed in Cocoa following the Mac OS X accessibility framework
including using Accessibility Objects setting attributes for Role, Role
Description, Description, Title, Relationship and Value. The conformance
claim includes links to the Accessibility Programming Guidelines for
Cocoa.
- Content management system on Windows:
Content management system on Windows: A content management system is
written to operate on the Windows operating systems following Microsoft
Windows' accessibility API, UI Automation, Microsoft Active Accessibility,
or IAccessible 2. The conformance claim includes links to the applicable
Microsoft Developer Network documents.
Related
Resources for Success Criterion A.1.2.2:
- The following is a non-exhaustive list of documents related to
communication with platform accessibility services for various platforms:
Implementing PRINCIPLE A.2: Editing-views must be
perceivable
Implementing Guideline A.2.1: (For the authoring tool
user interface) Make alternative content available to authors. [Return
to Guideline]
Rationale: Some authors require access to alternative content in order to interact with the web
content that they are editing.
Intent
of Success Criterion A.2.1.1:
The intent of this success criterion is to ensure that authors with
disabilities have access to text alternatives for non-text content within the
web content that they are editing, because this information can help authors
orient and navigate as they edit.
The term "programmatically associated" is simply a reminder that text
alternatives may appear within web content in ways that authoring tools are not
able to detect (e.g. when the information conveyed by an image is described in
an adjacent paragraph).
Examples of Success Criterion A.2.1.1:
- WYSIWYG editing-view: A WYSIWYG
editing-view renders images in the content being edited. If an image
includes alternative text, this information is exposed to assistive
technologies via the platform accessibility service.
Related
Resources for Success Criterion A.2.1.1:
Implementing Success Criterion A.2.1.2 Alternatives
for Rendered Time-Based Media: If an editing-view renders time-based media, then at
least one of the following is true: (Level A) (a) Alternatives Rendered: alternatives for
the time-based content are also rendered; or (b) User Agent Option: authors have
the option
to preview the time-based content in a user
agents that is able to render the alternatives.
Intent
of Success Criterion A.2.1.2:
The intent of this success criterion is to ensure that authors with
disabilities have access to alternatives for rendered time-based content in the
web content that they are editing, because this information can help authors
orient and navigate as they edit.
There are two ways to meet this success criterion.
Option (a) is to render the alternatives in conjunction with the rendered
time-based content. For example, a captioned video would have its captions
displayed when it played. This approach is preferable, since it does not
require authors to switch applications.
Option (b) is to instead provide authors with the option of rendering their
content in a user agent that is able to render the alternatives. While this is
not ideal from a usability perspective, it is necessary because alternatives
are sometimes provided in different modalities that authoring tools are not
equipped to render. For example, an audio editor might allow authors to edit
the waveform of the audio file and render (i.e., play) the resulting audio
files. However, the audio editor might not be equipped to render video, so if
an audio file includes an alternative that is a sign language file in video
format, the audio editor will need assistance in rendering the file.
Examples of Success Criterion A.2.1.2:
- Web-based WYSIWYG: A web-based WYSIWYG
editing-view is implemented so that videos placed into the content are
rendered. If the videos include captions these are displayed, meeting
(a).
- Audio editor: An audio editor allows
authors to edit audio tracks using the audio waveform. At any time, authors
can play the audio file. Sometimes the audio files include a link to a
video file that contains an alternative version (e.g. sign language).
Although the audio editor does not include the functionality to natively
render the video it provides the option to launch the video in a user agent
specified by the author, meeting (b).
Related
Resources for Success Criterion A.2.1.2:
Implementing Guideline A.2.2: (For the authoring tool
user interface) Editing-view presentation can be programmatically determined.
[Return
to Guideline]
Rationale: Some authors need access to details about the editing-view presentation, via
their assistive technology, when that presentation is used to convey status
information (e.g. underlining misspelled words) or provide information about
how the end user will experience the web content being edited.
Implementing Success
Criterion A.2.2.1 Editing-View Status Information: If an editing-view modifies the presentation to convey status information,
then that status information can be programmatically
determined. Status information conveyed by modifying the presentation of
editing-views may include, but is not limited to, spelling, grammar and syntax
errors. (Level A)
Intent
of Success Criterion A.2.2.1:
The intent of this success criterion is to ensure that, if the authoring
tool makes changes to the display of the web content being edited in order to
communicate status information with authors (e.g. to highlight spelling errors,
identify the location of markup tags, etc.), then authors with disabilities
will have the same access to that information as other authors.
Examples of Success Criterion A.2.2.1:
- Change tracking feature: A web-based
authoring tool includes a change tracking feature that displays inserted
text in green and deleted text in red with a strike-through style. Instead
of implementing this using simple CSS selectors, the authoring tool uses
the XHTML elements
ins
and del
, since these have
semantic meaning.
Related
Resources for Success Criterion A.2.2.1:
Implementing Success Criterion A.2.2.2 Access to
Rendered Text Properties: If a text property is both rendered and editable
and the property can be communicated by the supported platform accessibility
service, then the property is programmatically
determinable. (Level A)
Intent
of Success Criterion A.2.2.2:
The intent of this success criterion is to ensure that authors with
disabilities have access to text presentation information when this information
is already made available to other authors by editing-views. This is important
because this type of rendering acts as a type of preview to help authors
understand how their content may appear to end users, once it is published.
Authors who cannot see also need to understand how their web content will be
experienced by end users who can see.
Note: This success criterion pertains to the rendered properties of
text on the screen, even if the properties differ from the content being edited
(e.g. when authors chose custom display settings as per Success Criterion A.3.6.1). In this way, the views provided
on screen and via any assistive technologies can remain synchronized.
Examples of Success Criterion A.2.2.2:
- Non-web-based authoring tool: A
non-web-based authoring tool includes a WYSIWYG editing-view that
implements the appropriate platform accessibility service. Included in the
information passed to the platform accessibility service is information on
the size, font, foreground and background color, font weight, and position
of any rendered text.
- Web-based authoring tool: A web-based
WYSIWYG authoring tool uses style sheets to control text presentation,
enabling the presentation information to be programmatically determined by
the user agent, which then passes it on to the appropriate platform
accessibility service. The user agent is cited in any conformance claim.
Related
Resources for Success Criterion A.2.2.2:
Implementing PRINCIPLE A.3: Editing-views must be
operable
Implementing Guideline A.3.1: (For the authoring tool
user interface) Provide keyboard access to authoring features. [Return
to Guideline]
Rationale: Some authors with limited mobility or visual
disabilities are not able to use a mouse, and instead require keyboard access
to all of the functionality of the authoring
tool.
Implementing Success Criterion A.3.1.1 Keyboard
Access (Minimum): All functionality of the authoring
tool is operable through a keyboard
interface without requiring specific timings for individual keystrokes,
except where the underlying function requires input that depends on the path of
the user's movement and not just the endpoints. (Level A)
Note 1: The path exception relates to the underlying function, not the
input technique. For example, if using handwriting to enter text, the input
technique (handwriting) requires path-dependent input, but the underlying
function (text input) does not. The path exception encompasses other input
variables that are continuously sampled from pointing devices, including
pressure, speed, and angle.
Note 2: This success criterion does not forbid and should not discourage
providing mouse input or other input methods in addition to keyboard
operation.
Intent
of Success Criterion A.3.1.1 (Based on WCAG 2.0, Success Criterion 2.1.1):
The intent of this success criterion is to ensure that almost all authoring
tool functionality can be operated using a keyboard or an assistive technology
that makes use of a keyboard interface, such as onscreen scanning keyboards and
voice recognition systems.
The only exemption at Level A to this requirement involves functions that
require input that depends on the path of the user's movement and not just the
endpoints. This is a very narrow exception that relates to authoring web
content properties that contain hundreds or thousands of numerical values. The
exception exists because it is not reasonable to expect that authors using only
a keyboard would be prepared to hand-code so many data points. The exception
does not apply simply because the developers of an authoring tool have decided
to use mouse input to control functionality in the past (e.g. setting the
endpoints for straight lines, rectangles and circles). The exception also does
not apply simply because a functionality is related to graphics. Also, the
exception applies to the editing of particular properties. While editing the
path of a freehand curve may be exempt, setting the line color and thickness
likely would not be exempt. Finally, this is a Level A exception only. There is
no exception for the Level AAA requirement (Success
Criterion A.3.1.4).
Note 1 clarifies that the exception applies to the underlying function and
that pointing device input variables, such as pressure, speed and angle, are
also covered.
Note 2 clarifies that rather than replacing other types of interaction, the
keyboard access requirement is to provide an alternative.
Web-based authoring tools will already be required to meet this success
criterion as part of Success Criterion A.1.1.1.
Examples of Success Criterion A.3.1.1:
- Drag-and-drop feature: An authoring tool
allows authors to open documents by dragging them into the authoring tool
window. The same operation can be performed from the menus using the
keyboard.
- Keyboard manipulation of drawing objects:
A multimedia authoring tool allows authors to navigate the selection focus
between all of the drawing objects on the canvas. Once an object is
selected, it can be manipulated with keyboard-driven menu commands, some of
which have keyboard shortcuts (e.g. arrow keys to move the object, etc.).
New drawing objects can also be added from the keyboard-driven menus.
- Keyboard manipulation of drawing object
properties: A multimedia authoring tool does not include keyboard
access to the drawing canvas directly, but instead provides a keyboard
accessible list of drawing objects that allows a keyboard editable property
page to be brought up. The property pages include properties such as "top",
"left", "width", "height", "rotation", and "label". When these properties
are adjusted, the objects on the canvas are updated accordingly. New
drawing objects can be added from the keyboard-driven menus.
- Select and operate: An authoring tool
provides editing functionality in which authors can select content in the
editing-view (e.g. select text) and then perform an operation (i.e.
authoring action) on that selection (e.g. formatting, deletion, etc.).
Keyboard access to this functionality is enabled by the fact that the
selection can be made using the keyboard and that the selection is
maintained while the author uses the keyboard to navigate the authoring
tool user interface to arrive at the operation they want to perform.
Related
Resources for Success Criterion A.3.1.1:
Implementing Success Criterion A.3.1.2
No Keyboard Traps: Keyboard traps
are prevented as follows: (Level A) (a) In the Authoring
Tool User Interface: If keyboard focus can be moved to a component using a keyboard interface, then focus can
be moved away from that component using only a keyboard interface and, if it
requires more than unmodified arrow or tab keys or other standard exit methods,
the user is advised of the method for moving focus away; and (b) In Editing-Views
that Render Content: If an editing-view
renders content (e.g. WYSIWYG view), then a documented
keyboard command is provided that moves the editing-view keyboard focus to a
known location (e.g. the start of the editing-view).
Intent
of Success Criterion A.3.1.2 (Modified from WCAG 2.0, Success Criterion
2.1.2):
The intent of this success criterion is to ensure that neither the authoring
tool's own user interface nor any rendered web content within editing-views
"traps" keyboard focus. This problem may occur when an interactive object is
embedded in content. Authors might be able to move focus to the object (e.g. by
using the "tab" key) within a WYSIWYG editing-view, but they are unable to move
the focus out using the keyboard, because keyboard control has passed to the
embedded object.
The first requirement (a) applies only to the authoring tool user interface,
which is the part of the authoring tool that developers have the most control
over. In this case, there must not be any keyboard traps. If authors can move
focus to a component using standard keyboard navigation commands (e.g. using
the tab key), then they must be able to move focus out of the component in the
same way or be advised of the method.
The second requirement (b) applies to renderings of content. Because the
content may contain keyboard handlers, the authoring tool may not be able to
prevent keyboard traps entirely. Therefore, the requirement is only that the
authoring tool be able to restore the keyboard focus to some known location.
Examples of Success Criterion A.3.1.2:
- Non-web-based authoring tool: A
non-web-based authoring tool has a user interface that has been thoroughly
tested by the developer to ensure that no keyboard traps exist, meeting
(a). If authors open web content containing keyboard traps in the WYSIWYG
editing-view, the authoring tool allows authors to restore keyboard focus
to the top of the editing-view at any time by pressing the "Home" key,
which the authoring tool never passes to the content being edited, meeting
(b).
- Web-based authoring tool: A web-based
authoring tool has a user interface that has been thoroughly tested by the
developer to ensure that no keyboard traps exist, meeting (a). If authors
open content containing keyboard traps, the authoring tool relies on a
feature in the authors' user agent that always restores keyboard focus to
the address bar, meeting (b). The user agent is cited in any conformance claim.
Related
Resources for Success Criterion A.3.1.2:
Implementing Success Criterion A.3.1.3 Efficient
Keyboard Access: The authoring
tool user interface includes mechanisms to make keyboard access more
efficient than sequential
keyboard navigation. (Level AA)
Intent
of Success Criterion A.3.1.3:
The intent of this success criterion is to introduce a Level AA requirement
to strengthen the requirement of Success Criterion A.3.1.1. That success
criterion would be met even by a keyboard access mechanism in which users had
to sequentially navigate through every available user interface component in
order to reach their intended destination. This success criterion (A.3.1.3)
introduces the additional requirement that keyboard access must include
mechanisms to make it more efficient that this type of purely sequential
keyboard navigation.
The wording is intentionally general because the appropriate mechanisms
available for increasing the efficiency of keyboard access vary according to
the operating environment and the design of the authoring tool:
- In desktop environments with a full keyboard, there is generally some set
of keys available for developers to use as shortcut keys that directly link
to particular functionality (e.g. the "ctrl" + "S" key combination can be
directly mapped to the "Save" function).
- In web-based environments very few direct shortcut keys are available,
once the potential keys used by the various operating systems, user agents
and assistive technologies are taken into account. In this case, bypass
links are useful mechanisms for making keyboard access more efficient.
- In mobile environments, the situation is variable. Some mobile
environments include full, physical keyboards and support keyboard
shortcuts. Other mobile environments do not enable keyboard shortcuts, but
often increase keyboard navigation efficiency via recommending the use of
tabs and other organizational mechanisms.
Examples of Success Criterion A.3.1.3:
- In a desktop environment: A non-web-based
authoring tool provides keyboard shortcuts for its menu functions as well
as access keys in the design of its menus and dialog boxes. The choice of
shortcut keys follows platform conventions where applicable, for example
for open document, save document, cut, copy, paste, etc.
- In a mobile environment: A social
networking application on a mobile device has only a very few keyboard
shortcuts available on its targeted devices. These few keyboard shortcuts
are used for the most commonly accessed functions of the application (e.g.
home, list of friends).
- In a web-based environment: A web-based
CMS uses links to allow authors to skip between the toolbars and directly
to the content editing area.
Related
Resources for Success Criterion A.3.1.3:
- The following is a non-exhaustive list of keyboard shortcut conventions
for various platforms:
Implementing Success Criterion A.3.1.4 Keyboard
Access (Enhanced): All functionality of the authoring
tool is operable through a keyboard
interface without requiring specific timings for individual keystrokes.
(Level AAA)
Intent
of Success Criterion A.3.1.4 (Based on WCAG 2.0, Success Criterion 2.1.3):
The intent of this success criterion is to establish an enhanced requirement
for keyboard access at Level AAA, without any exceptions. While some "high-end"
drawing features, such as a "watercolor painting" tool that continuously
sampled the path, pressure and angle of a stylus would be very challenging to
make fully keyboard accessible, other less complex functions might be
practical.
Web-based authoring tools will already be required to meet this success
criterion as part of Success Criterion A.1.1.1.
Examples of Success Criterion A.3.1.4:
- Keyboard-driven "freehand" drawing: A
multimedia authoring tool has a mode that allows "freehand" lines to be
drawn in increments, letting authors use the keyboard to choose the angle
and length of the next increment, after which the shape is smoothed.
Related
Resources for Success Criterion A.3.1.4:
Implementing Success Criterion A.3.1.5 Customize
Keyboard Access: Keyboard access to the authoring
tool can be customized. (Level AAA)
Intent
of Success Criterion A.3.1.5:
The intent of this success criterion is to ensure that authors using a
keyboard interface have the ability to remap the authoring tool's keyboard
shortcuts in order to avoid keystroke conflicts, use familiar keystroke
combinations and optimize keyboard layout (e.g. for one-handed use).
Examples of Success Criterion A.3.1.5:
- Non-web-based authoring tool: A
non-web-based authoring tool has a keyboard setup utility that lists all of
the available keyboard shortcuts and allows authors to associate each
shortcut with any of the authoring tool's commands (e.g. all of the menu
commands).
- Web-based content management system: A
web-based content management system has a keyboard setup utility that
allows authors to change the access keys that are available during
authoring. These access key rebindings are for the authors' use only and do
not affect the web content being edited.
- Social networking application on a mobile device:
A social networking application has a keyboard setup utility that
allows authors to change their keyboard shortcuts for the site. The
remapping is saved in site cookies.
Related
Resources for Success Criterion A.3.1.5:
Implementing Success Criterion A.3.1.6 Present
Keyboard Commands: Authoring
tool user interface components can be presented
with any associated keyboard commands. (Level AAA)
Intent
of Success Criterion A.3.1.6:
The intent of this success criterion is to ensure that authors using a
keyboard interface have the ability to both discover and be reminded of
keyboard shortcuts, while they are using the authoring tool.
Examples of Success Criterion A.3.1.6:
- Non-web-based authoring tool: An
authoring tool on Windows includes a feature that allows authors to press a
modifier key (e.g. the "Alt" key) to display all of the keyboard shortcuts
in the current authoring tool user interface on top of the components to
which they relate.
Related
Resources for Success Criterion A.3.1.6:
Implementing Guideline A.3.2: (For the authoring tool
user interface) Provide authors with enough time. [Return
to Guideline]
Rationale: Some authors who have difficulty typing, operating
the mouse, or processing information can be prevented from using systems with
short time limits or that require fast reaction speeds, such as clicking on a
moving target.
Implementing Success Criterion A.3.2.1 Content Edits
Saved (Minimum): If the authoring tool includes authoring session time limits, then the authoring tool
saves all edits made by authors. (Level A)
Intent
of Success Criterion A.3.2.1:
The intent of this success criterion is to ensure that the work of authors
is saved in the event that an authoring session is ended due to a time limit
(e.g. the timeout of an authenticated authoring session). Reducing the
likelihood of lost content edits will benefit all authors, but especially
authors with disabilities who may take longer to accomplish authoring tasks.
For web-based authoring tools, this applies to any web content that has
already been submitted to the server by the user agent.
Examples of Success Criterion A.3.2.1:
- Save and continue: A web-based content
management system has a "Save and Continue" button that allows authors to
continually submit their content edits without requiring them to re-enter
the editing-view afterwards.
- Wiki: A wiki has an auto-save feature
that can be turned on by authors. The auto-save feature always saves before
a system timeout.
Related
Resources for Success Criterion A.3.2.1:
Implementing Success Criterion 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) (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.
Intent
of Success Criterion A.3.2.2 (Based on WCAG 2.0, Success Criterion 2.2.1):
The intent of this success criterion is to ensure that authoring tools
provide authors with disabilities adequate time to perform their tasks. Any
process that happens without author initiation after a set time or on a
periodic basis is a time limit. This includes partial or full updates of the
screen (for example, page refresh), or the expiration of a window of
opportunity for authors to react to a request for input. It also includes user
interface functionality that is advancing or updating at a rate beyond the
ability of authors to read and/or understand it. In other words, animated,
moving or scrolling information introduces a time limit.
Generally, turning off time limits is better than customizing the length of
time limits, which is better than requesting more time before a time limit
occurs. In some cases, however, it is not possible to change the time limit
(e.g. a collaborative authoring session) and exceptions are therefore provided
for those cases.
Web-based authoring tools will already be required to meet this success
criterion as part of a Success Criterion A.1.1.1.
Examples of Success Criterion A.3.2.2:
- Web-based content management system: A
web-based content management system has a login timeout function that
automatically logs authors out after 20 minutes of inactivity. One minute
before the automatic log out, the system notifies authors that they will be
logged out unless they cancel the notification, meeting (c). The system
also includes a preference setting that lets authors set the timing of the
notification up to 10 minutes before the automatic logout, meeting (b).
- Real-time collaborative editing system: A
real-time collaborative editing system allows multiple authors to edit the
same web content simultaneously. An integral part of the real-time
collaborative activity is that any author may edit or delete what others
have just authored, meeting (d).
Related
Resources for Success Criterion A.3.2.2:
Implementing Success Criterion A.3.2.3 Static Pointer
Targets: Authoring
tool user interface components that accept pointer
input are either stationary or authors can pause the movement. (Level A)
Intent
of Success Criterion A.3.2.3:
The intent of this success criterion is to ensure that authors are not
prevented from using the authoring tool by a requirement for fast reactions.
Examples of Success Criterion A.3.2.3:
- Timeline-based authoring tool: A
timeline-based interactive web content editor has an indicator of the
current position on the timeline that authors can click and drag. When the
interactive content is being previewed, the indicator moves along the
timeline, which can make it difficult to target with the mouse. Authors can
stop the indicator from moving by selecting the "Stop" or "Pause"
buttons.
Related
Resources for Success Criterion A.3.2.3:
Implementing Success Criterion A.3.2.4 Content Edits
Saved (Extended): The authoring tool can be set to
automatically save all content edits made by authors. (Level AAA)
Intent
of Success Criterion A.3.2.4:
The intent of this success criterion is to ensure that the work of authors
is saved in the event that an authoring session is ended due to a time limit.
Reducing the likelihood of lost content edits will benefit all authors, but
especially authors with disabilities who may take longer to accomplish
authoring tasks. Increasing the frequency with which content edits are saved
also helps authors recover more easily from inadvertent actions.
Examples of Success Criterion A.3.2.4:
- Web-based content management system: The
system includes an option to turn on asynchronous server communication to
constantly save authoring actions into a backup file. If the authoring
session ends unexpectedly, authors can retrieve backups during their next
authoring session.
Related
Resources for Success Criterion A.3.2.4:
Implementing Guideline A.3.3: (For the authoring tool
user interface) Help authors avoid flashing that could cause seizures. [Return
to Guideline]
Rationale: Flashing can cause seizures in authors with
photosensitive seizure disorder.
Implementing Success Criterion A.3.3.1 Static View
Option: Editing-views that render visual
time-based content can be paused and can be set to not play automatically.
(Level A)
Intent
of Success Criterion A.3.3.1:
The intent of this success criterion is to ensure that authors with
photosensitive seizure disorder can use the authoring tool to open visual
time-based web content (e.g. animations) without risk. Some people with seizure
disorders can have a seizure triggered by flashing visual content.
Examples of Success Criterion A.3.3.1:
- Blog: A blogging tool allows authors to
import video files. Authors have the option to turn off an auto-play
feature, so that the video files are not played until a "Play" button is
activated.
- WYSIWYG web page editor: A WYSIWYG
editing-view is capable of rendering JavaScript in real-time. Authors have
the option to turn off the real-time rendering feature, so that the
JavaScript is not rendered until a "Play" button is activated.
Related
Resources for Success Criterion A.3.3.1:
Implementing Guideline A.3.4: (For the authoring tool
user interface) Enhance navigation and editing via content structure. [Return
to Guideline]
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.
Implementing Success Criterion A.3.4.1 Navigate By
Structure: If editing-views expose the markup elements in
the web content being edited, then
the markup elements (e.g. source code, content renderings, etc.) are selectable
and navigation mechanisms are provided to move the selection focus between
elements. (Level AA)
Intent
of Success Criterion A.3.4.1:
The intent of this success criterion is to help authors using keyboard
interfaces to navigate more efficiently using the structure of the web content
being edited.
Examples of Success Criterion A.3.4.1:
- Source editing-view: A source
editing-view supports authors by providing the ability to use keyboard
shortcuts to select the current element (e.g. table row) and other keyboard
shortcuts to move the focus to:
- the element immediately above (e.g. table),
- the first element immediately below (e.g. table data cell),
- the element immediately preceding it at the same level (e.g. previous
table row), and
- the element immediately following it at the same level (e.g. next
table row).
- Search by headings: An authoring tool
includes a search function mode that enables authors to search forwards or
backwards by "any header element". For example, in HTML4 this would be
h1
...h6
. When a searched-for header element
exists, it is selected in the editing-view, enabling authors to immediately
edit the element.
- Search by element: An authoring tool
includes a search function mode that enables authors to search forwards or
backwards by the names of elements. When a searched-for element exists, it
is selected in the editing-view, enabling authors to immediately edit the
element. In addition, the search can be customized to search by attributes,
etc.
Figure: A "Find and Replace" dialog
box is shown configured to find the "element" with the name "img", "with
attribute" "height" "=" "100" (where each value in quotation marks is
editable). The replacement action is to "set attribute" "height" to "50".
The following checkbox options are available "match case", "ignore white
space" and "search text alternatives". The dialog box also includes the
following buttons "Find Next", "Find all", "Replace", "Replace All",
"Close" and "Help". (Source: mockup by AUWG)
- Outline view: An "outline" or "structure"
editing-view is provided that organizes structured element sets being
edited into a document tree. In this editing-view, only the arrow keys are
required for navigation between the parent, child and sibling elements.
- Customizing widgets: An authoring tool
enables authors to add and customize JavaScript widgets in its WYSIWYG
editing-view. Authors can use the keyboard to navigate through the elements
that make up the widget in order to set the properties or appearance of the
widget. For example, in a slider widget, the keyboard can be used to select
the background, the line, the line ticks or the thumb marker of the
slider.
- WYSIWYG web page editor: A WYSIWYG
editing-view allows authors to select and manipulate elements as objects.
When an element is selected, any content (including sub-elements) of the
element are also selected. When authors perform a function on a selected
element, the scope of the function and the resulting outcome depends on the
nature of the function.
- Some functions target the entire selection (i.e. the element, content
and sub-elements). For example, when a
<table>
element is selected and the "delete" operation is performed, the entire
table is deleted, including sub-elements (tr
and
td
) and any text content etc. within the table.
- Some functions only target the top level element of the selection.
For example, the "strip element tag" function deletes the markup of the
top level element without affecting its sub-elements or content.
- Some functions only target the content, including sub-elements of the
top level element of the selection without having any affect on the
markup of that top level element. For example, the “replace
contents” function is a variant of "paste" in which the sub-elements
and content of the selected element are replaced.
Related
Resources for Success Criterion A.3.4.1:
Implementing Success Criterion A.3.4.2 Navigate by
Programmatic Relationships: If editing-views
allow editing of programmatic relationships within web
content, then mechanisms are provided that support navigation between the
related content. Depending on the web content
technology and the nature of the authoring
tool, relationships may include, but are not limited to, element nesting,
headings, labeling, programmatic definitions, and ID relationships. (Level AAA)
Intent
of Success Criterion A.3.4.2:
The intent of this success criterion is to help authors using keyboard
interfaces to navigate more efficiently using the programmatic relationships
that may exist in many types of web content.
Examples of Success Criterion A.3.4.2:
- JavaScript editor: When a method is used,
authors can navigate directly to where that method is defined.
- HTML/CSS editor: When a style is used in
content being edited, authors can navigate directly to where that style is
defined, even if an external style sheet must be opened.
- HTML editor: When an ID is used in
content being edited, authors can navigate directly to where that ID is
defined.
- ARIA editor: Authors can navigate
directly via ARIA relationships, such as "aria-labeledby" and
"aria-describedby".
Related
Resources for Success Criterion A.3.4.2:
Implementing Guideline A.3.5: (For the authoring tool
user interface) Provide text search of the content. [Return
to Guideline]
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.
Implementing Success Criterion A.3.5.1 Text
Search: Authors can perform text searches of web
content that meet the following: (Level AA) (a) Search All Editable: Any information that is text
and that the authoring tool can modify is searchable,
including: text content, text alternatives for non-text
content, metadata, markup elements and attributes; and
Note: If the current editing-view is not able
to display the results of a search, then the authoring tool may provide a
mechanism to switch to a different editing-view to display the
results.(b) Two-way:
The search can be made forwards or backwards; and (c) Case Sensitive: The
search can be in both case sensitive and case insensitive modes; and
(d) No Match: Authors
are informed when no results are found.
Intent
of Success Criterion A.3.5.1:
The intent of this success criterion is to ensure that authors can
efficiently find the web content that they wish to edit.
The note under (a) acknowledges that not every editing-view is capable of
displaying every type of content that can be searched. For example, a WYSIWYG
editing-view may not be able to display search results within markup tags.
Examples of Success Criterion A.3.5.1:
- Basic text search: An authoring tool
provides both WYSIWYG and source editing-views. The authoring tool provides
two-way, case sensitive searching for plain text sequences within both
editing-views. The default search option is to search only within the
editing-view that the author is currently working within. However, there is
an option to search both editing-views simultaneously. When this option is
selected, the search results are all displayed in a selectable list that
labels each as "Text" or "Source Code", reflecting which editing-view will
become active when the author selects the search result.
- Advanced text search: An authoring tool's
basic text search feature is augmented by more advanced search options,
such as:
- replacement,
- wildcard characters,
- whole word matching,
- search repetition, and
- highlighting of all occurrences.
- Metadata editor: A metadata editor
provides two-way, case sensitive searching for plain text sequences within
textual metadata fields (e.g. title, description, author, etc.).
Related
Resources for Success Criterion A.3.5.1:
Implementing Guideline A.3.6: (For the authoring tool
user interface) Manage preference settings. [Return
to Guideline]
Rationale: Some authors need to set their own display settings in a way that differs
from the presentation that they want to define for
the published web content. Providing the ability to save
and reload sets of keyboard and display preference settings benefits authors who
have needs that differ over time (e.g. due to fatigue).
Implementing Success Criterion A.3.6.1 Independence
of Display: Authors can set their own display
settings for editing-views without affecting the web
content to be published. (Level A)
Intent
of Success Criterion A.3.6.1:
The intent of this success criterion is to ensure that the preference
display settings that authors set for their own use while they are editing web
content are independent of the display settings that are encoded (and
eventually published) in the content being edited.
When "WYSIWYG authoring tools" are referred to in the examples, it is with
the understanding that browsers will differ in rendering of the same content
and that end users are often free to override the default presentation of web
content.
Examples of Success Criterion A.3.6.1:
- Editing-view preferences: A
non-web-based WYSIWYG authoring tool has preference settings that enable
authors to override the default rendering styles used in the WYSIWYG
editing-view with the display settings that they have already set in the
operating system (e.g. large fonts, high contrast mode, etc.). The
preference settings have absolutely no effect on the web content being
edited.
- Setting an authoring style sheet: A
WYSIWYG authoring tool has preference settings that enable authors to set
an "authoring" style sheet. This style sheet is only used to control the
rendering of the web content in the author's editing-view. The stylesheet
does not make changes to the content markup being edited and is not
published to end users.
- Web-based authoring tool: A web-based
authoring tool lets authors customize the appearance of editing-views using
the preference display settings of the user agent. The user agent is cited
in any conformance claim.
Related
Resources for Success Criterion A.3.6.1:
Intent
of Success Criterion A.3.6.2:
The intent of this success criterion is to ensure that authors' preference
settings for keyboard and display settings do not need to be reset for each
authoring session.
Examples of Success Criterion A.3.6.2:
- Storing preferences with author account:
A web-based authoring tool requires that authors log in to their accounts
before authoring sessions can begin. Because preference settings are
associated with author accounts, the settings are applied as soon as
authors log in.
Related
Resources for Success Criterion A.3.6.2:
Implementing Success
Criterion A.3.6.3 Apply Platform Settings: The authoring tool applies platform display settings and control settings.
(Level AA)
Intent
of Success Criterion A.3.6.3:
The intent of this success criterion is to encourage authoring tools to
respect the display and control settings that authors have already specified at
the platform level. This reduces the need for authors to repeatedly specify the
same preferences. It also means that when authors first open the authoring
tool, they can more easily use the tool.
Examples of Success Criterion A.3.6.3:
- Desktop high contrast mode: A
non-web-based authoring tool defaults to high contrast mode when it detects
that the platform is set to high contrast mode.
- Web-based authoring tool: A web-based
authoring tool respects the display and control settings of the user agent
on which it is running.
Related
Resources for Success Criterion A.3.6.3:
Implementing Success Criterion A.3.6.4 Multiple
Sets: Authors can save and reload multiple sets of
any authoring tool display settings and control settings.
(Level AAA)
Intent
of Success Criterion A.3.6.4:
The intent of this success criterion is to ensure that authors whose
personal preferences vary over time (e.g. due to fatigue) can easily select
from a series of pre-set preferences for display and control settings.
Examples of Success Criterion A.3.6.4:
- Basic multiple profiles: An authoring
tool allows the various configurations of preference settings to be stored
as different profiles that authors can switch between at any time. The
stored preference settings include all display and control settings that
are specific to the authoring tool (i.e. are not controlled by the
platform).
- Portable profiles: An authoring tool's
basic multiple profiles feature is augmented by the ability for authors to
save the profiles as separate files. This allows authors to move
configurations between instances of the authoring tool on different systems
or to share the configuration files with other authors with similar
requirements.
Related
Resources for Success Criterion A.3.6.4:
Intent
of Success Criterion A.3.6.5:
The intent of this success criterion is to ensure that authoring tools
provide assistance to authors in configuring any options related to the
accessibility of the user interface. This assistance should include extra
assistance resolving any incompatibilities between options (e.g. prevent the
same color being used for both the foreground and background).
Examples of Success Criterion A.3.6.5:
- Options setting wizard: An authoring
tool includes a wizard that takes authors step-by-step through the
accessibility options, providing explanations and previews of how the
options will change the display. The wizard follows an interview format,
first asking authors about general areas (e.g. seeing the screen, using the
keyboard) and then becoming more detailed (e.g. text size, text color,
etc.).
Related
Resources for Success Criterion A.3.6.5:
Implementing Guideline A.3.7: (For the authoring tool
user interface) Ensure that previews are as accessible as existing user agents.
[Return
to Guideline]
Rationale: Preview features are provided in many authoring tools because the workflow
of authors often includes periodically checking how user
agents will display the web content to end users. Authors with
disabilities need the same opportunity to check their work.
Implementing Success Criterion A.3.7.1 Preview
(Minimum): If a preview is provided, then at least one of the
following is true: (Level A) (a)
Pre-existing User Agent: The preview makes use of a pre-existing user
agent; or (b) UAAG
(Level A): The preview conforms to the User Agent Accessibility
Guidelines Level A [UAAG].
Intent
of Success Criterion A.3.7.1:
The intent of this success criterion is to ensure that preview features
strike a balance between giving authors with disabilities an accessible means
of previewing the web content that they are editing and not giving those
authors an unrealistic impression of how end users with similar disabilities
will actually experience that content in their own user agents (e.g. browser,
video player, etc.). In other words, it is not necessarily useful to present a
user experience with content as a "preview" when it is much more accessible
than the actual end user experience of the content would be in a pre-existing
user agent.
There are two ways to meet this success criterion:
Option (a) is to implement preview features using user agents that are
already in use by end users, which is the most straightforward way to meet this
success criterion. This might be done in several ways, including by opening the
content in the author's default user agent or by making use of a user agent
widget nested within the authoring tool's own user interface. The user agent is
cited in any conformance claim.
Option (b) requires that if a preview is being developed that is already a
departure from existing user agents, then the W3C User Agent Accessibility
Guidelines (UAAG) must be followed. At the time of publication, UAAG version
1.0 is a W3C Recommendation and version 2.0 is under development.
Note: Developers may create a preview feature from scratch that
does not meet (b), as long as authors retain the option to preview using their
own user agent, since this meets (a).
Examples of Success Criterion A.3.7.1:
- Preview in a user agent: A web-based
authoring tool performs previews by opening the web content in a new user
agent tab or window, meeting (a).
- Preview in an external user agent: A
non-web-based authoring tool performs previews by opening the web content
to be previewed in the user's default browser, meeting (a).
- Preview in a user agent component: A
non-web-based authoring tool performs previews using a user agent component
that is built directly into the authoring tool, meeting (a).
- Custom built preview: An authoring tool
makes use of a custom built preview feature. The preview feature conforms
to User Agent Accessibility Guidelines (UAAG) 1.0 at Level "A", meeting
(b).
Related
Resources for Success Criterion A.3.7.1:
Implementing Success Criterion A.3.7.2 Preview
(Enhanced): If a preview is provided, then authors can specify which user
agent performs the preview. (Level AAA)
Intent
of Success Criterion A.3.7.2:
The intent of this success criterion is to provide an enhanced Level AAA
requirement for preview features, in which authors have the flexibility to
choose their preferred user agent for performing previews.
Examples of Success Criterion A.3.7.2:
- Non-web-based authoring tool: A
non-web-based authoring tool gives authors the option of choosing from any
of the user agents installed on their computer to perform the preview.
- Web-based authoring tool: A web-based
authoring tool provides authors with a URI that can be entered into another
user agent to perform the preview.
Related
Resources for Success Criterion A.3.7.2:
Implementing PRINCIPLE A.4: Editing-views must be
understandable
Implementing Guideline A.4.1: (For the authoring tool
user interface) Help authors avoid and correct mistakes. [Return
to Guideline]
Rationale: Some authors with disabilities may
be more susceptible to input errors due to factors such as difficulty making
fine movements and speech recognition system errors.
Implementing Success Criterion A.4.1.1 Content
Changes Reversible (Minimum): For authoring actions,
one of the following are true: (Level A)
Note 1: Reversing actions (e.g. an "undo" function) are also
considered authoring actions, meaning they must also meet this success
criterion (e.g. a "redo" function).
Note 2: It is acceptable to collect a series of text entry actions
(e.g. typed words, a series of backspaces) into a single reversible authoring
action.
Note 3: It is acceptable to clear the authoring action history at the
end of authoring sessions. (a) Reversible: The authoring action can be immediately
reversed; or (b) Warn
and Confirm: The authoring tool includes a warning to authors that
the action is irreversible and
requires authors to confirm the action before proceeding.
Intent
of Success Criterion A.4.1.1:
The intent of this success criterion is to help authors with disabilities
avoid serious consequences in the web content that they are editing as the
result of a mistake while performing authoring actions. Everyone makes
mistakes, but people with some disabilities have more difficulty creating
error-free input.
Note 1 makes it clear that "undo" functions, themselves, are authoring
actions that authors may need to undo.
Note 2 acknowledges that some implementations of "undo" may group text entry
actions.
Note 3 makes it clear that this success criterion does not require authoring
actions made in one authoring session to be reversible in subsequent authoring
sessions.
Examples of Success Criterion A.4.1.1:
- Non-web-based authoring tool: An
authoring tool has an "Undo" action under the "Edit" menu. Activating the
"Undo" action reverses the previous authoring action, meeting (a).
Activating "Undo" again undoes the previous authoring action and so on.
- Web-based content management system: A
web-based content management system supports two types of reversible
actions. Firstly, text entry actions into text fields can be reversed using
the "Undo" feature of the user agent. Secondly, "Cancel" buttons are
available within the web-based authoring tool user interface that allow
authors to reverse changes that have already been committed. However, to
avoid the "Cancel" button being pressed accidentally, authors have the
option of having confirmation dialogs displayed when "Cancel" is activated
(see Success Criterion A.4.1.3), meeting (a). The
user agent is cited in any conformance claim.
Related
Resources for Success Criterion A.4.1.1:
Implementing Success Criterion A.4.1.2 Setting
Changes Reversible: If actions modify authoring
tool settings, then one of the following are true: (Level A) (a) Reversible: The authoring
tool setting can be reversed by the same mechanism that made the change; or
(b) Warn and
Confirm: The authoring tool includes a warning to authors that
the action is irreversible and
requires authors to confirm the action or save the current settings before
proceeding.
Intent
of Success Criterion A.4.1.2:
The intent of this success criterion is to help authors with disabilities
avoid making the authoring tool unusable to them as the result of making a
mistake while installing the program or modifying preference settings. Everyone
makes mistakes, but people with some disabilities have more difficulty creating
error-free input. In addition, it may be harder for some people with
disabilities to detect that they have made an error.
Examples of Success Criterion A.4.1.2:
- Cancel: On each preference settings page
are two options, OK and Cancel. Canceling prevents the setting changes from
being applied, meeting (a).
- All reversible: All of the preference
setting changes in an authoring tool can be reversed by revisiting the
preference setting utility and adjusting the settings, meeting (a).
- Restore defaults: In a preference setting
utility, a "restore default settings" button is always available, meeting
(a).
Related
Resources for Success Criterion A.4.1.2:
Implementing Success Criterion A.4.1.3 Content
Changes Reversible (Enhanced): Authors can sequentially
reverse a series of reversible authoring actions. (Level AAA)
Note: The notes for A.4.1.1 still apply.
Intent
of Success Criterion A.4.1.3:
The intent of this success criterion is to establish an enhanced Level AAA
requirement for reversing inadvertent actions that modify the content being
edited. Everyone makes mistakes, but some people with some disabilities have
more difficulty creating error-free input. In addition, it may be harder for
some people with disabilities to detect and rectify errors, so it is more
likely that they will benefit from the ability to reverse a series of actions
once an error is discovered.
The note is a reminder that the three notes from Success
Criterion A.4.1.1 also apply.
Examples of Success Criterion A.4.1.3:
- Undo queue: An authoring tool saves
author actions in a "last-in-last-out" queue.
Related
Resources for Success Criterion A.4.1.3:
Implementing Guideline A.4.2: (For the authoring tool
user interface) Document the user interface including all accessibility
features. [Return
to Guideline]
Rationale: Some authors may not be able to
understand or operate the authoring
tool user interface without proper accessible documentation.
Implementing Success Criterion A.4.2.1 Document
Accessibility Features: All features that must be present to meet Part A of ATAG 2.0 (e.g. keyboard shortcuts, text search,
etc.) are documented. (Level A)
Note: The accessibility of the documentation is covered by Guideline A.1.1 and Guideline
A.1.2.
Intent
of Success Criterion A.4.2.1:
The intent of this success criterion is to ensure that authors with
disabilities that need to use the accessibility features of the authoring tool
user interface can easily find specific instruction in the documentation.
The note is a reminder that the accessibility of the documentation is
covered by Guideline A.1.1 and Guideline A.1.2.
Examples of Success Criterion A.4.2.1:
- Accessibility features documented: An
authoring tool includes a help system that is always available to authors,
is searchable by keyword and is also linked in context from the various
features within the authoring tool. The documentation conforms to WCAG 2.0
Level A and includes the following topics grouped together into an
"Accessibility Features" chapter in the help system:
- how to customize display settings
- what keyboard shortcuts are available, including navigation keys
- how to customize keyboard shortcuts
- how to avoid keyboard traps in content
- how to extend time limits
- how to use the search features
- how to undo/redo
- how to set accessibility-related options, such as turning off
auto-play
Related
Resources for Success Criterion A.4.2.1:
Implementing Success Criterion A.4.2.2 Document All
Features: All features of the authoring
tool are documented. (Level AA)
Note: The accessibility of the documentation is covered by Guideline A.1.1 and Guideline
A.1.2.
Intent
of Success Criterion A.4.2.2:
The intent of this success criterion is to ensure that authors who need
additional support to learn to operate an authoring tool can easily access
instructions.
The note is a reminder that the accessibility of the documentation is
covered by Guideline A.1.1 and Guideline A.1.2.
Examples of Success Criterion A.4.2.2:
- All features documented: An authoring
tool includes documentation for all of its available features. The
documentation conforms to WCAG 2.0 Level A.
Related
Resources for Success Criterion A.4.2.2:
Implementing
PART B: Support the production of accessible content
Part B Conformance Applicability Notes:
- Author availability: Any Part B success criteria
that refer to authors only apply during authoring sessions.
- Developer control: The Part B
success criteria only apply to the authoring
tool as it is provided by the developer. This does not
include subsequent modifications by parties other than the authoring tool
developer (e.g. by plug-ins, user-defined templates, user modifications of
default settings, etc.).
- Applicability after the end of an authoring
session: Authoring tools are responsible for
the accessibility of web content that they automatically generate after the end of an
author's authoring session (see Success Criterion
B.1.1.1). For example, if the developer changes the site-wide templates of a content management system, these would
be required to meet the accessibility requirements for
automatically-generated content. Authoring tools are not responsible for
changes to the accessibility of content that the author has specified,
whether it is author-generated or
automatically-generated by another system that the author has specified
(e.g. a third-party feed).
- Authoring systems: As per the ATAG
2.0 definition of authoring tool, several software
tools (identified in any conformance claim) can
be used in conjunction to meet the requirements of Part B (e.g. an
authoring tool could make use of a third-party software accessibility
checking tool).
- Features for meeting Part B must be
accessible: The Part A success criteria
apply to the entire authoring
tool user interface, including any features that must be present to
meet the success criteria in Part B (e.g. checking tools, repair tools,
tutorials, documentation, etc.).
- Multiple author roles: Some authoring tools include multiple author
roles, each with different views and content editing permissions (e.g. a content management system may
separate the roles of designers, content authors, and quality assurers). In
these cases, the Part B success criteria apply to the authoring tool as a
whole, not to the view provided to any particular author role. Accessible content
support features should be made available to any author role where it
would be useful.
Implementing PRINCIPLE B.1: Fully automatic processes
must produce accessible content
Implementing Guideline B.1.1: Ensure automatically
specified content is accessible. [Return
to Guideline]
Rationale: If authoring
tools automatically specify web
content that is not accessible, then additional repair
tasks are imposed on authors.
Implementing Success Criterion B.1.1.1 Content
Auto-Generation After Authoring Sessions (WCAG): Authors have the default option that, when web
content is automatically generated for publishing after the end of an authoring session, it is accessible web content
(WCAG).
Note: This success criterion applies only to automatic processes
specified by the authoring tool developer. It
does not apply when author
actions prevent generation of accessible web content.
The WCAG 2.0 Level A success criteria are met (Level
A); or
The WCAG 2.0 Level A and Level AA success criteria are met (Level AA); or
The WCAG 2.0 Level A, Level AA, and Level AAA success criteria are met (Level
AAA).
Intent
of Success Criterion B.1.1.1:
The intent of this success criterion is to ensure that when authoring tools
have been designed to generate web content that is published directly to end
users without an opportunity for author action, the default option should be
for that web content to be accessible.
The note acknowledges that there are automatic behaviors that may be
specified by other parties, and that author actions may purposefully or
inadvertently affect the accessibility of the content generated later.
WCAG 2.0 is referenced because it provides
testable success criteria to measure web content accessibility.
Examples of Success Criterion B.1.1.1:
- Email archive: An automatic email
archiving system automatically creates web pages from each email message
that it receives. It has been designed to generate accessible markup, but
if email messages contain accessibility problems, the archiving system is
not able to rectify them.
- Social networking application: A social
networking application collects some limited information from authors (e.g.
name, gender, status updates, etc.) which it uses to personalize an
automatically generated web application that meets the requirements of
WCAG.
Related
Resources for Success Criterion B.1.1.1:
Implementing Success Criterion B.1.1.2 Content
Auto-Generation During Authoring Sessions (WCAG): Authors have
the default option that, when web
content is automatically generated during an authoring session, then one of the following is true:
Note 1: Automatic generation includes automatically selecting
templates for authors.
Note 2: This success criterion applies only to automatic processes
specified by the authoring tool developer. It
does not apply when author
actions prevent generation of accessible web content.
(a) Accessible: The
content is accessible web content (WCAG)
without author input; or (b) Prompting: During the automatic generation process,
authors are prompted for any required accessibility information
(WCAG); or (c)
Automatic Checking: After the automatic generation process,
accessibility checking is automatically performed; or (d) Checking Suggested: After
the automatic generation process, the authoring tool prompts authors to perform
accessibility checking. The WCAG 2.0 Level A
success criteria are met (Level A); or
The WCAG 2.0 Level A and Level AA success criteria are met (Level AA); or
The WCAG 2.0 Level A, Level AA, and Level AAA success criteria are met (Level
AAA).
Intent
of Success Criterion B.1.1.2:
The intent of this success criterion is to provide more flexible guidance
when authors are available to assist in ensuring the accessibility of content,
while also recognizing that authors often will not be able to assist if they
are not made aware that web content accessibility problems do or may exist.
Note 1 highlights the fact that when an authoring tool automatically selects
a template for the author to use, the authoring tool is considered to be
auto-generating the content in the template.
Note 2 acknowledges that there are many ways in which the automatic behavior
of authoring tools can be modified that are not under the control of the
developer.
There are four ways to meet this success criterion:
Option (a) is the most straightforward. It requires the authoring tool to
generate only accessible content.
Option (b) takes into account that even more access-aware authoring tools
may need to query the author regarding issues that require human judgment, such
as whether alternative text is suited to the context.
Option (c) takes into account that prompting during the generation process
may be contrary to the workflow. Instead, the authoring tool can run a checker
on the output.
Option (d) is similar to (c) but takes into account that ATAG 2.0 allows the
option of manual checking.
WCAG 2.0 is referenced because it provides
testable success criteria to measure web content accessibility.
Examples of Success Criterion B.1.1.2:
- Markup behind WYSIWYG: A WYSIWYG web page
authoring tool provides authors with a toolbar of options for formatting
text. Following the WYSIWYG (what-you-see-is-what-you-get) paradigm, the
options are labeled with the visual result (e.g. a bold "B" to represent
bold, an italicized "I" to represent italics, etc.) of performing the
action however, the content that is automatically generated from those
actions actually conforms to WCAG 2.0 (e.g.
using
strong
for bold and em
for emphasis),
meeting (a).
- Automatic generation with author input:
An online photo album allows authors to upload images and then
automatically generates content to display the images. Since the album
application is not able to automatically generate alternative content for
the images that meets WCAG 2.0, authors are
prompted for this information, meeting (b).
- Automatic accessibility checking: An
authoring tool allows images, videos and other multimedia files to be
dragged into documents. When this happens, markup is automatically
generated that contains accessibility problems. However, the authoring tool
includes an "as-you-type" accessibility checker that unobtrusively
highlights the problems for author attention, meeting (c).
- Manual accessibility checking: An
authoring tool allows images, videos and other multimedia files to be
dragged into documents. When this happens, markup is automatically
generated that contains accessibility problems. Since the authoring tool
includes a manual checking wizard instead of an automatic checker, a
message appears in a status area of the user interface stating that the
author should use the wizard before publishing, meeting (d).
- Documentation: An authoring tool that
employs automatic content generation documents the accessibility of this
functionality with reference to particular WCAG
2.0 techniques.
Related
Resources for Success Criterion B.1.1.2:
Implementing Guideline B.1.2: Ensure accessibility
information is preserved. [Return
to Guideline]
Rationale: Accessibility information is
critical to maintaining comparable levels of accessibility between the input
and output of web content transformations.
Implementing Success Criterion B.1.2.1 Restructuring
and Recoding Transformations (WCAG): If the authoring
tool provides restructuring
transformations or re-coding transformations,
then at least one of the following is true:
Note: This success criteria only applies to transformations in which
the output technology is an "included" technology for conformance.(a) Preserve: Accessibility information
(WCAG) is preserved in the output; or (b) Warning: Authors have the
default option to be warned that accessibility information may be lost (e.g.
when saving a vector graphic into a raster image format); or (c) Automatic Checking: After
the transformation, accessibility checking is automatically performed; or
(d) Checking
Suggested: After the transformation, the authoring tool prompts
authors to perform accessibility checking. The WCAG 2.0 Level A success criteria are met (Level A);
or
The WCAG 2.0 Level A and Level AA success criteria are met (Level AA); or
The WCAG 2.0 Level A, Level AA, and Level AAA success criteria are met (Level
AAA).
Intent
of Success Criterion B.1.2.1:
The intent of this success criterion is to encourage authoring tools to
preserve accessibility information during restructuring or recoding
transformations and to ensure authors are made aware when the authoring tool is
unable to preserve accessibility information. This may occur when the output
format does not support the same accessibility features as the input format
(i.e. the example of a vector graphic being saved as a raster image format) or
when an authoring tool has not implemented the necessary data mapping. There is
no negative connotation intended here. In some cases, the number of source
technology possibilities is simply too large to ensure complete mappings are in
place for all of them.
The options available partially mirror the options for Success Criterion B.1.1.2, reflecting the similarities
between automatic generation and restructuring/re-coding web content
transformations:
Option (a) is the most straightforward. It requires the authoring tool to
preserve accessibility information during transformations.
Option (b) is to warn the author directly that accessibility information may
be lost, allowing them to decide whether or not to proceed.
Option (c) takes into account that prompting during the transformation
process may be contrary to the workflow. Instead, the authoring tool can run a
checker on the output.
Option (d) is similar to (c) but takes into account that ATAG 2.0 allows the
option of manual checking.
See Also: ATAG 2.0 identifies other types of transformations in which the
expectation for preserving accessibility information is higher. These are
optimizing transformations (Success Criterion B.1.2.2)
and transformations in which non-text content is preserved (Success Criterion B.1.2.3).
WCAG 2.0 is referenced because it provides
testable success criteria to measure web content accessibility.
Examples of Success Criterion B.1.2.1:
- Similar data structures: A "Save As"
feature preserves accessibility information in similar data structures,
meeting (a). For example:
- when converting between HTML and SVG, the contents of
alt
attributes are stored in desc
attributes
- when saving a word-processor format to markup, headings and list
items are transformed into appropriate structural markup
- Dissimilar but accessible: A "Save As"
feature preserves accessibility information in a dissimilar, but accessible
way, when similar data structures are not available, meeting (a). For
example:
- when transforming a SMIL presentation with a closed-caption text
track into a video-only format, authors have the option of converting
the closed captions into open-captions encoded in the video file
- when transforming a table to a list, table headings are transformed
into headings and summary or caption information is retained as
rendered text content
- when saving a word-processing format to markup, specialized document
features (i.e. footnotes, endnotes, call-outs, annotations, references,
etc.) are retained as rendered text content with two-way linking.
- Warning when text is converted to graphics):
A "Save As" feature includes the ability to convert textual
formats into graphics. However, if this option is selected by authors, they
are warned that the output will have web content accessibility problems.
They are also advised that style sheets are preferable for presentation
control. If authors continue, there is a suggestion to retain the original
text as alternative content for the graphical output, meeting (b).
- Option to cancel: A markup editor has a
feature that automatically removes any attributes or elements that do not
appear in the defined DTD when content is opened for editing. Upon
activation, the feature notifies authors that content will be deleted with
unknown effects for end users. The author has the option to cancel the
operation, in which case the content will not be opened for editing,
meeting (b).
- Automatic accessibility checking: An
authoring tool allows content to be copy-and-pasted from other
applications, including office applications, user agents, etc. When this
happens, the source content is recoded into the technology of the current
document. While accessibility was considered in the design of the feature,
web content accessibility problems may still occur. However, the authoring
tool includes an "as-you-type" accessibility checker, meeting (c).
- Manual accessibility checking: An
authoring tool allows content to be copy-and-pasted from other
applications, including office applications, user agents, etc. When this
happens, the source content is recoded into the technology of the current
document. While accessibility was considered in the design of the feature,
web content accessibility problems may still occur. Since the authoring
tool includes a manual checking wizard instead of an automatic checker, a
message appears in a status area of the user interface stating that the
author should use the wizard before publishing, meeting (d).
Related
Resources for Success Criterion B.1.2.1:
Intent
of Success Criterion B.1.2.2:
The intent of this success criterion is to ensure that web content
transformations intended only to optimize content do not result in the
introduction of web content accessibility problems.
Examples of Success Criterion B.1.2.2:
- Pretty-print: A "pretty-print" tool
reformats markup code to make it easier to read by programmers. The tool
never makes changes to the markup tags.
- Video compression: A tool that compresses
video does not automatically delete text tracks or secondary audio tracks,
since these may contain accessibility information.
Related
Resources for Success Criterion B.1.2.2:
Intent
of Success Criterion B.1.2.3:
The intent of this success criterion is to increase the likelihood that text
alternatives will be preserved by web content transformations. This is
especially important because text alternatives, such as labels and long
descriptions, can represent substantial investments of author effort.
Examples of Success Criterion B.1.2.3:
- Save as HTML: A word processor includes a
"Save as Simple HTML" feature that re-codes word processor files into HTML
where there is a one-to-one correspondence between elements. As a result,
some word processor-specific content is lost (e.g. change tracking,
footnotes). However, because of the existence of the <img> tag in
HTML, images are preserved and, in order to meet this success criterion,
the text alternatives associated with the image are also preserved in
HTML.
Related
Resources for Success Criterion B.1.2.3:
Implementing PRINCIPLE B.2: Authors must be supported
in producing accessible content
Implementing Guideline B.2.1: Ensure accessible
content production is possible. [Return
to Guideline]
Rationale: For the purposes of this
document, WCAG 2.0 defines the accessible web content (WCAG)
requirements. To support accessible web content production, at minimum, it must
be possible to produce web content that conforms with WCAG 2.0 using the authoring
tool.
Implementing Success Criterion B.2.1.1 Accessible
Content Possible (WCAG): If the authoring
tool places restrictions on the
web
content that authors can specify, then those restrictions do not prevent
WCAG 2.0 success
criteria from being met: The WCAG 2.0 Level A
success criteria can be met (Level A); or
The WCAG 2.0 Level A and Level AA success criteria can be met (Level AA); or
The WCAG 2.0 Level A, Level AA, and Level AAA success criteria can be met
(Level AAA).
Intent
of Success Criterion B.2.1.1:
The intent of this success criterion is to ensure that authors who have the
motivation and knowledge to create accessible web content using an authoring
tool are not prevented from doing so by restrictions in the actions that the
authoring tool allows them to perform. The subsequent success criteria in Part
B will build on this minimal requirement.
Note that the term "restricted" is not intended to have any negative
connotation. Authoring tools usually restrict web content authoring in order to
simplify the production of content that is in fact complex and technical. The
accessibility implications of the restrictions may be positive or negative and
need to be considered case by case:
Examples of unrestricted authoring:
- source code editor: authors can type whatever they like (e.g.
<img src="..." alt="..." longdesc="..." />
)
- WYSIWYG editor for HTML4: the "Insert Image" dialog includes all of the
HTML4 attributes for
<img>
Examples of restricted authoring that does not prevent WCAG 2.0 success
criteria from being met:
- WYSIWYG editor for HTML4: the "Insert Image" dialog includes just some of
the HTML4 attributes for
<img>
, but "alt" and "longdesc"
are included in the subset.
- CMS: authors can only add images that they have previously uploaded to
their "Asset Manager". While alt-text and long description do not appear as
options when they choose images from the "Asset Manager" to include on a
page, they can add/edit these values at any time within the "Asset
Manager".
Examples of restricted authoring that prevents WCAG 2.0 success criteria
from being met:
- WYSIWYG editor for HTML4: the "Insert Image" dialog has only one field
"src". There is no possible way to add other attribute values, including
for the "alt" and "longdesc" attributes.
- CMS: to be saved, each page of content must have a main title, but when
the author provides text for the title it is marked up with presentation
markup rather than appropriate header markup.
See Also: Unrestricted authoring tools entail less author guidance and
therefore may allow the introduction of more accessibility problems than
authoring tools with restrictions that encourage accessibility. ATAG 2.0
addresses this issue with other success criteria, including B.3.1.1 Checking Assistance (WCAG), which requires an
accessibility checking feature.
See Also: Restrictions on authors may also be related to automatically
generated content. ATAG 2.0 addresses the accessibility of automatically
generated content in Guideline B.1.1: Ensure automatically
specified content is accessible.
WCAG 2.0 is referenced because it provides
testable success criteria to measure web content accessibility.
Examples of Success Criterion B.2.1.1:
- Accessible workflow exists: An authoring
tool is designed such that accessible web content (in this case to WCAG 2.0 Level A) will result if authors do all
of the following:
- turn on all features that support the production of accessible
content; and
- correctly follow all prompts by features that support the production
of accessible content; and
- uses the accessibility checker, including a final check prior to
publishing; and
- correctly perform any manual checks suggested by the accessibility
checker; and
- correctly repair all of the automatically, semi-automatically or
manually identified web content accessibility problems using the
automated, semi-automated and manual repair assistance that the
authoring tool provides.
- Source content editing-view: An authoring
tool is designed around a source editing-view, allowing motivated and
knowledgeable authors to control every detail of the content produced,
including following accessible authoring practices.
Related
Resources for Success Criterion B.2.1.1:
Implementing Guideline B.2.2: Guide authors to
produce accessible content. [Return
to Guideline]
Rationale: By guiding authors from the outset
toward the creation and maintenance of accessible web content (WCAG) ,
web
content accessibility problems (WCAG) are mitigated and less repair
effort is required.
Implementing Success Criterion B.2.2.1 Accessible
Option Prominence (WCAG): If authors are provided with a
choice of authoring actions for achieving the
same authoring outcome (e.g. styling text), then options that
will result in accessible web content (WCAG) are at least as prominent as options
that will not. (Level A) The WCAG 2.0 Level A
success criteria are met (Level A); or
The WCAG 2.0 Level A and Level AA success criteria are met (Level AA); or
The WCAG 2.0 Level A, Level AA, and Level AAA success criteria are met (Level
AAA).
Intent
of Success Criterion B.2.2.1:
The intent of this success criterion is to help ensure that accessible
authoring practices are part of the default workflow of authoring tools. This
requirement applies when the authoring outcome is predictable by the authoring
tool. For example, a generic "insert table" command would not be applicable,
despite the fact that an author might misuse it for layout, because the author
might be seeking the outcome of adding tabular information. In contrast, a page
layout editor is covered by the requirement because the purpose of the feature
is to edit the page layout.
WCAG 2.0 is referenced because it provides
testable success criteria to measure web content accessibility.
Examples of Success Criterion B.2.2.1:
- Structural Markup: A WYSIWYG HTML editor
does not include any authoring action options that will necessarily result
in web content that will not meet the WCAG 2.0
Level A success criteria. For example:
- a toolbar button that allows text to be marked as bold does so by
adding a
<strong>
element rather than a
<span>
element with a bold style.
- a the toolbar button for placing text into a bulleted list does so
with list markup (
<ul>
and <li>
elements) rather than a <span>
element-based
implementation.
- a page layout view makes use of CSS positioning rather than table
markup.
- De-emphasizing problematic options: A
WYSIWYG editing-view emphasizes more accessible choices with a higher
position in the menus and a position in user interface shortcuts, such as
toolbars. Choices that always lead to less accessible web content are
de-emphasized with lower menu positions.
Figure: An authoring tool that
supports two methods for setting text color: using CSS and using
font
. Since using CSS is the more accessible option, it is
given a higher prominence within the authoring interface by: (1) the "CSS
Styling" option appearing above the "FONT Styling" option in the drop down
Text menu, and (2) the CSS styling option being used to implement the
one-click text color formatting button in the tool bar. The association is
made clear because the toolbar button has the same icon (an "A" beside a
color spectrum) as the "Color" sub-menu item under the "CSS Styling" menu
option.). (Source: mockup by AUWG)
Related
Resources for Success Criterion B.2.2.1:
Implementing Success Criterion B.2.2.2 Setting
Accessibility Properties (WCAG): If the authoring tool provides
mechanisms to set web content properties (e.g.
attribute values, etc.), then mechanisms are also provided to set web content
properties related to accessibility information
(WCAG):
Note: Success Criterion B.4.1.4 addresses the
prominence of the mechanisms. The WCAG 2.0 Level A
success criteria are met (Level A); or
The WCAG 2.0 Level A and Level AA success criteria are met (Level AA); or
The WCAG 2.0 Level A, Level AA, and Level AAA success criteria are met (Level
AAA).
Intent
of Success Criterion B.2.2.2:
The intent of this success criterion is to ensure that if authoring tools
provide authors with content authoring support that goes beyond source editing
(e.g. property dialogs, etc.) then accessibility information that is required
for the content are similarly supported. In many cases, authoring tools support
a subset of all of the possible properties that technologies might offer. This
success criterion requires that the subset of supported properties must include
properties required for conformance to WCAG
2.0.
The note is a reminder that the mechanisms for adding accessibility
information properties must have prominence that is at least comparable with
the other mechanisms for other properties.
Examples of Success Criterion B.2.2.2:
- Context sensitive properties: A markup
authoring tool includes a context sensitive properties pane that displays
property fields for the most common subset of attributes associated with
the markup element that currently has focus in the editing-view. The
attributes that are required for WCAG 2.0 are
included in the subset.
Figure: An "Image Properties" dialog
box in which the input fields are ordered (from top to bottom, left to
right): source ("src"), short label ("alt"), long description ("longdesc"),
height, and width. The buttons at the bottom are "More...", "OK" and
"Cancel". (Source: mockup by AUWG)
- Time-based media alternatives: A SMIL
authoring tool lets authors create multimedia presentations by pulling
together video, audio and timed text objects on to a timeline, even though
the tool has no built-in ability to edit these objects. When authors
specify information about video to be inserted, they are also provided with
the opportunity to associate a timed text object (for captions), an audio
object (for audio description), and a secondary video (for sign language
interpretation). When authors specify information about audio to be
inserted, they are also provided with the opportunity to associate a timed
text object (for captions) and a video (for sign language
interpretation).
- Data table for a bar graph: A learning
content management system has a feature that lets authors insert figures.
The feature accepts images, even though the authoring tool has no built-in
ability to edit images, but as part of the "figure properties" the authors
can identify the figure as a graph. If they choose this option, then the
system assists them in creating an accompanying data table using the values
used to create the graph.
Related
Resources for Success Criterion B.2.2.2:
Implementing Success Criterion B.2.2.3 Technology
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 support for the production of accessible
content, then both of the following are true: (Level A)
(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.
Intent
of Success Criterion B.2.2.3:
The intent of this success criterion is to inform authors as early as
possible about the degree to which the authoring tool will be able to provide
accessible web content production support for the web content technologies that
it is capable of producing. If accessibility is part of early decision-making,
it will reduce the likelihood that retrofits for accessibility will be required
later on.
The success criterion makes no judgment or assumption about the
accessibility of web content technologies. Instead, it is assumed that any
technology can be made accessible if used properly. For example, a technology
with no intrinsic accessibility features can be made accessible in conjunction
with another technology (e.g. bitmap images may be made more accessible via
HTML text labels).
Instead, the success criterion depends on whether the authoring tool in
question actually supports the production of accessible content in the
technology through features such as checking and repair or does not. The choice
of which technologies to provide accessible content production support for is
left completely to the developer (e.g. a developer might decide to begin by
adding support to a less-popular technology because a major customer has
requested it).
The wording "provides the option of producing" is intended to rule out
situations in which authors make technology choices without guidance by the
authoring tool (e.g. by hand coding, by specifying a DTD).
The wording "for publishing" is intended to rule out situations in which
incomplete content is created in interim formats that are not intended for
publishing.
Requirement (a) is that there be a warning before authors have progressed
too far with a technology option lacking support for the production of
accessible content in the authoring tool. The warning may appear before authors
make a selection or after.
Requirement (b) is simply to inform the user, who has now just received a
warning that the authoring tool lacks accessibility support for a given
technology, that one or more other web content technologies produced by the
authoring tool are supported by such accessibility support features. The list
may be a partial or complete list of the technologies for which support for the
production of accessible content is provided. In either case, it is left to
authors, to decide whether any of the listed technologies might be appropriate
for the task or whether they will continue on with their original selection.
Examples of Success Criterion B.2.2.3:
- Choosing video formats: A video authoring
tool allows authors to save into several video file formats. However, the
authoring tool includes a built-in closed-caption editor that only works
with one of the file formats. While there is nothing intrinsically
"inaccessible" about any of these three video formats, when the option to
save is presented, the formats that are not supported by the authoring
tool's own closed-caption editor include warnings that caption support is
not provided. In the warning's explanation, the video format that is
supported by the closed-caption editor is identified.
Related
Resources for Success Criterion B.2.2.3:
Implementing Guideline B.2.3: Assist authors with
managing alternative content for non-text content. [Return
to Guideline]
Rationale: Improperly generated alternative content can create accessibility
problems and interfere with accessibility checking.
See Also: This guideline applies when non-text
content is specified by authors (e.g. inserts an image). When non-text content is
automatically added by the authoring
tool, see Guideline B.1.1.
Implementing Success Criterion B.2.3.1 Alternative
Content is Editable (WCAG): Authors are able to modify programmatically
associated text alternatives for non-text
content. (Level A).
The WCAG 2.0 Level A success criteria are met (Level A); or
The WCAG 2.0 Level A and Level AA success criteria are met (Level AA); or
The WCAG 2.0 Level A, Level AA, and Level AAA success criteria are met (Level
AAA).
Intent
of Success Criterion B.2.3.1:
The intent of this success criterion is to ensure that authors can add
alternative content for non-text content and modify that alternative content in
the future.
If the type of alternative content (e.g. alternative text) is not typically
displayed on screen by user agents, then WYSIWYG editing-views may not display
it. This is acceptable as long as another mechanism is provided for modifying
that alternative content (e.g. an "Image Properties" dialog).
Examples of Success Criterion B.2.3.1:
- Source content editing-view: In a source
editing-view, alternative content within the source is always available,
regardless of what user agents might render. If alternative content is
referenced from an external location (e.g. HTML4
longdesc
),
then that resource can be opened for editing.
- Properties dialog: In a WYSIWYG
editing-view, alternative content is not displayed, since the editing-view
is designed to mimic typical user agents. However, the alternative content
can be accessed and edited via a properties editor that displays the
properties for the content that currently has focus.
Related
Resources for Success Criterion B.2.3.1:
Implementing Success Criterion B.2.3.2 Conditions on
Automated Suggestions: During the authoring session,
the authoring tool may only automatically
suggest programmatically
associated text alternatives for non-text
content under the following conditions: (Level A) (a) Author Control: Authors have
the opportunity to accept, modify, or reject the suggested text alternatives
prior to insertion; and (b) Relevant Sources: The suggested text alternatives
are 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).
Intent
of Success Criterion B.2.3.2:
The intent of this success criterion is to prevent the production of
alternative content that is not useful to an end user because it has not been
approved by an author and/or it is derived from unreliable sources.
The requirement of author control (a) enables knowledgeable authors to have
the final say on alternative content suggested by authoring tools.
The limitation to relevant sources (b) is intended to reduce the possibility
that authors who are unfamiliar with accessibility may approve alternative
content suggestions without realizing the problems these can cause for end
users.
Examples of Success Criterion B.2.3.2:
- Metadata on an archive: A content
management system includes a feature that allows authors to make use of
images from an extensive photographic archive. The photographic archive
includes metadata for each photograph with title and description fields.
The title field is always filled, but the description field is sometimes
lacking. When authors select an image for insertion, the metadata title is
suggested as the alternative text label and the metadata description (if
any) is suggested as the long description. In both cases, some basic
guidance on what constitutes correct alternative content is provided to
help authors judge the appropriateness of the suggestions. The authors are
still given the opportunity to accept, modify, or reject the suggested
alternative content prior to insertion, in case the non-text content is
being used in a different context.
- Alternative content registry: A web page
authoring tool implements an alternative content registry (see also Success Criterion B.2.3.4). Since the alternative
content was gathered from authors' previous entries into the same fields
for the same objects, these are acceptable as relevant sources. The authors
are still given the opportunity to accept, modify, or reject the suggested
alternative content prior to insertion, in case the non-text content is
being used in a different context.
- Accepting patterns: An authoring tool
allows authors to accept patterns of future uses of an alternative content
under certain conditions (e.g. whenever the same non-text content is marked
with the same semantic role).
Related
Resources for Success Criterion B.2.3.2:
Intent
of Success Criterion B.2.3.3:
The intent of this success criterion is to address situations in which
authors have either not noticed or ignored opportunities for adding alternative
content and have ended their authoring sessions. ATAG 2.0 does not require
authoring tools to attempt automated repairs in this situation because doing so
risks misleading accessibility checking tools and end users into the assumption
that the alternative content was either provided or approved by an author.
However, if developers do want to provide automated assistance to end users,
then this success criterion specifies what types of repairs may be provided.
Essentially:
- Basic "text" processing repairs using information that is equally
available to user agents (e.g. file name, text metadata within non-text
objects, the title of a linked resource, etc.) are not allowed, because
they are best performed by user agents and assistive technologies.
- Repairs are allowed when authoring tools have contextual information
(e.g. the image is the author's profile picture) that user agents do not
have equal access to.
- Repairs are also allowed that go beyond simple text processing to
directly processing images, audio or video. The intent here is to encourage
progress in these rapidly advancing fields.
Examples of Success Criterion B.2.3.3:
- Contextual information is known: A social
networking authoring tool allows authors to add a description of their
profile picture. If an author chooses not to provide a description, the
authoring tool labels the image as the author's profile picture.
- Contextual information is not known: A
web page authoring tool allows authors to insert images. If an author
ignores opportunities to add alternative content and then ends the
authoring session, the authoring tool has access to information such as the
file name of the image, but since this is text information that is equally
available to user agents, it is not suggested.
- Auto-generated transcript: An on-line
video editing and hosting authoring tool has a feature that allows authors
to create transcripts or captions for their videos. Authors can begin by
copying in a transcript if one is available or the authoring tool can use
voice recognition technology to generate a transcript for the authors to
correct. While this is preferred, the authoring tool also has a setting in
which it will automatically add the auto-generated transcript to the
published presentation if the end user requests this and the author has not
made an attempt to add their own captions or transcript.
Related
Resources for Success Criterion B.2.3.3:
Implementing Success Criterion B.2.3.4 Save for
Reuse: When authors enter programmatically
associated text alternatives for non-text
content, both of the following are true: (Level AAA) (a) Save and Suggest: the
text alternatives are automatically saved and suggested by the authoring tool, if the same non-text
content is reused; and (b) Edit Option: the author has the option to edit or delete the
saved text alternatives.
Intent
of Success Criterion B.2.3.4:
The intent of this success criterion is to ensure that when authors spend
effort providing alternative content, this content is retained by the authoring
tool in a form that allows it to be easily reused.
The editing requirement (b) allows authors to correct or remove alternatives
that are outdated or that contain spelling errors, etc...
Examples of Success Criterion B.2.3.4:
- Alternative content registry: An
authoring tool includes a registry that associates object identity
information with alternative content (i.e. text, URIs). Whenever an object
is used and any alternative content is collected, the object's identifying
information and the alternative content is added to the registry. The
stored alternative content is suggested as alternative content for author
approval whenever the associated object is inserted. The alternative
content registry allows several different versions of alternative content
to be associated with a single object (e.g. various translations, various
contexts).
Figure: The interface of a sample
alternative content registry viewer is shown. The design takes into account
multiple non-text content objects of the same name, multiple types of text
equivalents for each non-text content object, and multiple versions of each
text equivalent type. In the viewer shown here, the author has selected
"image" as the "media type" and then selected pic123.gif as the "content"
to edit. This has brought up a rendering of the "earthrise" image. The
viewer also shows that the content has three text labels. The author has
selected one ("An earth rise as seen from the moon") in order to edit it.
In addition some authoring tips are included ("Alternate text should be 10
words or less and should include any text in the image", "Image buttons
should have alternate text that describes the button function.", and "Image
bullets should have "bullet" as alternate text."(Source: mockup by AUWG)
- Interoperability with pre-authored
content: An enterprise authoring tool's clip art system is
integrated with an alternative content registry so that new alternative
content created by any author on the enterprise system is stored along with
the pre-authored alternative content for the images in the system. The
keyword search feature of the clip art system makes use of any alternative
content to retrieve matches.
Related
Resources for Success Criterion B.2.3.4:
Implementing Guideline B.2.4: Assist authors with
accessible templates. [Return
to Guideline]
Rationale: Providing accessible
templates and other pre-authored content (e.g. clip art, synchronized
media, widgets, etc.) can have several benefits, including: immediately
improving the accessibility of web content being
edited, reducing the effort required of authors, and demonstrating
the importance of accessible web content (WCAG)
.
Implementing Success Criterion B.2.4.1 Accessible
Template Options (WCAG): If the authoring
tool provides templates, then there are accessible template options for a range of
template uses. (Level A)
Intent
of Success Criterion B.2.4.1:
The intent of this success criterion is to reduce the possibility that
authors will be forced to use inaccessible templates to create web content
because accessible templates do not exist.
Examples of Success Criterion B.2.4.1:
- Variety of accessible templates: A web
page authoring tool provides several template choices for home pages, guest
books and on-line albums. For each type of functionality, the basic
template option is accessible.
- Content management system: A content
management system offers a variety of templates to authors for different
purposes (e.g. information page, interactive form page, registration page,
etc.). All of the templates have passed WCAG
2.0 Level A accessibility evaluations when filled in with sample
content by authors who follow all of the instructions provided.
Related
Resources for Success Criterion B.2.4.1:
Implementing Success Criterion B.2.4.2 Template
Selection Mechanism: If authors are provided with a template
selection mechanism, then both of the following are true: (Level AA) (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.
Intent
of Success Criterion B.2.4.2:
The intent of this success criterion is to ensure that authors can easily
determine the accessibility status of templates prior to selecting them and to
increase the likelihood that authors will notice the accessible template
options.
Note: The term "accessibility status" is used, rather than "WCAG 2.0
conformance", for the sake of flexibility. This means that the status values
are not required to include the term "WCAG" explicitly.
Examples of Success Criterion B.2.4.2:
- Accessibility status as metadata: An HTML
editor includes a template selection mechanism that consists of a list of
selectable items. The template list has several sortable fields that are
populated from the templates' metadata: the template name, date, popularity
and accessibility status. The accessibility status values are: "Level A",
"Level AA", "Level AAA", "None" and "Not Available". By default, the list
of templates is sorted alphabetically, but the author has the option to
sort by accessibility status instead. The accessibility status values of
the developer-provided templates are based on the degree to which WCAG 2.0 success criteria are met when the
template is used (see definition of "accessible template (WCAG)"). This may
have been assessed manually or semi-automatically with an accessibility
checker.
- Accessibility status included in template
names/descriptions: In a wiki system, creating a new page brings
up a list of available templates. Each template is only displayed as a name
and a short description. When the developer has ensured the accessibility
of a template, this is indicated by the template name (e.g. "slide show
template (accessible)") and/or information in the description ("This
template meets WCAG 2.0 Level A as provided and should result in an
accessible page, if accessible authoring practices are followed.").
Related
Resources for Success Criterion B.2.4.2:
Implementing Success Criterion B.2.4.3 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)
Intent
of Success Criterion B.2.4.3:
The intent of this success criterion is to ensure that new templates that
authors create and which might be used by subsequent authors interoperate with
the relevant template selection mechanism (See Success
Criterion B.2.4.2).
Examples of Success Criterion B.2.4.3:
- Save as template: An authoring tool
provides a "save as template" feature. When authors activate this feature,
the authoring tool automatically runs an accessibility checker on the
template with sample data. Once the checker returns a resulting
accessibility status, authors have the option of labeling the template with
this status. If the template fails to conform to WCAG 2.0 with sample data, then authors are
advised that templates should be held to a high accessibility standard,
since they will be repeatedly reused.
Related
Resources for Success Criterion B.2.4.3:
Implementing Success Criterion B.2.4.4 Template
Accessibility Status: If the authoring
tool provides a repository of templates, then each of the
templates has a recorded accessibility status. (Level AAA)
Intent
of Success Criterion B.2.4.4:
The intent of this success criterion is to ensure that all templates that
the authoring tool provides include an accessibility status, which might be
used by a template selection mechanism (See Success
Criterion B.2.4.2). This is not a requirement that all templates meet any
particular accessibility level.
Examples of Success Criterion B.2.4.4:
- Template repository: A web page authoring
tool provides several template choices for home pages, guest books and
on-line albums. All of the templates are labeled with an accessibility
level (i.e. conforming to WCAG 2.0 Level A,
Level AA or Level AAA when used as directed).
Related
Resources for Success Criterion B.2.4.4:
Implementing Guideline B.2.5: Assist authors with
accessible pre-authored content. [Return
to Guideline]
Rationale: Providing accessible templates and other
pre-authored content (e.g. clip art, synchronized media, widgets, etc.) can
have several benefits, including: immediately improving the accessibility of web content being
edited, reducing the effort required of authors, and demonstrating
the importance of accessible web content
(WCAG).
Implementing Success Criterion B.2.5.1 Pre-Authored
Content Selection Mechanism: If authors are provided with a
selection mechanism for pre-authored content other than templates (e.g. clip art
gallery, widget repository, design themes), then both of the following are
true: (Level AA) (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.
Intent
of Success Criterion B.2.5.1:
The intent of this success criterion is to ensure that authors can easily
determine the accessibility status of pre-authored content prior to selecting
them and that authors are more likely to notice the accessible pre-authored
content options.
Examples of Success Criterion B.2.5.1:
- Sort by accessibility status: A clip-art
repository lists the available images and provides the alternative text
associated with the images in a sortable field.
Related
Resources for Success Criterion B.2.5.1:
Implementing Success Criterion B.2.5.2 Pre-Authored
Content Accessibility Status: If the authoring
tool provides a repository of pre-authored content, then each of the
content objects has a recorded accessibility status. (Level AAA)
Intent
of Success Criterion B.2.5.2:
The intent of this success criterion is to ensure that all pre-authored
content that the authoring tool provides include an accessibility status, which
might be used by a pre-authored content selection mechanism (See Success Criterion B.2.4.2). This is not a requirement that
all pre-authored content meet any particular accessibility level.
Examples of Success Criterion B.2.5.2:
- Clip art collection: An authoring tool is
shipped with a clip art collection. Each image in the collection has a
short text label and long text description and the system is interoperable
with the alternative content registry, so that whenever authors insert an
image from the clip art collection, its alternative content is
automatically retrieved.
Related
Resources for Success Criterion B.2.5.2:
Implementing PRINCIPLE B.3: Authors must be supported
in improving the accessibility of existing content
Implementing Guideline B.3.1: Assist authors in
checking for accessibility problems. [Return
to Guideline]
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.
Implementing Success Criterion B.3.1.1 Checking
Assistance (WCAG): If the authoring
tool provides authors with the ability to add or modify web
content so that a WCAG 2.0 success criterion
can be violated, then accessibility checking for that success
criterion is provided (e.g. an HTML authoring tool that inserts images should
check for alternative text; a video authoring tool with the ability to edit text tracks
should check for captions).
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. The WCAG 2.0 Level A success criteria are met (Level A);
or
The WCAG 2.0 Level A and Level AA success criteria are met (Level AA); or
The WCAG 2.0 Level A, Level AA, and Level AAA success criteria are met (Level
AAA).
Intent
of Success Criterion B.3.1.1:
The intent of this success criterion is to ensure that authors are supported
in discovering web content accessibility problems in the content that they are
editing. This is critical if these issues are to be addressed prior to
publishing. The requirement to individually check WCAG
2.0 success criteria is intended to prevent manual checks from being worded
in excessively general ways (e.g. "does the page meet all of the
requirements?").
The success criterion does not specify how multiple instances of the same
problem should be handled, because this will usually depend on the nature of
the problem and the degree of automation in the checking and repair features of
the authoring tool. Some problems are limited to one or just a few elements and
lend themselves to automated or semi-automated reporting of each instance (e.g.
missing labels), while other problems extend across many elements and are
sometimes best checked globally (e.g. reading level, etc.).
The note about manual checking acknowledges that the current state of
technology does not allow every web content accessibility problem to be
identified automatically.
WCAG 2.0 is referenced because it provides
testable success criteria to measure web content accessibility.
Examples of Success Criterion B.3.1.1:
- Markup processing checker: An
accessibility checking tool includes automated checking for web content
accessibility problems that can be detected from markup alone. The tool
includes semi-automated checking where potential instances can be detected
from the markup, but where the author's assessment of the content is
required to make a final decision. In cases where markup processing is of
little or no use in detecting problems, manual instructions are included
for authors to follow in identifying whether the relevant WCAG 2.0 success criterion has been met.
- Content processing checker: An
accessibility checking tool goes beyond markup processing by applying
content processing heuristics, such as:
- Image processing to detect whether foreground and background contrast
levels are sufficient or whether images are blank.
- Text processing to calculate reading levels and detect changes in
human language.
Related
Resources for Success Criterion B.3.1.1:
Implementing Success Criterion B.3.1.2 Help Authors
Decide: For checks that require authors to decide whether a potential web
content accessibility problem is correctly identified (i.e. manual checking and semi-automated
checking), instructions are provided from the check that describe how to
make the decision. (Level A)
Intent
of Success Criterion B.3.1.2:
The intent of this success criterion is to ensure that authors, who in many
cases will lack accessibility knowledge, will be able to make adequate
judgments. If this is not the case, authors may miss web content accessibility
problems that do exist and/or mistakenly identify problems that do not exist.
Examples of Success Criterion B.3.1.2:
- Questions answered: Instructions are
formulated to answer the questions: "What part of the content should be
examined?" and "What is present or absent that is causing the
problem?".
- Variety of views: When author judgment
would be enhanced by modified views of the web content being edited, an
accessibility browser toolbar is used to provide various previews, such as:
- an alternative content view (with images and other multimedia
replaced by any alternative content)
- a monochrome view (to test contrast)
- a text to speech view (to test the availability of text alternatives)
- no scripts view
- no frames view
- no style sheet view
- Judgments saved: An authoring tool saves
author judgments for manual checks and only prompts for new judgments after
authors have made substantial changes.
Related
Resources for Success Criterion B.3.1.2:
Implementing Success Criterion B.3.1.3 Help Authors
Locate: For checks that require authors to decide whether a potential web
content accessibility problem is correctly identified (i.e. manual checking and semi-automated
checking), the relevant content is identified to the authors.
(Level A)
Note: Depending on the nature of the editing-view and
the scope of the potential web content accessibility problem, identification
might involve highlighting elements or renderings of elements, displaying line
numbers, or providing instructions.
Intent
of Success Criterion B.3.1.3:
The intent of this success criterion is to increase the accuracy of author
judgments by identifying the location of suspected web content accessibility
problems as precisely as possible.
The note acknowledges that there are many ways that this success criterion
may be met.
Examples of Success Criterion B.3.1.3:
- By line number: An authoring tool
displays potential problems in a separate list by the line number of the
first element involved.
- Underlining: A source editing-view
displays potential problems in-line by underlining all of the markup for
the affected span of elements.
- Outlining: A WYSIWYG editing-view
displays potential problems in-line with the rendered content as blue
outlining around the affected span of elements.
- Site-wide checking: A web site management
software is designed to identify issues on a site-wide scale (e.g. broken
links, outdated information). The software also includes a feature to
detect site-wide accessibility problems. The feature is able to identify
faulty templates, widgets, etc. that can cause systematic problems.
Related
Resources for Success Criterion B.3.1.3:
Implementing Success Criterion B.3.1.4 Status
Report: Authors can receive an accessibility status report based on
the results of the accessibility checks. (Level AA)
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.
Intent
of Success Criterion B.3.1.4:
The intent of this success criterion is to ensure that authors are able to
obtain an overview of the accessibility status of their web content. This
information has many uses, including the assessment of repair options, progress
monitoring and performance reporting.
The note highlights that no particular format is required, since this will
depend on the nature of the authoring tool and its checking feature.
Examples of Success Criterion B.3.1.4:
- List of accessibility problems: A
step-by-step checking feature provides a single consolidated list of all of
the web content accessibility problems that were detected. Direct links are
provided to additional help and repair assistance for each type of
accessibility problem.
- Conformance level report: A
check-as-you-type checking feature highlights accessibility problems that
can be automatically detected directly within a WYSIWYG editing-view. The
author controls the strictness of the automatic checking from a preferences
screen, where they select the target WCAG 2.0 level. The overall status of
accessibility checking is available on the application status bar, which
lists the target WCAG 2.0 level and the number of outstanding problems that
can be automatically detected. A link to the remaining manual checks is
also provided.
Related
Resources for Success Criterion B.3.1.4:
Implementing Success Criterion B.3.1.5 Metadata Production: Authors have the option of
associating accessibility checking results with the web content as
metadata. (Level AA)
Note: The metadata format that is implemented will dictate the nature
of the associated results (e.g. specific check results, summary conformance
claims, etc.)
Intent
of Success Criterion B.3.1.5:
The intent of this success criterion is to facilitate the creation of
accessibility metadata, which can have multiple uses, benefiting both authors
(e.g. by enabling interoperability between various checking and repair tools)
and end users (e.g. by enabling accessible resource discovery).
The note highlights that no particular format is required. Various metadata
options exist and they differ in the nature of the information they encode. The
metadata choice will depend on the intended use of the metadata. While this
success criterion does not require the use of a particular accessibility
metadata format, accessible resource discovery is facilitated by formats that
include specific checking results as opposed to formats that only include
summary conformance information. The reason for this is that individual end
users who are seeking accessible content, may have preferences for certain
types of accessibility information (e.g. captions), but not for others (e.g.
audio descriptions). This level of detail can be extracted from specific
checking results, but not from summary conformance claims.
Examples of Success Criterion B.3.1.5:
- Saving EARL: An authoring tool includes
an automated/semi-automated accessibility checker, but only manual repair
guidance. In order to give authors additional repair options, the checker
includes the option of storing the listing of web content accessibility
problems using the Evaluation and Repair Language (EARL). This allows the
author to use an external automated/semi-automated repair service.
- Saving AccessForAll: A learning content
management system (LCMS) is implemented with a personalized approach to
accessibility. Instead of every version of every web content resource being
fully conformant (e.g. every video including captions), several versions of
each web content resource are produced (e.g. one with captions and one
without) and AccessForAll metadata is associated with each. Then when an
end user attempts to access a web content resource, their personal
preferences are used by the LCMS to locate and serve out the version of the
web content resource that is appropriate to that end user's
preferences.
- Accessibility of legacy web content: A
content management system includes the ability to inventory issues within
legacy web content. Running automated checking on legacy web content and
storing the results in metadata, provides decision-makers with potentially
useful information.
Related
Resources for Success Criterion B.3.1.5:
Implementing Guideline B.3.2: Assist authors in
repairing accessibility problems. [Return
to Guideline]
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.
Implementing Success Criterion B.3.2.1 Repair
Assistance (WCAG): If checking (see Success Criterion B.3.1.1) can detect that a WCAG 2.0 success criterion is not met, then repair
suggestion(s) are provided:
Note: Automatedand
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. The WCAG 2.0 Level A success criteria are met (Level A);
or
The WCAG 2.0 Level A and Level AA success criteria are met (Level AA); or
The WCAG 2.0 Level A, Level AA, and Level AAA success criteria are met (Level
AAA).
Intent
of Success Criterion B.3.2.1:
The intent of this success criterion is to ensure that authors are aided in
repairing content accessibility problems that are detectable via the authoring
tools own checking system.
The note allows manual repair assistance to meet this success criterion in
order to acknowledge the difficulty of automatically or semi-automatically
repairing certain types of accessibility problems.
WCAG 2.0 is referenced because it provides
testable success criteria to measure web content accessibility.
Examples of Success Criterion B.3.2.1:
- Check-as-you-type: An authoring tool
includes a check-as-you-type feature that provides context sensitive
repair.
Figure: A WYSIWYG editing-view is
shown, in which a table is being edited. The first row of the table is
highlighted in blue "squiggly" lines because a checking heuristic has
detected that it might actually be a header row. The author has right
clicked on the outlined area and a pop-up menu gives them several repair
options: "Repair: Set as header row", "Skip", "Ignore", "Check
Accessibility..." and "Help...".
- Combined check-repair feature: A WYSIWYG
web page authoring tool includes an accessibility check and repair feature
that presents web content accessibility problems and repair options in a
sequential manner analogous to a typical spelling or grammar checking
"wizard". Each screen provides input field(s) for the information required
to address the issue as well as additional information and tips that
authors may require in order to properly provide the requested information.
Figure: A correction interface is
shown for repairing missing alternate text label for an image. The
interface includes (1) a short description of the problem (here: "Missing
Alternate Text Label for an Image"), (2) a preview (here: the "earthrise"
image that is missing a label), (3) tips for performing the repair (here:
"Alternate text should be 10 words or less and should include any text in
the image."; "Image buttons should have alternate text that describes the
button function."; and "Image bullets should have "bullet" as alternate
text."), and (4) an offered semi-automated repair in an editable drop-down
box (here: "An earth rise as seen from the moon"). The global checker
controls include a progress indicator ("5 of 25") and navigation buttons to
move backwards ("back") and forwards ("skip") through the list of repair
tasks. Buttons to "repair", get "help" and "cancel" are also provided.
(Source: mockup by AUWG)
- Manual repair instructions: For each
potential accessibility problem identified by the checking function (as
required by Success Criterion B.3.1.1),
documentation with repair instructions is provided that authors (with
sufficient skill and knowledge to use the rest of the tool) could follow to
correct the problem.
Related
Resources for Success Criterion B.2.3.1:
Implementing PRINCIPLE B.4: Authoring tools must
promote and integrate their accessibility features
Implementing Guideline B.4.1: Ensure the availability
of features that support the production of accessible content. [Return
to Guideline]
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.
Implementing Success Criterion B.4.1.1 Features
Active by Default: All accessible content support
features are turned on by default. (Level A)
Intent
of Success Criterion B.4.1.1:
The intent of this success criterion is to help ensure that the accessible
content support features are perceived by authors (and developers) as a natural
and expected part of the authoring tool workflow, just as features for
addressing spelling, grammar and syntax errors already are.
Examples of Success Criterion B.4.1.1:
- On by default: A web page authoring tool
has all accessible content support features turned on by default within the
"Accessibility" tab of its preferences area.
Figure: The preference setting area
of an authoring tool, open to an "Accessibility" section, shows the default
settings. "W3C-WCAG" and a level (e.g. "Double-A") are selected as are the
following options: "Check accessibility as you type", "Check accessibility
after saving", "Auto-correct when possible", "Highlight accessibility
related fields", "Prompt when highlighted fields are left blank", and
"Provide accessibility 'Quick Tips'". (Source: mockup by AUWG)
Related
Resources for Success Criterion B.4.1.1:
Implementing Success Criterion B.4.1.2 Option to
Reactivate Features: If authors can turn off an accessible content support
feature, then they can turn the feature back on. (Level A)
Intent
of Success Criterion B.4.1.2:
The intent of this success criterion is to ensure that if authors turn off
accessible content support features for any reason, they can easily turn them
back on.
Examples of Success Criterion B.4.1.2:
- Toggle in preferences area: A web page
authoring tool provides an "Accessibility" tab in its preferences area
where any deactivated features can be reactivated.
- Reminders: An authoring tool has a
"wizard"-style accessibility checker and a "check-as-you-type"-style
accessibility checker. If the "check-as-you-type"-style checker has been
turned off, then authors are reminded about the feature and provided with
an option to turn it back on whenever they run the "wizard"-style checker.
Related
Resources for Success Criterion B.4.1.2:
Intent
of Success Criterion B.4.1.3:
The intent of this success criterion is to ensure that if authors attempt to
turn off an accessible content support feature for any reason, they will have
the opportunity to understand the effect this will have on the accessibility of
the web content that they produce.
Examples of Success Criterion B.4.1.3:
- Warning: An authoring tool provides
authors with a warning whenever an accessible content support feature is
turned off (e.g. from the authoring tool preferences area.
Figure: In an authoring tool, the
author has unchecked a "highlighting accessibility related fields" feature
the tool. As a result the tool displays a warning that reads "You have just
turned off the highlighting accessibility related fields feature. This
feature is designed to inform you when information must be provided in
order for your documents to comply with your target accessibility setting.
Turning this feature off could cause your documents to be less accessible
to many users. In some jurisdictions accessibility is a legal requirement.
Are you sure you want to proceed?". The author has the option to answer
"Yes", "No" or "Cancel". (Source: mockup by AUWG)
Related
Resources for Success Criterion B.4.1.3:
Implementing Success Criterion B.4.1.4 Feature
Prominence: 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)
Intent
of Success Criterion B.4.1.4:
The intent of this success criterion is to help ensure that authors are as
likely to notice and use functions for addressing accessibility problems as
functions for addressing other web content issues (e.g. invalid markup, syntax
errors, spelling and grammar errors).
Examples of Success Criterion B.4.1.4:
- Prominence of checking and repair: An
authoring tool includes a pane dedicated to content "Evaluation and
Repair". The pane lists accessibility, grammar, link checking, spelling,
and syntax validation. When the various utilities are run, their results
are displayed in similar ways within the pane.
- Prominence of documentation: An authoring
tool includes documentation of its accessibility checker as part of the
main documentation of an authoring tool, with very similar prominence to
that of the spelling-related features.
Figure: A help system is shown. In
the right pane is the documentation table of contents, where "Accessibility
Features" appears as a top level topic just below "Spelling Features". In
the left panel is the help text, demonstrating a style typical of the rest
of the help system: "Checking for Accessibility: A variety of accessibility
checking options are available: Accessibility verifier, Check accessibility
as you type, Manual test support materials. These are suitable for use at
different times during the authoring process and all have options that can
be changed with the accessibility preferences. To get more information on
accessible web content, see the References.". (Source: mockup by AUWG)
- Check-as-you-type: An authoring tool
continuously checks the web content being edited and highlights problems as
the authors work.
Figure: A WYSIWYG authoring tool is
shown with check-as-you-type accessibility checking activated. Two elements
on the page have been highlighted as having problems: an image is
surrounded by a blue squiggly line and a line of text is underlined by the
same style of blue squiggly line. (Source: mockup by AUWG)
- Checking on demand: An authoring tool
provides accessibility checking from a menu item that is always available.
- Prompt to check before publishing: An
authoring tool automatically performs an accessibility check if authors
choose a publishing option and informs authors of the results.
Related
Resources for Success Criterion B.4.1.4:
Implementing Guideline B.4.2: Ensure that
documentation promotes the production of accessible content. [Return
to Guideline]
Rationale: Without documentation
of the features that support
the production of accessible content (e.g. prompts for text alternatives,
accessibility checking tools), some authors may not be able to use them.
Demonstrating accessible authoring as routine practice will encourage its
acceptance by some authors.
Implementing Success Criterion B.4.2.1 Model Practice
(WCAG): A range of examples in the documentation
(e.g. markup, screen shots of WYSIWYG editing-views) demonstrate accessible authoring
practices that meet the WCAG 2.0 success
criteria: The WCAG 2.0 Level A success criteria are
met (Level A); or
The WCAG 2.0 Level A and Level AA success criteria are met (Level AA); or
The WCAG 2.0 Level A, Level AA, and Level AAA success criteria are met (Level
AAA).
Intent
of Success Criterion B.4.2.1:
The intent of this success criterion is to introduce accessible authoring
practices as a naturally integrated common practice. The range of examples
might include markup fragments, screen shots of WYSIWYG editing-views, sample
code or sample applications.
WCAG 2.0 is referenced because it provides
testable success criteria to measure web content accessibility.
Examples of Success Criterion B.4.2.1:
- Reference examples are accessible: An
HTML authoring tool includes an on-line HTML reference guide. Most of the
examples provided in the reference guide conform to WCAG 2.0 Level A.
- Screen shots show accessibility features in
use: A content management system has a help system that includes
screen shots of various screens. When screen shots show examples of the
user interfaces while content being produced, the user interface is always
such that the content produced would conforms WCAG
2.0 Level A (e.g. prompts filled in, optional accessibility features
turned on, etc.).
Related
Resources for Success Criterion B.4.2.1:
Implementing Success Criterion B.4.2.2 Feature
Instructions: Instructions for using the accessible content
support features appear in the documentation. (Level A)
Intent
of Success Criterion B.4.2.2:
The intent of this success criterion is to help ensure that authors are able
to find help on how to use the accessible content support features effectively.
Examples of Success Criterion B.4.2.2:
- Documentation of accessible content support
features: An authoring tool's help system documents the accessible
content support features as it would other features of the authoring tool.
Since the authoring tool includes context-sensitive help, this is also
provided for the accessible content support features.
- Short and long versions of help: During
prompting and repairs, an authoring tool provides authors with immediate
access to some basic accessibility documentation and one-step access to
more comprehensive documentation.
Figure: An accessibility checker
includes some limited tips for authoring short text labels listed beneath
the text entry area as well as a "Help" button linking to the full
documentation. The tips are: "Alternate text should be 10 words or less and
should include any text in the image.", "Image buttons should have
alternate text that describes the button function.", and "Image bullets
should have 'bullet' as alternate text.". The screen shot also includes the
name of the problem ("Missing Alternate Text Label for an Image"), a field
for adding the short text label and a preview rendering of the image
("earthrise"). At the bottom are five buttons: "Help", "< Back",
"Repair", "Skip", and "Cancel". (Source: mockup by AUWG)
Related
Resources for Success Criterion B.4.2.2:
Implementing Success Criterion B.4.2.3 Tutorial:
A tutorial on an accessible authoring process that is
specific to the authoring tool is provided. (Level AAA)
Intent
of Success Criterion B.4.2.3:
The intent of this success criterion is to ensure that authors that learn
best through tutorials are exposed to accessibility best practices specific to
the authoring tool.
Examples of Success Criterion B.4.2.3:
- Accessibility tutorial: A web page
authoring tool includes built-in tutorials demonstrating several multi-step
tasks (e.g. setting up the folders and files for the local version of a
website, formatting with CSS, etc.). One of the tutorials describes how to
use the accessible content support features of the authoring tool to
increase the accessibility of the web content produced. The tutorial begins
at the typical starting point for the tool (e.g. empty document). The
tutorial also covers when and how checking and repair should be performed.
The tutorial includes some basic rationales for accessible content
production. These rationales emphasize the importance of accessibility for
a wide range of content consumers, from those with disabilities to those
with alternative viewers (see "Auxiliary Benefits of
Accessibility Features", a W3C-WAI resource).
Related
Resources for Success Criterion B.4.2.3:
Implementing Success Criterion B.4.2.4 Instruction
Index: The documentation contains an index to the
instructions for using the accessible content
support features. (Level AAA)
Intent
of Success Criterion B.4.2.4:
The intent is to help authors discover instructions related to features
provided to support the authoring of accessible web content.
Examples of Success Criterion B.4.2.4:
- Help chapter: An authoring tool includes
documentation of its accessible content support features (needed to meet Success Criterion B.4.2.2). This documentation appears
in a chapter of the documentation on accessibility. The documentation is
also available via other mechanisms, including context sensitive help from
the features themselves and from a help search function.
- Help index: An authoring tool includes
documentation of its accessible content support features (needed to meet Success Criterion B.4.2.2). This documentation is
spread throughout the other documentation topics as applicable. In
addition, there is a help topic on accessible authoring that includes links
to the various pieces of distributed documentation. The documentation is
also available via other mechanisms, including context sensitive help from
the features themselves and from a help search function.
Related
Resources for Success Criterion B.4.2.4:
Implementing ATAG 2.0 Conformance
This section is included here for informative purposes. The normative version appears in the Authoring
Tool Accessibility Guidelines 2.0 [ATAG20].
Conformance means that the authoring tool satisfies the applicable success criteria defined in the guidelines section. This conformance section describes
conformance and lists the conformance requirements.
Relationship to the Web
Content Accessibility Guidelines (WCAG) 2.0
Because WCAG 2.0 [WCAG20] is the most
recent W3C Recommendation regarding web content accessibility, ATAG 2.0
frequently refers to WCAG 2.0 in order to set requirements for (1) the
accessibility of web-based
authoring tool user interfaces (in Part A) and (2)
how authors should be enabled, supported, and guided toward
producing web content that is accessible to end
users with disabilities (in Part B).
Whenever success criteria or defined terms in ATAG 2.0 depend on WCAG 2.0,
they are marked with "(WCAG)".
Note on "accessibility-supported
ways of using technologies":
Part of conformance to WCAG 2.0 is the requirement that "only
accessibility-supported ways of using technologies are relied upon to satisfy
the WCAG 2.0 success criteria. Any information or functionality that is
provided in a way that is not accessibility supported is also available in a
way that is accessibility supported." In broad terms, WCAG 2.0
considers a web content
technology to be "accessibility supported" when (1) the way that the web
content technology is used is supported by users' assistive technology and (2) the
web content technology has accessibility-supported user agents that are
available to end users.
This concept is not easily extended to authoring
tools because many authoring tools can be installed and used in a variety
of environments with differing availabilities for assistive technologies and
user agents (e.g. private intranets versus public websites, monolingual sites
versus multilingual sites, etc.). Therefore:
ATAG 2.0 does not include the accessibility-supported requirement.
As a result, ATAG 2.0 success criteria do not refer to WCAG 2.0
"conformance", but instead refer to "meeting WCAG 2.0 success
criteria".
Once an authoring tool has been installed and put into use, it would be
possible to assess the WCAG 2.0 conformance of the web content that
the authoring tool produces, including whether the WCAG 2.0
accessibility-supported requirement is met. However, this WCAG 2.0 conformance
assessment would be completely independent of the authoring tool's conformance
with ATAG 2.0.
Applicability of Success
Criteria
The ATAG 2.0 definition of authoring tool
is inclusive and, as such, it covers software with a wide range of capabilities
and contexts of operation. In order to take into account authoring
tools with limited feature sets (e.g. a photo editor, a CSS editor, a
status update field in a social networking application, etc.), many of the ATAG
2.0 success criteria are conditional, applying only to authoring tools with the
given features(s) (e.g. Success Criterion B.1.1.1 applies only to authoring
tools that automatically generate web content after
the end of
authoring sessions).
If a conformance claim is made, a declaration that
a success criterion is not applicable requires a rationale.
Conformance Requirements
In order for an authoring tool to conform to ATAG 2.0,
all of the following conformance requirements must be satisfied:
Conformance Levels:
Authoring tools may conform "fully" or
"partially" to ATAG 2.0. In either case, the level of conformance depends on
the level of the success criteria that have been satisfied.
"Full" ATAG 2.0 Conformance: This type of conformance is
intended to be used when developers have considered
the accessibility of the authoring tools from both the perspective of authors (Part A: Make the authoring tool user interface accessible)
and the perspective of end users of web content produced by the authoring tools
(Part B: Support the production of accessible
content):
- Full ATAG 2.0 Conformance at Level A
The authoring tool satisfies all of the applicable Level A success criteria.
- Full ATAG 2.0 Conformance at Level AA
The authoring tool satisfies all of the applicable Level A and
Level AA success criteria.
- Full ATAG 2.0 Conformance at Level AAA
The authoring tool satisfies all of the applicable success
criteria.
And the Part A Conformance
Applicability Notes and Part B Conformance
Applicability Notes have been applied.
"Partial" ATAG 2.0 Conformance: Authoring Tool User
Interface: This type of conformance is intended to be used when
developers have initially focused on the accessibility of the authoring tool to
authors (Part A: Make the authoring tool user interface accessible):
- Partial ATAG 2.0 Conformance Level A: Authoring Tool User
Interface
The authoring tool satisfies all of the applicable Level A success criteria in Part A.
Nothing is implied about Part B.
- Partial ATAG 2.0 Conformance Level AA: Authoring Tool User
Interface
The authoring tool satisfies all of the applicable Level
A and Level AA success criteria in Part A. Nothing is implied about Part B.
- Partial ATAG 2.0 Conformance Level AAA: Authoring Tool User
Interface
The authoring tool satisfies all of the applicable
success criteria in Part A. Nothing is implied about Part B.
And the Part A Conformance
Applicability Notes have been applied.
"Partial" ATAG 2.0 Conformance: Content Production: This
type of conformance is intended to be used when developers have initially
focused on the accessibility of the web content produced by the authoring tool
to end users (Part B: Support the production of accessible content):
- Partial ATAG 2.0 Conformance Level A: Content Production
The authoring tool satisfies all of the applicable Level A success criteria in Part B.
Nothing is implied about Part A.
- Partial ATAG 2.0 Conformance Level AA: Content Production
The authoring tool satisfies all of the applicable Level
A and Level AA success criteria in Part B. Nothing is implied about Part A.
- Partial ATAG 2.0 Conformance Level AAA: Content Production
The authoring tool satisfies all of the applicable
success criteria in Part B. Nothing is implied about Part A.
And the Part B Conformance
Applicability Notes have been applied.
Note: The Working Group remains committed to the guiding
principle that: "Everyone should have the ability to create and access web
content". Therefore, it is recommended that "Partial" Conformance be
claimed only as a step toward "Full" Conformance.
Web Content
Technologies Produced:
Authoring tools conform to ATAG 2.0 with
respect to the production of specific web content technologies (e.g.
Full Level A conformance with respect to the production of XHTML 1.0, Partial
Level AA Conformance: Content Production with respect to the production of SVG
1.1).
If an authoring tool is capable of producing multiple web content
technologies, then the conformance may include only a subset of these
technologies as long as the subset includes any technologies that the developer either sets for automatically-generated content or sets as the default for
author-generated content. The
subset may include "interim" formats that are not intended for publishing to end users, but this is not
required.
When Success Criterion B.2.1.1 refers to web content
technologies for which the authoring tool provides support for the
production of accessible content, it is referring to this subset.
Live publishing authoring tools:
ATAG 2.0 may be applied to authoring tools with workflows that involve live
authoring of web content (e.g. some collaborative tools). Due to the challenges
inherent in real-time publishing, conformance to Part B
of ATAG 2.0 for these authoring tools may involve some combination of support
before (e.g. support in preparing accessible slides), during (e.g. live
captioning as WCAG 2.0 requires at Level AA) and after the live authoring
session (e.g. the ability to add a transcript to the archive of a
presentation that was initially published in real-time). For more information,
see the Implementing
ATAG 2.0 - Appendix E: Authoring Tools for Live Web Content.
Conformance Claims (Optional)
If a conformance claim is made, then the conformance claim must meet the
following conditions and include the following information (authoring tools can
conform to ATAG 2.0 without making a claim). Claimants are encouraged to claim
conformance to the most recent version of the Authoring Tool Accessibility
Guidelines Recommendation.
Conditions on
Conformance Claims
- At least one version of the conformance claim must be published on the
web as a document meeting Level A of WCAG 2.0. A suggested metadata
description for this document is "ATAG 2.0 Conformance Claim".
- Whenever the claimed conformance level is published (e.g. product
information web site), the URI for the on-line published version of the
conformance claim must be included.
- The existence of a conformance claim does not imply that the W3C has
reviewed the claim or assured its validity.
- Claimants are solely responsible for the accuracy of their claims and
keeping claims up to date.
Required Components of an ATAG 2.0
Conformance Claim
- Claimant name and affiliation.
- Date of the claim.
- Guidelines title, version
andURI
- Conformance level
satisfied.
- Authoring tool information: The name of the authoring tool and sufficient
additional information to specify the version (e.g. vendor name, version
number (or version range), required patches or updates, human
language of the user interface or documentation).
- Note: If the authoring tool is a collection of software components (e.g. a markup editor, an image editor, and a validation
tool), then information must be provided separately for each component,
although the conformance claim will treat them as a whole. As
stated above, the Claimant has sole responsibility for the conformance
claim, not the developer of any of the software
components.
- Web content technologies
produced.
- A list of the web content
technologies produced by the authoring tool that the Claimant
is including in the conformance claim. For each web
content technology, provide information on how the web content
technology might be used to create accessible web content
(e.g. provide links to technology-specific techniques).
- A list of any web content technologies produced by the authoring tool
that the Claimant is not including in the conformance
claim.
- Declarations: For each success criterion:
- A declaration of whether or not the success criterion has been
satisfied; or
- A declaration that the success criterion is not applicable and a rationale for why not.
- Platform(s): The platform(s) upon which the authoring tool
was evaluated:
Optional Components of an ATAG 2.0
Conformance Claim
- A description of the authoring tool that identifies the
types of editing-views that it includes.
- A description of how the ATAG 2.0 success criteria were
met where this may not be obvious.
"Progress Toward
Conformance" Statement
Developers of authoring tools that do not yet conform
fully to a particular ATAG 2.0 conformance level are encouraged to publish a
statement on progress toward conformance. This statement would be the same as a
conformance claim except that this statement would
specify an ATAG 2.0 conformance level that is being progressed toward, rather
than one already satisfied, and report the progress on success criteria not yet
met. The author of a "Progress Toward Conformance" Statement is solely
responsible for the accuracy of their statement. Developers are encouraged to
provide expected timelines for meeting outstanding success criteria within the
Statement.
Disclaimer
Neither W3C, WAI, nor AUWG take any responsibility for any aspect or result
of any ATAG 2.0 conformance claim that has not been
published under the authority of the W3C, WAI, or AUWG.
Appendix A: Gathering
Accessibility Information from Authors:
This section is informative.
In order to produce accessible web content, authoring tools often need
authors to provide accessibility information such as text alternatives for
images, role and state information for widgets, relationships within complex
tables, and captions for audio. As for any information to be gathered from
authors, there are a range of approaches that a developer might take for
gathering accessibility information, from voluntary unobtrusive reminders to
intrusive mandatory prompts. While ATAG 2.0 does not require
any particular approach, author cooperation and goodwill are important
considerations in ensuring that the accessibility information that is gathered
is correct and complete.
The following are some techniques that may assist in gathering different
types of accessibility information, along with some example implementations.
1.
Short text labels (e.g. alternate text, titles, short text metadata fields,
rubies for ideograms):
- Prompts may be kept short because short text strings are usually entries
of ten words or less. (see Example A-1a)
- Provide a rendered view of the object being labeled for the authors to
consult. (see Example A-1a)
- Provide the option of automatically retrieving previously used labels as
suggestions. (see Example A-1a, see Success Criterion B.2.4.2 for more
information)
- If the tool offers authors previously used labels or special function
label text, then editable text entry boxes with drop-down lists should be
used to allow authors the option of entering different text (see Example
A-1a).
- In source editing-views, suggest short text labels that are already
marked up appropriately (see Example A-1b).
Example A-1a: A dialog box offers short text labels
for reuse. It shows an "Insert Image" dialog box a thumbnail image of the
"earthrise" graphic along with entry fields for "src", "alt", "longdesc",
"height" and "width". The "alt" entry field is drop-down list that is shown
with several short labels for the same image. The first is a visual
description in English ("An earth rise as seen from the moon"), the second is
a visual description in French ("Une vue do la terre de la lune") and the
third is an English functional label used if the image serves as a link ("Go
to pictures of the earth"). (Source: mockup by AUWG)
Example A-1b: A source editing-view offers short text
labels for reuse. It shows the author midway through adding markup for an
image. After adding the src
attribute value the author has
pressed the spacebar, causing the tool to prompt them with the
alt
attribute along with several attribute values, including a
visual description in English (alt="An earth rise as seen from the moon"), a
visual description in French (alt="Une vue de la terre de la lune") and an
English functional label used if the image serves as a link (alt="Go to
pictures of the earth"). (Source: mockup by AUWG)
2. Multiple text labels (e.g. image map
area labels):
- Prompts for multiple text labels may be similar to those for short text labels, with allowance made
for rapidly adding several labels (e.g. a spreadsheet type of component).
(see Example A-2)
- Provide a rendered view of the various objects being labeled for authors
to consult
- If the objects have URIs (e.g. image map areas), display these as a hint
for the labels. (see Example A-2)
- If the objects have URIs (e.g. image map areas), offer to automatically
generate a set of plain text links from the labels that the user completes.
(see Example A-2)
Example A-2: An interface for image map area text
labels. It is comprised of a list with two columns. In the right-hand column
is the URL for each image map area. This can be used as a hint by the author
as they fill in the text labels (left-hand column). A checkbox at the bottom
provides the option of using the text labels to create a set of text links
below the image map. (Source: mockup by AUWG)
(3):
Long text descriptions (e.g. longdesc text, table summaries, site information,
long text metadata fields):
- Begin by asking authors whether the inserted object is adequately
described with an existing short text label. Providing a view of the page
with rendering of the object turned off may help authors decide. (see
Example A-3)
- If the short text label is determined to be inadequate, prompt authors
for the location of a pre-existing description. (see Example A-3)
- If authors need to create a description, provide a special writing
utility that includes a rendered view of the object and description writing
advice.
- Ensure checking can ignore objects that do not require long text
descriptions (e.g. bullets, spacers, horizontal rules) or objects that
authors have previously stated do not require long text descriptions.
Example A-3: An interface for long text descriptions.
A "description required" checkbox controls whether the rest of the interface
is available. If a description is required, the author then has the choice of
opening an existing description file or writing (and saving) a new one. If
they choose to use an existing file, there is a text entry area for the name
along with a button to browse the file system. If they choose to compose a
new description, there is a text entry area for the description followed by a
text field for the file name and a button to save it to that location. In the
situation shown, the author chooses to use an existing description of
"earthrise" so the file name containing the description is shown. In
addition, the text of the description from the file is loaded into the
compose area ("The earth hangs in the pitch black sky above the gray horizon
of the moon. The dazzling blue sphere is covered with creamy white streamers
of cloud.") in case the author would like to use this text as a basis for a
new description. (Source: mockup by AUWG)
(4): Form component labels:
- Prompts for form components may be similar to those for short text labels and/or multiple text labels.
- For web content technologies in which form component labels are external
to the actual form component elements (e.g. HTML), allow authors to either
directly add a form component label or identify pre-existing text strings
that are already serving implicitly as labels.
- It may be helpful to render the form components with indicators of label
associations or missing labels.
- It may be helpful to redisplay the components in spreadsheet form to
assist authors in determining which components are lacking labels. (see
Example A-4)
Example A-4: A form properties list with five columns
that allows the author to simultaneously decide the following for each field:
the tab order, form name, field label, component type, and accesskey. In this
example, two form field labels are missing, causing yellow highlighting of
the cells and red icons to be displayed. "Move up" and "move down" buttons
are provided. (Source: mockup by AUWG)
(5):
Form field place-holders:
(6): Tab orders:
- At the very least, provide a field for entering the tab order number for
any element that can appear in the tab order.
- Manage the tab order to prevent duplicate tab order indices and to reduce
the need for manual renumbering.
- Provide contextual information to supplement the basic tab order numbers,
such as the label or name of components.
- Provide authors with a point-and-click numbering tool that they can use
to select components to quickly create a tab order
- Provide a list of links and components to check the tab order.
- Where there are only a few links that change in each page of a
collection, ask authors to confirm whether these links receive focus first.
If so, then the tool can appropriately update the tab order.
(7):
Navigational shortcuts (e.g. keyboard shortcuts, bypass blocks, etc.):
- Suggest repetitive blocks of content that might be candidates for
bypass.
- Prompt authors with a list of links that are candidates for accesskeys,
because they are common to a number of pages in a site.
- Manage accesskey lists to ensure consistency across sites and to prevent
conflicts within pages. (see Example A-7)
Example A-7: A source editing-view that suggests
accesskey values. The following markup can be seen:
"<body><p>Here is one of the most famous photographs taken
from the <a href="moon.html" > moon.</a></p><It was
taken with a special <a href="camera.html"
accesskey="c">camera.</p>"
. A pop-up menu, centered on the
word "moon" suggest accesskey="m", because "moon" begins with "m", followed
by the rest of the alphabet in order. Accesskey="c" is missing, however,
since it is already used as an accesskey later in the document (for the
"camera" link). (Source: mockup by AUWG)
(8):
Contrasting colors:
- Assemble color palettes with insufficiently contrasting colors excluded
or identified. (see Example A-8)
- To help authors test contrast, provide gray scale and black and white
views or suggest that they activate the operating system high contrast
mode.
Example A-8: A dialog box for choosing sufficiently
contrasting color combinations. The dialog box has two tabs: one for text
color and one for background color. A "hide low contrast choices" checkbox
has been selected, so the palette of colors has been pre-screened so that
sufficient contrast between the text and the current background color is
assured. All other colors have been grayed out. (Source: mockup by AUWG)
(9):
Alternative content for multimedia (transcripts, captions, video transcripts,
audio descriptions, signed translations, still images, etc.):
- Prompt authors for the location of pre-existing alternative resources for
multimedia.
- Provide a single utility where the various alternative resources can be
managed at the same time.
- Although producing alternative resource for multimedia can be a complex
process for long media files, production suites do exist or authoring tools
can include simple utilities, with built-in media players, for producing
simple alternative resources.
- The tool should make an attempt to access existing alternative resources
for multimedia, which may be incorporated into media (e.g. as text or
secondary audio tracks) or be located separately but nearby within content.
(10): Metadata:
- For metadata information fields requiring information similar to that
discussed in the other sections of this Appendix, see the relevant section.
For example: short text labels, long text descriptions, and alternative resources for multimedia.
- When prompting for terms in a controlled vocabulary, allow authors to
choose from lists to prevent spelling errors.
- Provide the option of automating the insertion of information that easily
stored and reused (e.g. author name, author organization, date, etc.).
- Automate metadata discovery where possible.
- Provide the option of storing licensing conditions within metadata (e.g.
by Creative Commons licenses, GPL, BSD, etc.)
(11): Document structure:
- Alert authors to the occurrence of unstructured content in a way that is
appropriate to the workflow of the tool.
- Provide authors with options for creating new content that is structured,
such as:
- templates (with pre-defined structure),
- wizards (that introduce structure to content through a series of
system-generated queries), or
- real-time validators (that may be set by authors to prevent the
creation of improperly structured content)
- Provide authors with options for imposing structure on existing
unstructured content.
- For tools that support explicit structural mechanisms offer authors
the opportunity to use those mechanisms. For example, for DTD or schema
based structures, provide validation in accordance to the applicable
DTD or schema.
- For tools that do not support explicit structural mechanisms, offer
authors the option of deriving structure from format styles. For
example, provide authors a mechanism to map presentation markup that
follows formatting conventions into structural elements. For example,
patterns of text formatting may be interpreted as headings (see Example
A-11) and multiple lines of text beginning items with certain
typographical symbols, such as "*" or "-", may be interpreted as list
items.
- Provide structure-based editing features, such as:
- hide/show content blocks according to structure,
- shift content blocks up, down, and sideways through the document
structure, or
- hierarchical representation or network diagram view of the document
structure, as appropriate.
- Provide validation for structure.
- It is not necessary to prohibit editing in an unstructured mode. However,
the tool should alert authors to the fact that they are working in an
unstructured mode.
Example A-11: A WYSIWYG editing-view that detects
opportunities for enhancing structure and alerts the author. On the left side
is the WYSIWYG editing-view with the title of the page ("Mars") displayed
with a blue underline. The author has brought up a pop-up menu for the title
and sees the following options: "Repair: Mark as heading (a sub-menu displays
the different levels of header (i.e. h1, h2, etc.)) for the author to
choose", "Skip", "Ignore", "Check Accessibility...", and "Help...". On the
right, an element inspector makes clear that the title is currently marked up
as a paragraph. (Source: mockup by AUWG)
(12): Tabular structure:
- Prompt authors to identify tables as used for layout or data or implement
automated detection mechanisms.
- Differentiate utilities for table structure from utilities for document
layout - use this when tables are identified as being for layout.
- Prompt authors to provide header information. (see Example A-12)
- Prompt authors to group and split columns, rows, or blocks of cells that
are related.
- Provide authors with a linearized view of tables (as tablin does).
Example A-12: A WYSIWYG editing-view that prompts the
author to decide whether the top row of a table contains the table header
cells. The top row of the rendered table is outlined in blue to indicate an
accessibility problem. The author has brought up a pop-up menu for one of the
cells in the top row and sees the following options: "Repair: Set as header
row", "Skip", "Ignore", "Check Accessibility...", and "Help...". (Source:
mockup by AUWG)
(13): Style sheets:
- Use style sheets, according to specification, as the default mechanism
for presentation formatting and layout.
- If content is created with a style sheet format, along with a content
format, the use of that style format must also meet the requirements of
WCAG.
- Conceal the technical details of style sheet usage to a similar degree as
for usage of other markup formats supported by the tool.
- Assist authors by detecting structural markup (e.g. header tags, etc.)
that has been misused to achieve presentation formatting and, with author
permission, transforming it to use style sheets.
- Prompt authors to create style classes and rules within and across
document, rather than using more limited in-line styling.
- Assist authors by recognizing patterns in style sheet use and converting
them into style classes and rules.
- Provide the option of editing text content independently of style sheet
layout and presentation formatting.
- Assist authors with the issue of style sheet browser compatibility by
guiding them toward standard practices and detecting the existence of
non-standard practices.
- Assist authors by providing a style sheet validation function.
- Maintain a registry of styles for ease of re-use.
- For prompting and assisting with specific types of information required
by style sheets, see the other sections in this Appendix. For example: (8)
font/background colors and (11) document structure.
- Consult Accessibility
Features of CSS.
(14): Clearly written text:
- Prompt authors to specify a default language of a document.
- Provide a thesaurus function.
- Provide a dictionary lookup system that can recognize changes of
language, terms outside a controlled vocabulary as well as known
abbreviation or acronym expansions.
- Provide an automated reading level status. (see Example A-14a)
- Prompt authors for expansions of unknown acronyms, recognizable in some
languages as collections of uppercase letters. (see Example A-14b)
Example A-14a: A source editing-view that indicates
the reading level of a page and whether it exceeds a limit determined by the
author's preference settings. The editing-view includes the following markup:
<body><h1>Mars</h1><p>Mars is the fourth planet
in the solar system, orbiting at a distance of 1.5 AU, with a period of 687
days.</p></body></html>
. Then in a status bar below
the text entry area, is a reading level display: "Reading Level: 11.2
(target<8)". The 11.2 is highlighted with a yellow background and bold
text to indicate that the target is exceeded. (Source: mockup by AUWG)
Example A-14b: An authoring interface that prompts
the author to enter an acronym expansion. The rendered text reads: "The
'habitable zone' around a star is the region of that star’s solar system in
which liquid water is possible. The continuous habitable zone (CHZ) is the
region of the solar system which has remained in the zone, even during
changes in the star’s radiation pattern." The acronym "CHZ" is identified
with a blue underline as an accessibility problem. The author has brought up
a pop-up menu for the acronym and sees the following options: "Repair: Enter
acronym expansion…", "Check Accessibility...", and "Help...". (Source:
mockup by AUWG)
(15): Device-independent events:
- Detect mouse-specific events.
- If paired keyboard events (e.g.
onfocus
for
onmouseover
,) exist, suggest they be added.
(16): Non-text supplements to text:
- Prompt authors to provide icons for buttons, illustrations for text,
graphs for numeric comparisons, etc. (see Example A-16)
- Where subject metadata is available, look up appropriate
illustrations.
- If authors have identified content as instructions, then provide
templates or automated utilities for extracting flow charts, etc.
Example A-16: An authoring interface for prompting
the author about whether a paragraph that contains many numbers might be made
more clear with the addition of a chart or graph. On the left side of the
interface is the rendered text: " Planet Orbits: The inner planets orbit the
sun relatively quickly with Mercury orbiting the sun in 88 days, Venus in 224
days, Earth in 365 days, and Mars in 687 days. Compare this to Jupiter’s,
4332 day orbit." This text is marked with a yellow exclamation mark icon. On
the right side is the following explanation of the error icon: "This
paragraph contains 5 numbers. Would readers benefit if a chart or graph of
this information was added?". "Yes" and "no" buttons are provided. (Source:
mockup by AUWG)
Appendix B: Levels of
Checking Automation
This section is informative.
This list is representative, but not necessarily complete.
(a)
Automated Checking:
In automated checking, the tool is able to check for accessibility problems
automatically, with no human intervention required. This type of check is
usually appropriate for checks of a syntactic nature, such as the use of
deprecated elements or a missing attribute, in which the meaning of text or
images does not play a role.
Example B-1: A
summary interface for a code-based authoring tool that displays the results
of an automated check. The display is a tree-view where the leftmost nodes
are the names of problems ("Image missing alternate text" and "Text boxes
missing labels) with number of problems appended (e.g. "[6]") and the
sub-items are the problem instances with line numbers appended (e.g.
"(Line:45)"). (Source: mockup by AUWG)
Example B-2: A WYSIWYG
interface that displays the results of an automated check in a WYSIWYG
authoring view using blue highlighting around or under rendered elements (in
this case, the "earthrise" image and some "blinking text"), identifying
accessibility problems for the author to correct. (Source: mockup by AUWG)
Example B-3: An authoring
interface of an automated check in an instruction-level authoring view. The
text is: "<body><p>Image:</p><img
href="pic123.gif"/><hr/><blink>Blinking
text</blink></body></html>
".In this view, the text
of elements with accessibility problems (img
and
blink
) is shown in a blue font, instead of the default black
font. (Source: mockup by AUWG)
(b) Semi-Automated
Checking:
In semi-automated checking, the tool is able to identify potential problems,
but still requires human judgment by authors to make a final decision on
whether an actual problem exists. Semi-automated checks are usually most
appropriate for problems that are semantic in nature, such as descriptions of
non-text objects, as opposed to purely syntactic problems, such as missing
attributes, that lend themselves more readily to full automation.
Example B-4: A dialog box
that appears once the tool has detected an image without a description
attribute. However, since not all images require description, the author is
prompted to make the final decision ("Does this image require descriptive
text?"). The author can confirm that this is indeed an accessibility problem
by choosing and move on to the repair stage by choosing "Yes" or press "No"
to mark the potential problem, as not a problem at all. Additional help is
available in the form of a tip: "An image requires descriptive text when the
information it contains cannot be conveyed in 10 words or less using an
alternate text label." (Source: mockup by AUWG)
(c) Manual
Checking:
In manual checking, the tool provides authors with instructions for
detecting a problem, but does not automate the task of detecting the problem in
any other way. As a result, authors must decide on their own whether or not a
problem exists. Manual checks are discouraged because they are prone to human
error, especially when the type of problem in question may be easily detected
by a more automated utility, such as an element missing a particular
attribute.
Example B-5: A dialog box
that reminds the author to check if there are any words in other languages in
the document with the message: "Does this document contain any words or
phrases in a different language than the main content?". The author can move
on to the repair stage by pressing "Yes" or press "No" to mark the potential
problem, as not a problem at all. (Source: mockup by AUWG)
Appendix C: Levels of Repair
Automation
This section is informative.
This list is representative, but not necessarily complete.
(a) Repair
Instructions:
In manual repairing, the tool provides authors with instructions for making
the necessary correction, but does not automate the task in any other way. For
example, the tool may move the cursor to start of the problem, but since this
is not a substantial automation, the repair would still be considered "manual".
Manual correction tools leave it up to authors to follow the instructions and
make the repair by themselves. This is the most time consuming option for
authors and allows the most opportunity for human error.
Example C-1: Repair
instructions in a code level editing-view. In this case, the following markup
is being edited: <body><p>Image:</p><img
href="pic123.gif"/><hr/><blink>Blinking
text</blink></body></html>
. Since the problems have
already been detected in the checking step and the selected offending
elements in a code view (<img href="pic123.gif"/>
and
<blink>Blinking text</blink>
) have been highlighted
in blue text. When the author puts focus on the highlighted text, a short
repair instruction ("Repair: Add 'alt' attribute") appears in a status bar
with a button than will open a longer explanation in the help system.
(Source: mockup by AUWG)
(b)
Semi-Automated:
In semi-automated repairing, the tool can provide some automated assistance
to authors in performing corrections, but author input is still required before
the repair can be complete. For example, the tool may prompt authors for a
plain text string, but then be capable of handling all of the markup required
to add the text string to the content. In other cases, the tool may be able to
narrow the choice of repair options, but still rely on authors to make the
final selection. This type of repair is usually appropriate for corrections of
a semantic nature.
Example C-2: A
semi-automated repair in a WYSIWYG editing-view. The author has right-clicked
on an image of the "earthrise" that has been highlighted with a blue outline
by the automated checker system. This has brought up a pop-up menu with the
following choices: "Repair: Set Alt -Text: 'An earth rise as seen from the
moon'", "Enter different alt-text…", " Skip", "Ignore", "Check
Accessibility...", "Help...". The author must decide whether the label text
that the tool suggests is appropriate. Whichever option the author chooses,
the tool will handle the details of updating the content. (Source: mockup by
AUWG)
(c)
Automated:
In automated repairing, the tool is able to make repairs automatically, with
no author input required. For example, a tool may be capable of automatically
adding a document type to the header of a file that lacks this information. In
these cases, very little, if any, author notification is required. This type of
repair is usually appropriate for corrections of a syntactic or repetitive
nature.
Example C-3: An
announcement that an automated repair has been completed ("All instances of
<blink> have been replaced with CSS styling according to your
preferences."). The author selects an "ok" to proceed. An "undo" button is
provided in case the author wishes to reverse the operation. In some cases,
automated repairs might be completed with no author notification at all.
(Source: mockup by AUWG)
Appendix D: Author
Interruption Timing Options
This section is informative.
This list is representative, but not necessarily complete.
(a)
Negotiated Interruption: A negotiated interruption is caused by
interface mechanisms (e.g. icons or highlighting of the element, audio
feedback) that alert the author to a problem, but remain flexible enough to
allow the author to decide whether to take immediate action or address the
issue at a later time. Since negotiated interruptions are less intrusive than
immediate or scheduled interruptions, they can often be better integrated into
the design workflow and have the added benefit of informing the author about
the distribution of problems within the document. Although some authors may
choose to ignore the alerts completely, it is not recommended that
authors be forced to fix problems as they occur. Instead, it is recommended
that negotiated interruption be supplemented by scheduled interruptions at major editing
events (e.g. when publishing), when the tool should alert the author to the
outstanding accessibility problems.
Example D-1: A
WYSIWYG editing-view makes the author of problems detected automatically by
means of a blue line under text or around rendered objects with accessibility
problems. Here, red lines are also visible, highlighting spelling errors in
the text. The author can decide to address the problems at a later time.
(Source: mockup by AUWG)
(b)
Scheduled Interruption: A scheduled interruption is one in which the
author has set the tool to alert them of accessibility issues on a configurable
schedule. One option for the schedule might be to have prompts associated with
the interface mechanisms for significant authoring events, such as opening,
saving, closing, committing, or publishing files. At the significant authoring
event, the author would be informed of the problem, while at the same time they
would not be prevented from saving, publishing, printing, etc. A
potential downside of postponing corrective actions is that by the time the
prompt is displayed, the author may not have sufficient time or inclination to
make the required changes, especially if they are extensive.
Example D-2: A "Publish"
dialog box allows the author to publish multiple files at once, however in
the case shown here, two of the files have uncorrected accessibility problems
which causes them not to meet a "standard of publishing" the author has set
for themselves in the options. As a result the files are selected, a message
is displayed ("The selected files do not meet your specified standard for
publishing.") and the "publishing" button is grayed out. This standard is
referred to generally since it is assumed that it might include spelling and
grammar standards as well as accessibility issues. (Source: mockup by AUWG)
(c)
Immediate Interruption: An immediate interruption is the most
intrusive timing option because the attention of the author is actively
diverted from the current editing task by the notification of some issue. This
might be achieved, for instance, by an alert dialog. This type of alert
presents multiple usability problems and should be used sparingly because it
interferes with the normal design workflow. Intrusive warnings are probably
only appropriate when the window of opportunity for correcting a serious
accessibility problem is about to close, such as when an author decides to
publish the content in question. In general, negotiated and scheduled
interruptions are preferred.
Example D-3: A modal dialog
box contains the message: "This image is missing alternate text". The author
must press the "OK" button to continue. (Source: mockup by AUWG)
Appendix E:
Authoring Tools for Live Web Content
This section is informative.
Supporting the production of live web content that is also accessible is a
challenge. The immediate and continuous time pressures will limit what can
reasonably expect from authors. However, there are potential approaches that
developers may take to increase the accessibility of the live content produced
by their authoring tools:
(a) Determine Participant
Requirements: Sometimes it may be possible to determine beforehand
the accessibility requirements of the end-user audience. In other cases,
polling the participants (see "Request whiteboard descriptions" checkbox in
the figure) or matching participant profiles might help determine which types
of accessibility practices would offer the greatest advantage in the short
time available. However, usually it is impossible to know all of the needs of
the actual or potential participants.
(b) Assistant/Peer
Author: Consider designating one or more secondary authors, who can
receive and respond to prompts for supplemental information generated as the
primary author proceeds uninterrupted. The secondary author(s) might be an
unrelated specialist, analogous to a sign language interpreter, a co-author
(helpful for describing technical drawings, etc.), or in some situations a
member of the session audience (e.g. peer descriptions).
(c) Preparation
Time: Consider allowing authors time to pre-assemble materials for a
live presentation (e.g. a professor preparing for an online class).
(d) Archiving: If
the session will be archived, there may be other opportunities to increase
the accessibility of the content of the archive by guiding authors through a
process to check for and repair accessibility problems after the live session
has ended, but prior to archiving.
Example E-1: A live
presentation in a whiteboard/chat client environment that has been enhanced
to provide real-time descriptions. The example has five panes. On the far
left is a list of participants ("Presenter", "John (You)", "Jane", and
"Alice"). In the upper-middle is the chat "Presenter> I suggest a space
theme for the slide presentation.", "Image File Inserted (by Presenter)
Description: An earthrise as seen from the surface of the moon.",
"Presenter> The white text would go...", "Marker (by Presenter)
Description> Draws a red box..., and "Presenter> in this area." Notice
that descriptions are appearing here. The lower-middle is the message
composition area for this user and is blank. The upper-right is the
whiteboard. So far there is an image of "earthrise" and a red hand-drawn
rectangle on the "canvas". The whiteboard tools are "select box", "text
tool", "marker", "eraser", "insert image", "line tool", "rectangle tool", and
an "ellipse tool". In the lower-right is an area for describing a drawing
action - in this case the "Presenter' use of the Marker". Notice that any
participant can describe the events on the whiteboard even as the dialog
continues. (Source: mockup by AUWG).
Appendix F: Glossary
This section is included here for informative purposes. The normative version appears in the Authoring
Tool Accessibility Guidelines 2.0 [ATAG20].
- accessibility problems
- ATAG 2.0 recognizes two types of accessibility problems:
- authoring
tool user interface accessibility problems: Aspects of an authoring tool user
interface that does not meet a success criterion in Part A of ATAG 2.0.
- web content
accessibility problems (WCAG): Aspects of web content that does not meet a WCAG 2.0 success criterion (Level A, AA or
AAA).
- accessibility information
(WCAG)
- Any information that web content must
contain in order to meet a WCAG 2.0 success
criterion (Level A, AA or AAA). Examples include: programmatically
associated alternative content (e.g. text alternatives for images),
role and
state information for widgets, relationships
within complex tables).
- accessible content
support features
- Any features of an authoring tool that directly
support authors in increasing the accessibility of the web content being
edited. These are features that must be present to meet the
success criteria in Part B of ATAG 2.0.
- alternative content
- Web content that is used in place of other content
that some people are not able to access. Alternative content fulfills
essentially the same function or purpose as the original content. WCAG 2.0 recognizes several general types of
alternative content (for more information see WCAG 2.0):
- text alternatives for non-text
content: Text that is programmatically associated with non-text content or referred
to from text that is programmatically associated with non-text
content. For example, an image of a chart might have two text
alternatives: a description in the paragraph after the chart and a
short text alternative for the chart indicating in words that a
description follows.
- alternatives for time-based
media: Web content that serves the same function or purpose as
one or more tracks in a time based media presentation. This includes:
captions, audio descriptions, extended audio descriptions, sign
language interpretation as well as correctly sequenced text
descriptions of time-based visual and auditory information that also
is capable of achieving the outcomes of any interactivity in the
time-based presentation.
- media alternative for text:
Media that presents no more information than is already presented in
text (directly or via text alternatives). A media alternative for
text is provided for those who benefit from alternate representations
of text. Media alternatives for text may be audio-only, video-only
(including sign-language video), or audio-video.
Importantly, from the perspective of authoring tools, alternative content
may or may not be:
- programmatically
associated: Alternative content whose location and purpose can
be programmatically
determined from the original content for which it is serving as
an alternative. For example, a paragraph might serve as a text
alternative for an image, but it is only programmatically associated
if this relationship is properly encoded (e.g. by "aria-labeledby").
Note: ATAG 2.0 typically refers to programmatically associated
alternative content.
- 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 include:
- 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
- The technology of sound reproduction. Audio can be created
synthetically (including speech synthesis), recorded from real-world
sounds, or both.
- author actions preventing generation
of accessible web content
- When the actions of authors prevents authoring
tools from generating accessible web content
(WCAG). Examples include: turning off accessibility options, ignoring
prompts for accessibility information
(WCAG), providing faulty accessibility information (WCAG) at prompts,
modifying the authoring tool (e.g. via scripting, macros, etc.), and
installing plug-ins.
- authors
- People who use authoring tools to
create or modify web content. The term may cover roles
such as content authors, designers, programmers, publishers, testers,
etc. (see also Part B Conformance
Applicability Note 6: Multiple author roles). Some authoring tools
control who may be an author by managing author permissions.
- author permission
- Authorization that allows modification of given web content.
- 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. saving, publishing, 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. Authoring practices may or may not be:
- authoring session
- A state of the authoring tool in
which web content can be edited by an author.
- end of an authoring session:
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 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 can be used
by authors (alone or collaboratively) to
create or modify web content for use by other people
(other authors or end users).
Note 1: "collection of software components": Multiple
applications, plug-ins, etc. can be used together to meet ATAG 2.0 (see
also note in the "Required Components of an ATAG 2.0 Conformance
Claim").
Note 2: "alone or collaboratively": Multiple authors may contribute
to the creation of web content and, depending on the authoring tool, each
author may work with different views of the content and different author permissions.
Note 3: "to create or modify web content": This clause rules out
software that collects data from a person for other purposes (e.g. online
grocery order form) and then creates web content from that data (e.g. a
web-based warehouse order) without informing the person (however, WCAG 2.0 would still apply). This clause also
rules out software used to create content exclusively in non-web content
technologies.
Note 4: "for use by other people": This clause rules out the many
web applications that allow people to modify web content that only they
themselves experience (e.g. web-based email display settings) or that
only provide input to automated processes (e.g. library catalog search
page).
Examples of software that are generally considered authoring tools
under ATAG 2.0:
- web page authoring tools (e.g. WYSIWYG HTML
editors)
- software for directly editing source code
- software for converting to web content
technologies (e.g. "Save as HTML" features in office document
applications)
- 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
management systems, courseware tools, content aggregators)
- email clients that send messages in web content technologies
- multimedia authoring tools
- software for creating mobile web applications
Examples of software that are not considered authoring tools under ATAG
2.0 (in all cases, WCAG 2.0 still applies if the software is web-based):
- customizable personal portals: ATAG 2.0 does not apply because the
web content being edited is only available to the owner of the
portal
- e-commerce order forms: ATAG 2.0 does not apply because the purpose
of an e-commerce order form is to order a product, not communicate
with other people via web content, even if the data collected by the
form actually does result in web content (e.g. online tracking pages,
etc.)
- stand-alone accessibility checkers: ATAG 2.0 does not apply because
a stand-alone accessibility checker with no automated or
semi-automated repair functionality does not actually modify web
content. An accessibility checker with repair functionality or that
is considered as part of a larger authoring process would be
considered an authoring tool.
- 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 via a user agent.
Authoring tool user interfaces may or may not be:
- accessible authoring
tool user interfaces: Authoring tool user interfaces that meet
the success criteria of a level in Part A of
ATAG 2.0.
- checking, accessibility
- The process by which web content is evaluated for web content
accessibility problems (WCAG). ATAG 2.0 recognizes three types of
checking, based on increasing levels of automation of the tests:
- manual checking: Checking in
which the tests are carried out by authors. This
includes the case where authors are aided by instructions or guidance
provided by the authoring
tool, but where authors must carry out the actual test
procedure.
- semi-automated
checking: Checking in which the tests are partially carried out
by the authoring tool, but where authors' input or judgment is still
required to decide or help decide the outcome of the tests.
- automated checking:
Checking in which the tests are carried out automatically by the
authoring tool without any intervention by authors. An authoring tool
may support any combination of checking types.
- collection of software
components
- Any software programs that are used either together (e.g. base tool and
plug-in) or separately (e.g. markup editor, image
editor, and validation tool), regardless of whether there has been any
formal collaboration between the developers of the software components.
- content (web
content)
- Information and sensory experience to be communicated to the end
user by means of a user agent, including code or markup
that defines the content's structure, presentation, and interactions. In
ATAG 2.0, the term is primarily used to refer to the output that is
produced by the authoring tool.
Content produced by authoring tools may include web applications,
including those that act as web-based
authoring tools. Content may or may not be:
- content properties
- The individual pieces of information that make up the web content (e.g.
the attributes and contents of elements, stylesheet information, etc.).
- content (structured)
- Web content that includes machine-readable internal structure (e.g. markup
elements), as opposed to unstructured content, such
as raster image formats or plain human
language text.
- content generation (content authoring,
content editing)
- The act of specifying the web content to be rendered, played or
executed by user agents (also may be referred to as "content
authoring" or "content editing"). This may refer to information perceived
by end users or to instructions for the user agents.
Content may be author generated or automatically generated:
In some cases, responsibility for content generation is shared. For
example, an author requests an interactive object be
placed on their page (e.g. a photo album), the authoring tool applies a template, but the
template requires input from the author to be complete.
- content
rendering
- User
interface functionality that authoring tools
present if they render, play or execute the web content being
edited. ATAG 2.0 recognizes several types of content
renderings:
- conventional
renderings (or "WYSIWYG"): When content is rendered in a way
that is similar to the default rendering a user agent would
create from the same content. While "WYSIWYG", standing for
"What-you-see-is-what-you-get" is the common term, differences
between user agents and end user settings mean that in reality there
is no single typical end user experience;
or
- unconventional
renderings: When content is rendered differently than it would
be in a typical user agent (e.g. rendering an audio file as a
graphical wavefront); or
- partial renderings: When
some aspects of the content are rendered, played, or executed, but
not others (e.g. a frame-by-frame video editor renders
the graphical, but not the timing aspects, of a video).
- content
transformations
- Processes that take content in one web content
technology or non-web content technology (e.g. a word processing
format) as input and produce content that has been either:
- optimized: e.g.
removing whitespace, re-compressing images; or
- restructured:
e.g. linearizing tables, splitting a document into pages; or
- re-coded: e.g. HTML
to XHTML, a word processing format to HTML.
- control
settings
- Settings that relate to how authors operate the authoring tool, for example using the keyboard or
mouse.
- developer
- Any entities or individuals responsible for programming the authoring tool. This includes the programmers of any
additional software components included by the Claimant in the
conformance claim. In some cases, development
of the authoring tool is complete before authors can use it to publish web content. However, in other cases
(e.g. some web-based
authoring tools), the developer may continue to modify the authoring
tool even after content has been published, such that the content
experienced by the end user is modified.
- direct accessibility features
- Features of an authoring tool
that provide functionality to meet the requirements of authors with disabilities (e.g. keyboard navigation,
zoom features, text-to-speech). Additional or specialized functionality
may still be provided by external assistive
technology.
- display
settings
- Settings that relate to how authors perceive the authoring tool. These
include:
- audio display
settings: the characteristics of audio output of music, sounds and speech.
Examples include volume, speech voices, voice speed, and voice
emphasis.
- visual display
settings: the characteristics of the on-screen rendering of
text and graphics. Examples include fonts, sizes, colors, spacing,
positioning, and contrast.
- tactile display
settings: the characteristics of haptic output. Examples
include the magnitude of the haptic forces and the types of
vibration.
- documentation
- Any information that supports the use of an authoring tool. This information may be provided
electronically or otherwise and includes help, manuals, installation
instructions, sample work flows, tutorials, etc.
- document
object
- The internal representation of data in the source by a non-web based authoring tool or user agent. The document object may form part of a platform accessibility service that enables
communication with assistive
technologies. Web-based authoring tools are considered to make use
of the document object that is maintained by the user agent.
- element
- A pair of markup tags and its content, or an "empty tag" (one
that requires no closing tag or content).
- end user
- A person who interacts with web content once it has been
authored. This includes people using assistive
technologies.
- human
language
- Language that is spoken, written or signed (through visual or tactile
means) to communicate with humans.
- informative
- For information purposes and not required for conformance.
- keyboard interface
- An interface used by software to obtain keystroke input. A keyboard
interface can allows keystroke input even if particular devices do not
contain a conventional keyboard (e.g. a touchscreen PDA can have a
keyboard interface built into its operating system to support onscreen
keyboards as well as external keyboards that may be connected).
Keyboard-operated mouse emulators, such as MouseKeys, do not qualify as
operation through a keyboard interface because these emulators use
pointing device interfaces, not keyboard interfaces.
- keyboard
trap
- A user interface situation in which a keyboard interface may be used
to move focus to, but not from, a user interface component
or group of components.
- label
- Text or other component with a text
alternative that is presented to users to identify a component. A label
is presented to all users whereas the name may be hidden and only
exposed by assistive
technology. In many (but not all) cases the name and the label are
the same.
- live
- Information captured from a real-world event that is published with no more than a broadcast delay.
Note: A broadcast delay is a short (usually automated) delay,
for example used in order to give the broadcaster time to queue or censor
the audio (or video) feed, but not sufficient to allow significant
editing.
- markup
language
- A system of text annotations (e.g. elements in HTML) and
processing rules that may be used to specify the structure, presentation
or semantics of content. Examples of markup languages
include HTML and SVG.
- markup of some
content is the set of annotations that appear in the content.
- name
- Text by which software can identify a user interface component
to the author or end user. The name may
be hidden and only exposed by assistive
technology, whereas a label is presented to all users. In many (but not
all) cases, the label and the name are the same.
- non-text content
- Any content that is not a sequence of
characters that can be programmatically
determined or where the sequence is not expressing something in human language. This includes ASCII Art
(which is a pattern of characters), emoticons, and images representing
text.
- normative
- Required for conformance. One may conform in a variety of well-defined
ways to ATAG 2.0. Content identified as "informative" or "non-normative" is never
required for conformance.
- option
- When an author is presented with choices.
- default option: A setting or
value for an option that is assigned automatically by the authoring tool and remains in effect unless
canceled or changed by the author.
- platform
- The software environment within which the authoring tool operates. In
the case of web-based authoring user interfaces, this will be user agents. In the case of non-web-based user interfaces this will be operating
systems (e.g. Windows, Mac OS, Linux), virtual machines (e.g. JVM), etc.
- platform accessibility
service
- A programmatic interface that is specifically engineered to provide
communication between applications and assistive technologies (e.g. MSAA, IAccessible2 and
UI Automation for Windows applications, AXAPI for Mac OSX applications,
Gnome Accessibility Toolkit API for Gnome applications, Java Access for
Java applications, etc.). On some platforms, it may be
conventional to enhance communication further by implementing a document object.
- plug-in
- A program that runs as part of the authoring tool
(e.g. a third-party checking and repair tool) and that
is not part of web content being
edited. Authors generally choose to include or exclude
plug-ins from their authoring tool.
- presentation
- Rendering of the content in a form to
be perceived by authors or end users.
- programmatically determined
(programmatically determinable)
- Information that is encoded in a way that allows different software,
including assistive
technologies, to extract and present the information in different
modalities. ATAG 2.0 uses this term in two contexts:
- prominence
- A heuristic measure of how likely users are to notice a user interface component
in a user interface that they are operating. Prominence is affected by
numerous factors, including: the number of navigation steps required, the
reading order position, visual properties (e.g. size, spacing, color),
and even the modality of use (e.g. mouse vs. keyboard use).
- at least as prominent: For
ATAG 2.0, a user interface
component A is considered to be "at least as prominent" as
another component B when, from a default state, component A becomes
displayed (and enabled) with the same number or less "opening"
actions than are required for component B to become displayed (and
enabled).
Note 1: When a container is open, all of the enabled
components in the container (e.g. items in a list, items in a menu,
buttons in a toolbar, all components on a dialog box, etc.) are
considered to be displayed (and therefore are at least as prominent
as each other), even if the container must be scrolled for them to
become visible. This takes into account that different screen sizes
and author settings will affect which components are
visible at a given time.
Note 2: "Opening actions" are actions made by authors on
components within the user interface that result in new components
becoming displayed or enabled. For example: (a) keyboard shortcut to
a top-level menu item to display a sub-menu, (b) keyboard selection
on a button to display a dialog box, (c) mouse click on a checkbox to
enable previously disabled sub-items, etc. Actions that do not cause
new components to become actionable (e.g., moving focus, scrolling a
list), are not counted as "opening actions".
Note 3: Keyboard shortcuts to components in closed
containers are not counted as "opening actions" because the
components have no prominence when they are not displayed. The same
is true when authors must use "search" to reveal components in closed
containers.
Note 4: The "default state" is the state of the authoring tool at the beginning of an authoring
session as set by the developer. The default state of many document
authoring tools is an editing-view.
- prompt
- Any authoring tool initiated request for a decision or
piece of information from authors. Well designed
prompting will urge, suggest, and encourage authors.
- publishing
- Any point at which the authors or authoring tool make web content available
to end users (e.g. uploading a web page, committing a
change in a wiki, live streaming).
- relationships
- Meaningful associations between distinct pieces of content.
- repairing
(accessibility)
- The process by which web content
accessibility problems that have been identified within web content are resolved. ATAG 2.0
recognizes three types of repairing, based on increasing levels of
automation:
- manual repairing: Where the
repairs are carried out by authors. This
includes the case where authors are aided by instructions or guidance
provided by the authoring
tool, but where authors carry out the actual repair procedure;
- semi-automated
repairing: Where the repairs are partially carried out by the
authoring tool, but where authors' input or
judgment is still required to complete the repair; and
- automated repairing:
Where the repairs are carried out automatically by the authoring tool without any intervention by authors.
- reversible actions
- Authoring actions that, by their nature, can be
completely undone so that the system returns to the state it was in
before the action. The opposite of reversible actions are:
- irreversible actions: Actions
that cannot be reversed and may include certain save and delete
actions as well as actions made in a collaborative environment that
another author has begun to work with.
- role
- Text or a number by which software can identify the function of a
component within web content (e.g. a
string that indicates whether an image functions as a hyperlink, command
button, or check box).
- sequential keyboard
navigation
- Using a keyboard interface to navigate
one-by-one through all of the items in an ordered set (e.g. menu items,
form fields, etc.). This is in contrast to direct navigation methods such
as keyboard shortcuts and bypass links.
- technology (web content)
- A mechanism for encoding instructions to be rendered, played or
executed by user agents. Web content technologies may include markup languages, data formats, or programming
languages that authors may use alone or in combination to create
end-user experiences that range from static web pages to multimedia
presentations to dynamic web applications. Some common examples of web
content technologies include HTML, CSS, SVG, PNG, PDF, Flash,
Silverlight, Flex and JavaScript.
- templates
- Content patterns that are filled in by authors or the authoring
tool to produce content for end users (e.g. document
templates, content management templates, presentation themes). Often
templates will pre-specify at least some authoring decisions.
- accessible templates (WCAG):
Templates that the author or authoring tool can use to
create web content that meets the WCAG 2.0 success criteria at a particular
level (Level A, AA or AAA) under both of the following conditions:
- Authors correctly follow the minimum instructions associated
with the template, including providing complete and correct
information when requested (e.g. by responding to prompts,
replacing highlighted placeholders, etc.); and
- No further authoring occurs (e.g. a "blank" document template
would be assessed only on the basis of the resulting blank web
content).
- template selection
mechanism
- A function beyond standard file selection that allows authors to select templates to use as the basis for
new content or to apply to existing content.
- tutorial
- A type of documentation that
provides step-by-step instructions for performing multi-part tasks.
- user agent
- Any software that retrieves, renders and facilitates end
user interaction with web content. Examples
include web browsers, browser plug-ins, and media players.
- user interface
component
- A part of the user
interface or content display (including content renderings) that is perceived by authors as a single control for a distinct function.
- video
- The technology of moving pictures or images. Video can be made up of
animated or photographic images, or both.
- view
- A user interface function that authors use to interact
with the web content being
edited. ATAG 2.0 categorizes views according to whether they
support editing:
- editing-views: View in which
some or all of the content is editable; or
- previews:
Views in which none of the content is editable. Often the purpose is
to present content as it would appear in a user agent.
ATAG 2.0 also recognizes several approaches to presenting the content in
a view:
- workflow
- A customary sequence of steps or tasks that authors follow to produce
a content deliverable. If an authoring tool is composed of a collection of software components, then its workflows
may include use of one or more of the components.
Appendix G: References
This section is informative.
For the latest version of any W3C specification please
consult the list of W3C Technical Reports at
http://www.w3.org/TR/. Some documents listed below may have been superseded
since the publication of this document.
- [ATAG10]
- "Authoring
Tool Accessibility Guidelines 1.0", J. Treviranus, C. McCathieNevile,
I. Jacobs, and J. Richards, eds., 3 February 2000. This W3C
Recommendation is available at
http://www.w3.org/TR/2000/REC-ATAG10-20000203/.
- [ATAG20]
- "Authoring
Tool Accessibility Guidelines 2.0," J. Treviranus, J. Richards, C.
McCathieNevile, and M. May, eds. The latest version is available at
http://www.w3.org/TR/ATAG20. The latest
version of ATAG 2.0 is available at http://www.w3.org/TR/ATAG20.
- [UAAG]
- "User Agent
Accessibility Guidelines 1.0," I. Jacobs, J. Gunderson, E. Hansen,
eds.17 December 2002. This W3C Recommendation is available at
http://www.w3.org/TR/2002/REC-UAAG10-20021217/.
- [WCAG20]
- "Web Content Accessibility
Guidelines 2.0 ", B. Caldwell, M. Cooper, L. Guarino Reid, and G.
Vanderheiden.
Appendix H: Acknowledgments
Participants
active in the AUWG at the time of publication:
- Tim Boland (National Institute for Standards and Technology)
- Alastair Campbell (Nomensa)
- Cherie Ekholm (Microsoft)
- Alex Li (Microsoft)
- Alessandro Miele (Invited Expert)
- Sueann Nichols (IBM)
- Greg Pisocky (Adobe)
- Jan Richards (Inclusive Design Institute, OCAD University)
- Andrew Ronksley (Royal National Institute for the Blind)
- Roberto Scano (IWA/HWG)
- Jeanne Spellman (W3C)
- Jutta Treviranus (WG Chair; Inclusive Design Institute, OCAD
University)
Other
previously active AUWG participants and other contributors to ATAG 2.0:
Kynn Bartlett, Giorgio Brajnik, Judy Brewer, Wendy Chisholm, Daniel
Dardailler, Geoff Deering, Barry A. Feigenbaum, Katie Haritos-Shea, Kip Harris,
Phill Jenkins, Len Kasday, Marjolein Katsma, William Loughborough, Karen
Mardahl, Matt May, Charles McCathieNevile, Ann McMeekin, Matthias
Müller-Prove, Liddy Nevile, Graham Oliver, Wendy Porch, Bob Regan, Chris
Ridpath, Gregory Rosmaita, Dana Simberkoff, Reed Shaffner, Michael Squillace,
Heather Swayne, Gregg Vanderheiden, Carlos Velasco, and Jason White.
This document would not have been possible without the work of those who contributed to
ATAG 1.0.
This publication has been funded in part with Federal funds from the U.S.
Department of Education, National Institute on Disability and Rehabilitation
Research (NIDRR) under contract number ED-OSE-10-C-0067. The content of this
publication does not necessarily reflect the views or policies of the U.S.
Department of Education, nor does mention of trade names, commercial products,
or organizations imply endorsement by the U.S. Government.