This specification provides guidelines for Web authoring tool
developers. Its purpose is two-fold: to assist developers in
designing authoring tools that produce accessible Web content and
to assist developers in creating an accessible authoring
interface.
Authoring tools can enable, encourage, and assist users
("authors")
in the creation of accessible Web content through prompts, alerts, checking
and repair functions, help files and automated tools. It is just
as important that all people be
able to author content as it is for all people to have access to
it. The tools
used to create this information
must therefore
be accessible themselves. Adoption
of these guidelines will
contribute to the proliferation of Web content that can be read by a broader
range of readers and authoring tools that can be used by a broader range of
authors.
This document is part of a series of accessibility documents
published by the
W3C Web Accessibility
Initiative (WAI).
This section describes the status of this document at the
time of its publication. Other documents may supersede this
document. The latest status of this document series is maintained
at the
W3C.
This is a Public Working Draft of a document which will
supersede the W3C Recommendation
Authoring Tool Accessibility
Guidelines 1.0
[ATAG10].
It has been made available for review by W3C
Members and other interested parties, in accordance with W3C
Process. It is not endorsed by the W3C or its Members. It is
inappropriate to refer to this document other than as a "work in
progress".
This document has been produced by the
Authoring Tool Accessibility
Guidelines Working Group (AUWG)
as part of the Web Accessibility
Initiative (WAI).
The goals of the Working Group are discussed in the
AUWG charter.
A list of current W3C Recommendations and other technical documents
including Working Drafts and Notes can be found at
http://www.w3.org/TR/.
The AUWG is part of the WAI Technical
Activity.
This draft refers to the Web Content Accessibility Guidelines
(WCAG)
for specification of accessible content and refers non-normatively
to the Techniques
for Authoring Tool Accessibility
[ATAG20-TECHS].
The AUWG expects the ATAG 2.0 to be
backwards-compatible with ATAG 1.0,
or at most to make only minor changes in requirements. Before this
document reaches last call, the Working Group will publish a
detailed analysis of the differences in requirements.
The working group maintains an
ATAG 2.0 Issues List
and a log of changes between
successive Working Drafts.
Please send comments about this document to the public mailing
list: w3c-wai-au@w3.org
(public
archives).
Please note that this document may contain
typographical errors. It was published as soon as possible since
review of the content itself is important, although noting
typographical errors is also helpful.
For information about the current activities of the working
group, please refer to the
AUWG home page. This page includes an explanation of the
inter-relation of each document as well as minutes and previous
drafts.
In these guidelines, the term "authoring
tool" refers
to the wide range of software used for creating Web content, including:
- Editing tools specifically designed to produce Web content
(e.g., WYSIWYG
HTML and XML editors);
- Tools that offer the option of saving material in a Web format (e.g.,
word processors or desktop publishing packages);
- Tools that transform documents into Web formats (e.g.,
filters to transform
desktop publishing formats to Web publishing formats);
- Tools that produce multimedia, especially where it is intended for use
on the Web (e.g., video production and editing suites, SMIL
authoring packages);
- Tools for site management or site publication, including
tools that automatically
generate Web sites dynamically from a database, on-the-fly
conversion tools,
and Web site publishing tools; (e.g. learning management tools)
- Tools for management of layout (e.g., CSS formatting tools).
- Combinations of the above???
- Content aggregators???
- Real-time content creators (chat tools, etc.)???
- Services
- Collaborative Agents
Everyone should have the ability to create and access Web
content.
Authoring tools are pivotal in achieving this principle. The accessibility
of authoring tools determines who can create Web content and the output of
authoring tools determines who can access Web content.
The guidelines set forth in this document will benefit people
with
and without disabilities??. This includes people who need to use
their eyes for another task and are unable to view a screen or
people in environments
where the use
of sound is not practical or
people who use small mobile devices with small screens, no keyboard, or no
mouse.
The guidelines reflect
the following goals:
- that the tool itself be accessible,
- that the tool be designed to produce
accessible content,
- that the authoring tool support the author
in the production
of accessible content, and
- that the authoring tool integrate
accessibility solutions
into the overall "look and feel".
The accessibility of authoring tools is defined primarily by
existing specifications
for accessible software. The accessibility of authoring tool
output is defined
by the Web Content Accessibility Guidelines (WCAG).
1.3 How this document is
organized
This document contains four guidelines that reflect
the goals of accessible authoring tool design:
- Guideline 1: Ensure that the tool itself is accessible
- Guideline 2: Ensure that the tool is designed to produce
accessible content
- Guideline 3: Support the author in the production of accessible
content
- Guideline 4: Integrate accessibility solutions into the overall
"look
and feel"
Each guideline includes:
- The guideline number
- The statement of the guideline
- The rationale behind the guideline
- A list of checkpoints
Each checkpoint is intended to be
specific enough that it can be
verified , while being sufficiently general to allow
developers the
freedom to use the most appropriate strategies to satisfy it. The checkpoints
specify requirements for meeting the guidelines. Each checkpoint
includes:
- The checkpoint number
- The statement of the checkpoint
- The priority of the checkpoint
- Checkpoint subtext, including:
- a brief rationale for the checkpoint
- a minimum basic functionality requirement that is
normative
- suggested functionality for more advanced implementation (this
is optional)
- references to further information and techniques
A separate document, entitled "Techniques for Authoring Tool
Accessibility Guidelines 2.0"
[ATAG20-TECHS],
provides suggestions and examples of how to achieve the
recommendations in this document. Another document
[ATAG20-CHECKLIST]
lists all checkpoints, ordered by priority, for convenient reference.
1.4 Checkpoint priorities
Each checkpoint in the specification has been assigned one of
the following
priority levels to reflect
the importance of the checkpoint in satisfying the guidelines:
- Priority
1
- The checkpoint is essential.
- Priority
2
- The checkpoint is important.
- Priority
3
- The checkpoint is beneficial.
- Relative
Priority (Level 1, 2, or 3)
- The importance of the checkpoint depends on the specific
requirements of WCAG and is therefore relative to priorities
assigned in those guidelines.
Note: The priority
level for each checkpoint has been
chosen
based on the assumption that the author is a competent, but not necessarily
expert, user of the authoring tool, and that the author has little
or no knowledge
of accessibility. For example, the author is not expected to have read all of
the documentation, but is expected to know how to turn to the documentation
for assistance.
An ATAG conformance claim for an authoring tool must indicate
which of the following conformance levels has been met:
- Conformance Level "A"
- Tool has met all Priority 1 checkpoints and has also met all
Relative Priority checkpoints to at least Level 1.
- Conformance Level "Double-A"
- Tool has met all Priority 1 and 2 checkpoints and has also met
all Relative Priority checkpoints to at least Level 2.
- Conformance Level "Triple-A"
- Tool has met all checkpoints and has also met all Relative
Priority checkpoints to Level 3.
For the purposes of ATAG 2.0 conformance claims, tools may be
bundled together (e.g. a markup editor and a evaluation and repair
tool or a multimedia editor with a custom plug-in), however, this
has two important consequences:
- The bundled tools must be distributed together in order for
each to maintain that conformance claim.
- Bundled tools may have more difficmeeting
the checkpoints in Guideline 4 (Integrate accessibility solutions into the
overall "look and feel") than single tools that integrate
accessibility
functionality more tightly.
Conformance Icons: There are currently no conformance icons
available for this draft specification. If it becomes a
recommendatiot is expected that there will be conformance icons like
those available
for ATAG 1.0.
From the standpoint of accessibility, Web authoring is a process
that may involve
one or more tools in parallel or in sequence. In order to ensure that the Web
content produced as a result of a Web authoring process is
accessible, developers
and purchasers should choose tools that are either ATAG 2.0
conformant or ATAG
2.0-"Friendly". ATAG-"Friendly" tools are tools
which, although
they do not conform with ATAG, are also very unlikely to degrade the
accessibility of Web content. For example, a
tool which
converts the URI locations in a Web page from
absolute to relative prior to publishing.
In some cases, strategic ordering of the tools in a Web authoring
process may
increase the likelihood of producing accessible content. For
example, a markup
editor that does not conform to ATAG might be used before an ATAG conformant
evaluation and repair tool. While this is, of course, preferable to
not addressing
accessibility at all, the original markup tool is still considered
ATAG non-conformant.
Considering the markup editor and evaluation and repair tool
together is possible,
but due to the low likelihood of proper integration between the
tools, the result
is unlikely to be a high
ATAG conformance level.
2. Guidelines
GUIDELINE 1: Ensure that the tool
itself is accessible
The An authoring tool is a software program
with standard user interface elements and as such must be designed according
to relevant user interface accessibility guidelines. When custom
interface components
are created, it is essential that they be accessible through the
standard access
mechanisms for the relevant platform so that assistive technologies
can be used
with them.
Some additional user interface design considerations apply
specifically to Web
authoring tools. For instance, authoring tools must
ensure that the author can edit (in an editing view)
using one set of stylistic preferences and publish using different
styles. Authors
with low vision may need large text when editing but want to
publish with a smaller default text size. The style preferences of
the editing view must not affect the markup of the published
document.
Authoring tools must also ensure that the author can navigate a
document efficiently
while editing, regardless of
disability. Authors
who use screen readers, refreshable Braille displays, or screen
magnifiers can
make limited use (if at
all) of graphical artifacts that communicate the structure
of the document
and act as signposts when traversing it. Authors who cannot use a
mouse (
e.g., people with physical
disabilities or who
are blind) must use the slow and tiring process of moving one step at a time
through the document to access the desired content, unless more
efficient navigation
methods are available. Authoring tools should therefore provide an
editing view
that conveys a sense of the overall structure and allows structured
navigation.
Note: Documentation, help files, and
installation are part of the software and need to be available in
an
accessible form.
- 1.1 Ensure that the
authoring interface
follows all operating environment conventions that benefit
accessibilit
(A
at three priority levels: [Priority 1] for standards and conventions that
are essential to accessibility; [Priority 2] for those that are important
to accessibility; [Priority 3] for those that are beneficial to
accessibility).
-
Rationale: .
Techniques: Implementation
Techniques for Checkpoint 1.1, Evaluation Techniques for Checkpoint
1.1
Success Criteria:
This checkpoint requires all aspects of the authoring interface to be
accessible to the author. This wide scope means
that the checkpoint applies to the implementation of all the
other checkpoints
in this guidelines document. The techniques for this checkpoint
include references to checklists and guidelines for a number
of platforms
and to general guidelines for accessible
applications. In many cases several sets of standards will be
applicable.
[@@issue 7 there is no
minimum requirement
here]
- 1.2 Ensure that the authoring
interface enables
accessible editing of all element and object properties.
[Priority 1]
-
Note This checkpoint is a special case of
checkpoint 1.1
that is especially important to authoring tools.
Techniques: Implementation
Techniques for Checkpoint 1.2, Evaluation Techniques for Checkpoint
1.2
Success Criteria: provide at least one accessible way
to edit every element and object property supported by the tool.
- 1.3 Ensure that the authoring
interface enables
the author to edit the structure of the document [Priority
2]
-
Note This checkpoint is a special case of
checkpoint 1.1
that is especially important to authoring tools.
Techniques: Implementation
Techniques for Checkpoint 1.3, Evaluation Techniques for Checkpoint
1.3
Success Criteria: the checkpoint requires
that the author
be able to copy, cut or paste an element and its content at any level
of the document tree hierarchy .
- 1.4 Allow the display preferences of
the authoring interface to be changed without affecting the
document markup.
[Priority 1]
-
Note: This checkpoint applies primarily to
WYSIWYG markup
editing tools and requires that the author be able to view the content,
as it is being authored, in a way that differs from the presumed default
appearance of the rendered
content.
Techniques: Implementation
Techniques for Checkpoint 1.4, Evaluation Techniques for Checkpoint
1.4
Success Criteria: there must be some
mechanism for changing
the document display independently of the document markup.
There are a number of ways that this can be achieved,
including supporting
operating environment display preferences and allowing the
author to specify
an editing style sheet that is different from those included with the
published document. In addition, there must be some means by
which textual
alternatives can be displayed to the author in place of
non-text elements.
[@@Issue 8 - need to clean this paragraph up - some is techniques,
plus wording and some is useful for the checkpoint]
- 1.5 Ensure that the authoring interface
enables accessible navigation of editing
views via the document structure. [Priority 2]
-
Rationale: simplify navigation for the author.
Techniques: Implementation
Techniques for Checkpoint 1.5, Evaluation Techniques for Checkpoint
1.5
Success Criteria: the author should be able to move
from element to element. [@@Issue 9:
is this actually
what we need?]
- 1.6 Ensure the authoring interface allows the
author to search within the editing views.
[Priority 2]
-
Rationale: Search functions facilitate author navigation
of content as it is being authored. Most markup editing tools
will already
provide a search function, other authoring tools (i.e.
multimedia editors,
etc.) may not.
-
-
Techniques: Implementation
Techniques for Checkpoint 1.6, Evaluation Techniques for Checkpoint
1.6
-
Success Criteria:
The purpose of this checkpoint is to
encourage authoring
tool developers to include search functions into their tools in order
to facilitate navigation of the content as it is authored. This search
capability may be as simple as a string matching
"find" function
in a basic text editor or as complex as search functions that
take advantage
of the structure (elements, attributes, etc.) inherent in
marked-up content.
As this is a checkpoint within
Guideline 7 (Ensure
that the Authoring Tool is Accessible to Authors with
Disabilities) there
is one other implicit requirement: that is that the search
function must
able to move the editing focus immediately to the occurrences that it
finds (one at a time s requested by the author).
A tool that merely highlights all the found occurrences simultaneously
without allowing the author to quickly move the editing focus
to the occurrences
is not helpful as a document navigation function.
GUIDELINE 2:
Ensure that the tool is designed to produce accessible content
The most basic determinant of the accessibility of Web content is the degree
to which the authoring tool that produced it was designed with attention to
markup validity and accessibility. Tools that generate and preserve
high quality
markup are well prepared to meet the other guidelines.
.
Conformance with standards promotes interoperability and
accessibility by making
it easier to create specialized user
agents that address the needs of users with
disabilities. In particular,
many assistive technologies used with browsers and multimedia
players are only
able to provide access to Web documents
that use valid markup. Therefore, valid markup is an essential aspect of accessibility.
Where applicable use W3C
Recommendations, which have been reviewed to ensure accessibility
and interoperability
.
If there are no applicable W3C
Recommendations, use a published standard that enables accessibility.
- 2.1
Use the latest versions of W3C
Recommendations when they are available and appropriate
for a task .
[Priority
2]
-
Rationale: Many of the W3C language
recommendations have
been designed with accessibility as a goal. In addition, the
W3C has published
Notes
for some of its most popular language recommendations,
describing best use
practices. As a result, building accessibility-aware authoring tools for
W3C languages should be easier than for other language formats that lack
these supports.
Techniques: Implementation
Techniques for Checkpoint 2.1, Evaluation Techniques for Checkpoint
2.1
Success Criteria:
- Using a W3C language
Recommendation may involve
reading and/or writing Web content in that language format.
- .
- The tool may use non-W3C formats, in
addition to the W3C Recommendations.
- A W3C Recommendation
is considered available to a specific version of an authoring
tool, if the Recommendation
has reached the Candidate Recommendation phase at least two (2) years
before the version of the tool in question is released for use.
- Whether a W3C Recommendation
is appropriate
depends on a comparison of
the features
of the tool with the requirements
of the task.
Critical appropriateness
criteria will depend on the task, but may include support for media,
scripting, or styling. When comparing the appropriateness
of W3C recommendations
with non-W3C formats for
a particular task, accessibility must be included as a
comparison criteria.
- Inform the author in marketing, packaging and
documentary material of the name and version of any W3C
Recommendations
used. This notice must specify whether the conformance with
the Recommendation
is full or partial.
- 2.2 Ensure that markup
which the tool
automatically generates is valid for the language the tool is generating.
[Priority 1]
-
Rationale: Following language specifications
is the most
basic requirement for accessible content production. When
content is valid,
it is easier to check and correct accessibility errors and user
agents
are better able to render the content properly and personalize
the content
to the needs of individual .
Techniques: Implementation
Techniques for Checkpoint 2.2, Evaluation Techniques for Checkpoint
2.2
Success Criteria:
- All markup strings written by the tool are valid as defined by the
relevant W3C Language Recommendation or othformat specification. This does not apply where
, unless the markup
has been authored "by hand".
- Markup strings that the tool writes as a result of the
author selecting
elements or attributes by name from lists, toolbar buttons, etc. are
valid as defined by the relevant W3C Language
Recommendation or oth
format specification.
If the tool automatically generates markup, many authors will be
unaware of the accessibility status of the final content unless
they expend extra effort to review it and make appropriate
corrections by hand. Since many authors are unfamiliar with
accessibility, authoring tools are responsible for automatically
generating accessible markup, and where appropriate, for guiding
the author in producing accessible content.
Many applications feature the ability to convert
documents from other formats
(e.g., Rich
Text Format) into a markup format specifically intended for the Web such as
HTML. Markup changes may also be made to facilitate efficient
editing and manipulation.
It is essential that these processes do not introduce inaccessible
markup or remove accessibility, particularly when a tool hides the markup
changes from the author's view.
- 2.3 Ensure that the
author can produce
accessible content
in the markup language(s) supported by the
tool. [Priority
1]
-
Rationale: The most basic support for
accesility
is ensuring that is at
least possible
for the author to produce accessible content. Without this posssibility,
further efforts are futile. The simplest way to assure this possibility
exists is to allow authoring "by
hand",
so that well-informed authors can work around any accessibility
shortcomings
in the automatic generation of markup. However,
t ools that
only generate
markup automatically must ensure the accessibility of all
generated markup
in order to meet this requirement.
Techniques: Implementation
Techniques for Checkpoint 2.3, Evaluation Techniques for Checkpoint
2.3
Success Criteria:
- A method for authoring "by
hand"
is provided (e.g. code editing view).
If authoring "by hand"
is not provided
then:
- Tools that provide the author with choice as to how content will be
marked up, must ensure accessible alternatives to every inaccessible
choice.
- Tools that generate content automatically always generate
accessible
markup. (In other words, the tool meets Checkpoint
2.5 to Relative Priority Level 3).
- 2.4 Ensure that the tool preserves
all accessibility
information
during transformations, and conversions.
[Priority 1]
-
Rationale: Once the author has made the effort to add
accessible content, either manually or with the aid of the
authoring tool,
it would be highly
inconvenient for the authoring tool not
to take care with that content when converting (i.e. taking
content encoded
in one markup language and re-encoding it in another) or transforming it
(i.e. modifying the encoding of content without changing the
markup language).
Note: Differences in grammatical richness must be taken into
account, between
markup languages in the case of conversions, and between markup entities
in the case of conversions .
Techniques: Implementation
Techniques for Checkpoint 2.4, Evaluation Techniques for Checkpoint
2.4
Success Criteria:
- When transformations or conversions move content from
a
grammatically-rich to grammatically-poor languages or
markups entities,
the structure of the content may
need to be
flattened to the point where it is insufficient to allow the reversal
of the transformation. To
ameliorate this problem,
utilize
as much of
structural richness of the target language or markup entity as
possible.
- When reversal of the transformation is not possible, the author is
notified author .
- Equivalent alternatives (e.g. labels, descriptions, etc.)
are preserved
during every transformation or conversion ,
such that the information is still available and
useful for the
purpose of providing equivalent information for the
non-text element.
- Structural information (e.g. heading, etc.) is preserved
during every
transformation or conversion
, such that that the
information is still
available and useful for navigation.
- Separation of content from presentation is preserved during every
transformation or conversion
, such that content is still separate
from presentation to the degree possible in the new format.
- 2.5
Ensure that when the tool automatically generates content it
conforms to the
WCAG. [Relative Priority]
-
Rationale: Authoring tools that automatically generate
content that does not conform to WCAG are an obvious source of
accessibility
problems. If the tool includes checking and correction
tools,
problems result
in inconvenieence as the author must to correct errors which were completely under the
control of the tool. If the tool does not include checking and correction
tools, the result is almost certainly WCAG non-conformant documents.
Techniques: Implementation
Techniques for Checkpoint 2.5, Evaluation Techniques for Checkpoint
2.5
Success Criteria:
- All markup strings written by the tool are accessible as defined by
WCAG (see Note on Relative Priority),
unless the markup has been authored
"by hand".
- Markup strings that the tool generates from author
selections of elements
and attributes by name (e.g. from lists. etc.) are
accessible as defined
by WCAG (see Note on Relative
Priority).
- This applies to the choice of markup type, file type, and
markup practices.
- The tool may provide the author with the option of
disabling or altering
the accessible defaults.
- 2.6 Ensure that all pre-authored
content for the tool conforms to WCAG. [Relative
Priority]
-
Rationale: Pre-authored content is included with
authoring
tools for the convenience of the author. Including WCAG
conformant pre-authored
content (e.g.
accessible markup and content for templates, alt text, long descriptions
for images, captions, auditory descriptions and collated text
transcriptions
for multimedia objects, and accessible design and functional alternatives
for applets and scripts, etc.)
increases that convenience
by (1) ensuring that authors can use any of the content without concern
for the accessibility implications and (2) prevents each
individual author
from having to compose their own version of alternative content when this
task could have been done just once by the distributor.
Techniques: Implementation
Techniques for Checkpoint 2.6, Evaluation Techniques for Checkpoint
2.6
Success Criteria:
- All Web content (e.g. templates, clip art, multimedia
objects, scripts,
applets, example pages, etc) included with distribution of the tool
or provided preferentially to the users of the tool, must conform to
WCAG (see Note on Relative Priority).
Preferential offerings include those in the distribution
file or media
as well as those offerered
by the developer
or its partners that may be accessed in a way
that authors not
using the tool would not
(e.g. free clip art for
registered owners,
etc.).
- Objects that require alternative descriptions (see WCAG) have this
information stored internally (e.g. as text tracks) or
externally (e.g.
as files, database entries in a management system - see
Checkpoint 3.4,
etc.).
- 2.7 Allow the author to preserve
markup not
recognized by the tool. [Priority 2]
-
Rationale: Markup that is not recognized by
an authoring
tool may have been added to enhance accessibility.
Techniques: Implementation
Techniques for Checkpoint 2.7, Evaluation Techniques for Checkpoint
2.7
-
all
well-formed markup is Preserve.
-
Or query t
he author for their consent before removing
or changing unrecognized
markup
It is acceptable for a tool to
refuse to open
a document that contains markup that it cannot process, but
that the author
chooses to retain.
While ensuring the accessibility of automated output provides a
solid foundation
, the
author
will likely act in ways
that confound this .
Therefore, it is especially important that the authoring tool
support the author
by guiding them in matters that involve an element of human
judgment or creativity,
providing automated or semi-automated checking and correction facilities and
by providing high quality accessibility documentation.
Well-structured information and equivalent
alternative information are cornerstones of accessible
design, allowing
information to be presented in a way most appropriate for the needs
of the user
without constraining the creativity of the author. However,
producing equivalent information,
such as text alternatives for images and auditory descriptions of video, can
be one of the most challenging aspects of Web
design, and authoring
tool developers should attempt to facilitate and automate the
mechanics of this
process. For example, prompting authors to include equivalent
alternative information
such as text
equivalents, captions,
and auditory
descriptions at appropriate times can greatly ease the burden
for authors.
Where such information can be mechanically
determined and
offered as a choice for the author (e.g., the function of icons in
an automatically-generated
navigation bar, or expansion of acronyms from a dictionary), the
tool can assist
the author. At the same time, the tool can reinforce the need for
such information
and the author's role in ensuring that it is used appropriately in
each instance.
- 3.1 Assist the author to
create structured
content. [Relative Priority]
-
Rationale: While structuring content and
separating content
from presentation is important from an accessibility
standpoint, with contentis
often counter-intuitive
to accustumed to implicitly encoding the context of information into its
visual "look". Therefore, supporting
the author in this aspect of markup production is crucial.
Note:
Some checkpoints in Web Content Accessibility Guidelines 2.0
[ WCAG20]
do not apply.
Techniques: Implementation
Techniques for Checkpoint 3.2, Evaluation Techniques for Checkpoint
3.2
Success Criteria:
- the
tool has provided
the author with an explicit method of specifying the structure of the
content authoring content
independent of presentation and
authoring presentation style
sheets.
- The content created by the average author will have
structural markup
to allow navigation of the document using the structure.
Text elements
can be flexibly rendered
using various style sheets or display preferences without
author intervention.
Non-text elements can be flexibly laid
out .
- 3.2 Assist the author to
separate information from its presentation. [Relative
Priority]
-
Rationale:
Techniques: Implementation
Techniques for Checkpoint ???, Evaluation Techniques for
Checkpoint ???
- 3.3 Assist the author to ensure
device independent control. [Relative
Priority]
-
Rationale:
Techniques:
Accessible Equivalents
- 3.4 Prompt the author to provide equivalent
alternative information (e.g., captions, auditory descriptions, and collated
text transcripts for video). [Relative Priority
- See Implementation Techniques for applicable WCAG
checkpoints.]
-
Rationale: This
checkpoint is intended
to result in typical tool users providing equivalent alternatives for
all non-text elements (including alternate text, captions,
auditory descriptions,
collated text transcripts for video, etc.). Different tools
will accomplish
this goal in ways appropriate to their product and their users.
Techniques: Implementation
Techniques for Checkpoint 3.1, Evaluation Techniques for Checkpoint
3.1
Success Criteria:
- The authoring tool
reminds
the author to provide equivalent alternatives for each instance of
non-text content.
- The reminder
is made available to the author at least once prior to completion
of authoring,
- Non-text content with pre-existing equivalent
alternatives are exempt
from this requirement, if the function of the content is known with
certainty and is matched by the stored alternative (see Checkpoint
3.5).
- 3.5 Do not automatically
generate equivalent
alternatives or reuse previously authored alternatives without author
confirmation, except when the function is known with certainty.
[Priority
1]
-
Rationale: Improperly generated
alternatives can interfere
with accessibility checking.
Techniques: Implementation
Techniques for Checkpoint 3.3, Evaluation Techniques for Checkpoint
3.3
Success Criteria:
- When a new object is inserted
the tool has prompted
the author to enter an appropriate equivalent alternative without
providing a generated default entry.
- Only an alternative that has been explicitly associated with an
object is offered as a default entry for the author to
approve.
- In content authored by the average author there are no improperly
generated alternatives.
- 3.6 Provide functionality for managing,
editing, and reusing alternative equivalents for multimedia
objects. [Priority
3]
-
Rationale: Simplifying the initial
production and later
reuse of alternative equivalents will encourage authors to
use them more
frequently. In addition, such a alternative equivalent
management system
will facilitate meeting the requirements of Checkpoint
3.3.
Techniques: Implementation
Techniques for Checkpoint 3.4, Evaluation Techniques for Checkpoint
3.4
Success Criteria:
- The author is able to reuse or re-purpose previously
authored alternative equivalents to provide meaningful alternative
equivalents.
Many authoring tools allow authors to create documents with little
or no knowledge about the underlying markup. To ensure
accessibility, authoring
tools must be designed so that they can (where possible,
automatically) identify
inaccessible
markup, and enable its correction even
when the markup itself
is hidden from the author .
Authoring tool support for the creation of accessible Web content should
account for different authoring styles. Authors who can configure the tool's accessibility features to support their
regular work patterns are more likely to accept accessible
authoring practices
(see guideline 5). For example, some
authors may prefer to be alerted to accessibility
problems when they occur, whereas others may prefer to perform
a check at the end of an editing session. This
is analogous to programming
environments that allow users to decide whether to check for correct code
during editing or at compilation.
Note: Validation of markup is an essential
aspect of checking
the accessibility of content.
- 3.7 Check for and inform the author of accessibility problems. [Relative
Priority]
-
Rationale: provide the author with a
utility that helps
check documents for accessibility problems.
Techniques: Techniques
for checkpoint 3.5, Evaluation Techniques for Checkpoint 3.5.
-
-
At minimum (required basic
functionality): this utility
must provide at least one, automated or manual, check for each WCAG
2.0 [WCAG20]
checkpoint (of relevant
priority). When this utility runs it must always check
those questions
pertaining to "In General" WCAG 2.0 checkpoints, but only
those "conditional" WCAG 2.0 checkpoints that
have their conditions
fulfilled by the document.
- The average author is
aware of accessibility problems within the document.
- 3.8 Assist authors in correcting
accessibility problems.
[Relative Priority]
-
Rationale: once accessibility problems have
been found,
help the author to correct them properly.
Techniques: Techniques
for checkpoint 3.6, Evaluation Techniques for Checkpoint 3.6
Success Criteria:, provide context-sensitive help
with the accessibility checking required by checkpoint
3.5.
- The
average author is able to
successfully
correct identified accessibility problems.
- 3.9 Provide the author with a summary
of the document's accessibility status. [Priority
3]
-
Rationale: encourage authoring tools to
notify authors
of accessibility problems in a coherent way.
Techniques: Techniques
for checkpoint 3.7, Evaluation Techniques for Checkpoint 3.7.
Success Criteria:
- The
average author, following
review of help and
documentation will be aware of and able to use features of the tool
that promote accessibility.
Web authors may not be familiar with accessibility issues that arise when
creating Web content. Therefore, help and documentation must include explanations of accessibility
problems, and should demonstrate solutions with examples.
- 3.10 Document all features of the tool
that promote the production of accessible content. [Priority
1]
-
Rationale: As with any feature, documentation of all
the accessibility related feature
of the tool (dialog boxes, utility, code views, etc.) will facilitate
authors finding and using them,
effectively.
Techniques: Techniques
for checkpoint 3.8, Evaluation Techniques for Checkpoint 3.8.
Success Criteria:
- All features of the tool that help create accessible content are
documented.
- 3.11 Document the process of
using the tool to produce accessible content. [Relative
Priority]
-
Rationale: Authors will be more likely to
effectively
use the accessibility features of the tool
if a they have a workflow strategy for
integrating the new accessibility related tasks inot
the Web content authoring that
thery already perform.
Techniques: Techniques
for checkpoint 3.9, Evaluation Techniques for Checkpoint 3.9
Success Criteria:
- The documentation contains sample
suggested workflows which, if followed, will likely result
in the various levels of WCAG conformance. This
should include
the name and nature of the features and when and how they should be
used.
- For tools that lack a particular accessibility-related feature,
this worflow
strategy will contain
work-arounds that are likely to acheive
the same result..
GUIDELINE
4: Integrate accessibility solutions into the overall "look
and feel"
When a new feature is added to an existing software tool without
proper integration,
the result is often an obvious discontinuity. Differing color
schemes, fonts,
interaction styles, and even software stability can be factors
affecting author
acceptance of the new feature. In addition, the relative
prominence of different
ways to accomplish the same task can influence which one the
author chooses.
Therefore, it is important that creating accessible content be a
natural process
when using an authoring tool.
- 4.1
Ensure that the functionalities for checkpoints 3.1, 3.2, 3.5 and 3.6 are
always clearly available to the user [Priority 1]
-
Rationale: The user must be easily able to
turn on accessibility
support functionality.
Techniques: Implementation
Techniques for Checkpoint 4.1, Evaluation Techniques for Checkpoint
4.1
See Also: ATAG Checkpoints 3.1, 3.2, 3.5 and 3.6.
Success Criteria:
- If accessibility-related functionalities (see Checkpoint
3.1, Checkpoint 3.2,
Checkpoint 3.5,
and Checkpoint
3.6) are not already active by default, the mechanism
for activating
them must be available to the author: (1) at all times
during authoring
and (2) at most, one level down in the user interface (e.g. in the
first level of a drop-down menu).
- The configuration mechanism (i.e. preferences, options, etc.) for
these accessibility-related functionalities must be
designed so that
(1) authors searching for the configuration mechanism will find it
easily and (2) authors performing general configuration tasks will
readily notice the configuration mechanism.
- When these accessibility-related functionalities are
combined with
other functionalities in an authoring mechanism (i.e. one
accessibility-related
field in a general purpose dialog box), the design must allow (1)
authors searching for the functionality to find it easily and (2)
authors performing the other general purpose tasks to
readily notice
the functionality.
- 4.2 Ensure that accessible
authoring practices supporting the minimum requirements for
all WCAG
checkpoints are among the most obvious and easily initiated by
the author.
[Priority 2]
-
Rationale: For accessibility-related
functionality to
be accepted by authors, it must be integrated as seamlessly as
possible.
Techniques: Implementation
Techniques for Checkpoint 4.2, Evaluation Techniques for Checkpoint
4.2
Success Criteria:
- When an authoring action does not necessarily demand a particular
markup implementation (ex. changing the color of text), the markup
implementation(s) that meet the minimum
requirements of WCAG
must have at least the same user interface
visibility
and at least the same ease of function
activation (in terms
of mouse clicks and keystrokes) as markup implementations that do
nmeet those
requirements.
- Whenever a tool provides a means for markup (that has
not be authored
"by hand") to be added into a document by one mouse
click or keystroke, that markup must meet the
minimum requirements
of WCAG.
- 4.3 Ensure that all
functionality (prompts,
checkers, information icons, etc.) related to accessible
authoring practices is naturally integrated into the overall look and
feel of the tool. [Priority 2]
-
Rationale: User interfaces can increase the
probability
that authors will use accessible authoring practices, even
when less accessible
alternatives are provided by the tool for reasons of completeness.
Techniques: Implementation
Techniques for Checkpoint 4.3, Evaluation Techniques for Checkpoint
4.3
Success Criteria:
- The accessibility-related functionalities do not
contrast with analagous
functionality in the normal operation of the tool. For example, an
accessibility checker is analagous to
spell checker, while a prompt for a accessibility-related label is
analagous to a prompt for a document title. The following factors
must be considered: (1) Visual Design:
Design metaphors,
artistic sophistication, sizes, fonts, colours,
(2) Operation:
The degree of automation, the approximate number of mouse clicks or
keystrokes, (3) Complexity: The amount of author
instruction required, and (4)
Flexibility: The configurability
of the functionality and its features.
- The separation of accessibility-related functionalities from the
normal authoring process, should be minimized. ????
- 4.4 Ensure that
creating accessible
content is a naturally integrated part of the documentation,
including examples.
[Priority ?] [@@ No longer
relative - suggested P2]
-
Rationale: This checkpoint promotes the production of
accessible content by implicitly demonstrating to the author that all
content, regardless of purpose, should comply with the WCAG guidelines.
Techniques: Implementation
Techniques for Checkpoint 4.4, Evaluation Techniques for Checkpoint
4.4
Success Criteria:
- All markup code examples must meet the all requirements
of WCAG, regardless of the purpose of the example.
- Only the WCAG requirements appropriate to code segments
of the size
in question are
required. For example, no navigation mechanism is required for an
example comprised of only one element,
- All examples of the authoring tool interface, including
screenshots
of dialog boxes, code views, etc., included within the
documentation
must not violate any of the requirements of WCAG,
regardless of the purpose of the example. For example, a screenshot
of an image properties dialog that has been cropped so as
to include
a field for a short descriptive text label must ensure a text label
is added to that field.
-
Accessibility
(Also: Accessible)
- Within these guidelines,"accessible Web content"
and "accessible
authoring tool" mean that the content and tool can be used by people
regardless of disability. To understand the accessibility issues relevant
to authoring tool design, consider that many authors may be
creating content
in contexts very different from your own:
- They may not be able to see, hear, move, or may not be
able to process
some types of information easily or at all;
- They may have difficulty reading or comprehending text;
- They may not have or be able to use a keyboard or mouse;
- They may have a text-only display, or a small screen.
Accessible design will benefit people in these different
authoring scenarios
and also many people who do not have a physical disability but who have
similar needs. For example, someone may be working in a noisy environment
and thus require an alternative representation of audio
information. Similarly,
someone may be working in an eyes-busy environment and thus
require an audio
equivalent to information they cannot view. Users of small mobile devices
(with small screens, no keyboard, and no mouse) have similar functional
needs as some users with disabilities.
-
Accessibility Information
- "Accessibility information" is content, including information
and markup, that is used to improve the accessibility of a
document. Accessibility
information includes, but is not limited to,
equivalent alternative
information.
- Accessibility Problem
(Also: Inaccessible Markup)
- Inaccessible Web content or authoring tools cannot be used by
some people
with disabilities. The Web Content Accessibility Guidelines 2.0
[WCAG20]
describes how to create accessible Web content.
- Accessible Authoring
Practice
- "Accessible authoring practices" improve the accessibility of
Web content. Both authors and tools engage in accessible
authoring practices.
For example, authors write clearly, structure their content, and provide
navigation aids. Tools automatically generate valid markup and
assist authors
in providing and managing appropriate equivalent alternatives.
- Alert
- An "alert" draws the author's attention to an event
or situation.
It may require a response from the author.
- Alternative
Information
(Also: Equivalent Alternative)
- Content is "equivalent" to other content when both
fulfill essentially
the same function or purpose upon presentation to the user.
Equivalent alternatives
play an important role in accessible authoring practices since
certain types
of content may not be accessible to all users (e.g., video,
images, audio,
etc.). Authors are encouraged to provide text equivalents for
non-text content
since text may be rendered as synthesized speech for individuals who have
visual or learning disabilities, as Braille for individuals who
are blind,
or as graphical text for individuals who are deaf or do not
have a disability.
For more information about equivalent alternatives, please refer to the
Web Content Accessibility Guidelines WCAG
2.0 [WCAG20].
-
Attribute
- This document uses the term "attribute" as used in SGML and
XML [XML]: Element types may be defined as
having any number of attributes. Some attributes are integral
to the accessibility
of content (e.g., the
"alt",
"title",
and "longdesc" attributes in HTML).
- Auditory
Description
- An "auditory description" provides information about actions,
body language, graphics, and scene changes in a video. Auditory
descriptions
are commonly used by people who are blind or have low vision,
although they
may also be used as a low-bandwidth equivalent on the Web. An
auditory description
is either a pre-recorded human voice or a synthesized voice (recorded or
automatically generated in real time). The auditory description must be
synchronized with the auditory track of a video presentation,
usually during
natural pauses in the auditory track.
- Authored "by
hand"
- When the author specifies the precise text string, as by typing into a
text editor.
- Authoring Tool
- An "authoring tool" is any software that is used to produce
content for publishing on the Web. Authoring tools include:
- Editing tools specifically designed to produce Web content (e.g.,
WYSIWYG HTML and XML editors);
- Tools that offer the option of saving material in a Web
format (e.g.,
word processors or desktop publishing packages);
- Tools that transform documents into Web formats (e.g., filters to
transform desktop publishing formats to HTML);
- Tools that produce multimedia, especially where it is intended for
use on the Web (e.g., video production and editing suites,
SMIL authoring
packages);
- Tools for site management or site publication, including tools that
automatically generate Web sites dynamically from a
database, on-the-fly
conversion and Web site publishing tools;
- Tools for management of layout (e.g., CSS formatting tools).
-
Captions
- "Captions" are essential text
equivalents for movie audio. Captions consist of a
text
transcript
of the auditory track of the movie (or other video presentation) that is
synchronized with the video and auditory tracks. Captions are generally
rendered graphically and benefit people who can see but are
deaf, hard-of-hearing,
or cannot hear the audio.
- Conversion
Tool
- A "conversion tool" is any application or application feature
(e.g.,"Save as HTML") that transforms convert in one format to
another format (such as a markup language).
- Check
for
- As used in checkpoint
4.1,"check for" can refer to three types of checking:
- In some instances, an authoring tool will be able to
check for accessibility
problems automatically. For example, checking for validity
(checkpoint 2.2) or testing whether an image is the
only content
of a link.
- In some cases, the tool will be able to
"suspect" or "guess"
that there is a problem, but will need confirmation from the author.
For example, in making sure that a sensible reading order
is preserved
a tool can present a linearized version of a page to the author.
- In some cases, a tool must rely mostly on the author, and can only
ask the author to check. For example, the tool may prompt the author
to verify that equivalent alternatives for multimedia are
appropriate.
This is the minimal standard to be satisfied. Subtle,
rather than extensive,
prompting is more likely to be effective in encouraging the author to
verify accessibility where it cannot be done automatically.
- Document
- A "document" is a series of elements that are
defined by a
markup language (e.g., HTML 4 or an XML application).
- Editing View
- An "editing view" is a view provided
by the authoring tool that allows editing.
- Element
- An "element" is any identifiable object within a
document, for
example, a character, word, image, paragraph or spreadsheet
cell. In [HTML4] and [ XML],
an element refers to a pair of tags and their content, or an
"empty"
tag - one that requires no closing tag or content.
- Inform
- To "inform" is to make the author aware of an event
or situation
through
alert,
prompt, sound,
flash, or other means.
-
Markup Language
- Authors encode information using a "markup language" such as
HTML [HTML4], SVG [ SVG],
or MathML [MATHML].
- Presentation
Markup
- "Presentation markup" is markup
language that encodes information about the desired
presentation
or layout of the content. For example, Cascading Style Sheets
[CSS1],
[CSS2] can be used to control fonts,
colors, aural rendering, and graphical positioning. Presentation markup
should not be used in place of
structural markup to convey structure. For example,
authors should
mark up lists in HTML with proper list markup and style them
with CSS (e.g.,
to control spacing, bullets, numbering, etc.). Authors should
not use other
CSS or HTML incorrectly to lay out content graphically so that
it resembles
a list.
- Prompt
- In this document prompt does not refer to the narrow software sense of
a "prompt," rather it is used as a verb meaning to
urge, suggest
and encourage. The form and timing that this prompting takes can be user
configurable. "Prompting" does not depend upon the
author to seek
out the support but is initiated by the tool.
"Prompting" is more
than checking, correcting, and providing help and documentation
as encompassed
in guidelines 4, 5, 6. The goal of prompting the author is to encourage,
urge and support the author in creating meaningful equivalent
text without
causing frustration that may cause the author to avoid access
options. Prompting
should be implemented in such a way that it causes a positive disposition
and awareness on the part of the author toward accessible
authoring practices.
- Property
- A "property" is a piece of information about an element, for
example structural information (e.g., it is item number 7 in a list, or
plain text) or presentation information (e.g., that it is marked as bold,
its font size is 14). In XML and HTML, properties of an element include
the type of the element (e.g.,
IMG or DL), the
values of its
attributes, and information associated by means of a
style sheet.
In a database, properties of a particular element may include values of
the entry, and acceptable data types for that entry.
-
Structural
Markup
- "Structural markup" is markup
language that encodes information about the structural role of
elements of the content. For example, headings, sections,
members of a list,
and components of a complex diagram can be identified using
structural markup.
Structural markup should not be used incorrectly to control presentation
or layout. For example, authors should not use the
BLOCKQUOTE
element in HTML [HTML4]to achieve an
indentation visual
layout effect. Structural markup should be used correctly to communicate
the roles of the elements of the content and presentation
markup should be used separately to control the presentation
and layout.
-
Transcript
- A "transcript" is a text representation of sounds in an audio
clip or an auditory track of a multimedia presentation. A "collated
text transcript" for a video combines (collates) caption text with
text descriptions of video information (descriptions of the actions, body
language, graphics, and scene changes of the visual track). Collated text
transcripts are essential for individuals who are deaf-blind and rely on
Braille for access to movies and other content.
-
Transformation
- A "transformation" is a process that changes a
document or object
into another, equivalent, object according to a discrete set of
rules. This
includes
conversion tools,
software that allows
the author to change the DTD
defined for the original document to another DTD,
and the ability to change the markup of lists and convert them
into tables.
- User
Agent
- A "user agent" is software that retrieves and
renders Web content.
User agents include browsers, plug-ins for a particular media type, and
some assistive technologies.
- View
- Authoring tools may render the same content in a variety of ways; each
rendering is called a "view". Some authoring tools
will have several
different types of view, and some allow views of several
documents at once.
For instance, one view may show raw markup, a second may show a
structured
tree, a third may show markup with rendered objects while a
final view shows
an example of how the document may appear if it were to be rendered by a
particular browser. A typical way to distinguish views in a
graphic environment
is to place each in a separate window.
Many thanks to the following people who have contributed through review
and comment: Giorgio Brajnik, Daniel Dardailler, Katie
Haritos-Shea, Phill
Jenkins, Len Kasday, Marjolein Katsma, William Loughborough,
Matthias Müller-Prove,
Graham Oliver, Chris Ridpath, Gregory Rosmaita, Heather Swayne,
Carlos Velasco.
This document would not have been possible without the work of
those
who contributed to The Authoring Tool Accessibility Guidelines
1.0
For the latest version of any W3C
specification please consult the list of W3C
Technical Reports at http://www.w3.org/TR.
- [ATAG10]
-
"Authoring
Tool Accessibility Guidelines 1.0", J. Treviranus,
C. McCathieNevile,
I. Jacobs, and J. Richards, eds., 3 February 2000. This W3C
Recommendation
is http://www.w3.org/TR/2000/REC-ATAG10-20000203/.
-
[ATAG10-TECHS]
- "Techniques for Authoring
Tool Accessibility", J. Treviranus, J. Richards, I.
Jacobs, and
C. McCathieNevile editors. The latest version is available at
http://www.w3.org/TR/ATAG10-TECHS.
-
[CONFORMANCE]
- "Conformance icons
for ATAG
1.0". Information about ATAG 1.0 conformance icons
is available
at http://www.w3.org/WAI/ATAG10-Conformance.
- [CSS1]
- " CSS, level
1 Recommendation ," B. Bos and H. Wium Lie,
editors., 17 December
1996, revised 11 January 1999. This CSS1 Recommendation is
http://www.w3.org/TR/1999/REC-CSS1-19990111.
The latest version of CSS1
is available at http://www.w3.org/TR/REC-CSS1. Note:
CSS1 has been superseded by CSS2. Tools should implement the
CSS2 cascade
in particular.
- [CSS2]
- " CSS, level
2 Recommendation ," B. Bos, H. Wium Lie, C. Lilley,
and I. Jacobs,
editors., 12 May 1998. This CSS2 Recommendation is
http://www.w3.org/TR/1998/REC-CSS2-19980512.
The latest version of CSS2
is available at http://www.w3.org/TR/REC-CSS2.
- [HTML4]
- "HTML
4.01 Recommendation," D. Raggett, A. Le Hors, and I. Jacobs,
editors., 24 December 1999. This HTML 4.01 Recommendation is
http://www.w3.org/TR/1999/REC-html401-19991224.
The latest version of HTML 4
is available at http://www.w3.org/TR/html4.
- [MATHML]
- "Mathematical
Markup Language,"
P. Ion and R. Miner, editors., 7 April 1998, revised 7 July 1999. This
MathML 1.0 Recommendation is
http://www.w3.org/TR/1998/REC-MathML-19990707.
The latest version of MathML
1.0 is available at http://www.w3.org/TR/REC-MathML.
- [RDF10]
- "Resource
Description Framework (RDF) Model and Syntax Specification,"
O. Lassila, R. Swick, editors. The 22 February 1999 Recommendation is
http://www.w3.org/TR/1999/REC-rdf-syntax-19990222. The latest
version of RDF 1.0 is available at
http://www.w3.org/TR/REC-rdf-syntax.
- [SVG]
- "Scalable Vector
Graphics (SVG)
1.0 Specification (Working Draft)," J. Ferraiolo, editor. The
latest version of the SVG specification is available at
http://www.w3.org/TR/SVG.
-
[UAAG10-TECHS]
- "Techniques for User
Agent Accessibility Guidelines 1.0," J. Gunderson,
and I. Jacobs,
editors. The
latest version
of Techniques for User Agent Accessibility Guidelines 1.0
is available
at http://www.w3.org/TR/UAAG10-TECHS/.
- [WCAG20]
- "Web Content
Accessibility
Guidelines 2.0 (Working Draft)," W. Chisholm, G. Vanderheiden,
and J. White, editors. The latest version of the Web Content
Accessibility
Guidelines 2.0 is available at http://www.w3.org/TR/WCAG20/.
Note:
This document is still a working draft.
-
[WOMBAT-CHECKLIST]
- Not available.
-
[WOMBAT-TECHS]
- "
Implementation Techniques for Authoring Tools Accessibility Guidelines
'Wombat'," Jutta Treviranus, Charles McCathieNevile,
Jan Richards,
Matt May. Note: This document is still a working
group draft.
- [XML]
- "The Extensible
Markup Language (XML) 1.0," T. Bray, J. Paoli, C. M.
Sperberg-McQueen,
editors., 10 February 1998. This XML 1.0 Recommendation is
http://www.w3.org/TR/1998/REC-xml-19980210.
The latest version of
the XML specification
is available at http://www.w3.org/TR/REC-xml.
