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 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, therefore, must also be
accessible. Implementation 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 in a wider range of contexts with more
devices.
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.
The Working Group maintains a list of patent disclosures and issues related to ATAG
2.0.
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 working group has provided a reference called ATAG 2.0 References to WCAG
[WCAG-REFS] mapping the ATAG checkpoints to
WCAG 1.0 and the January 2003 draft of WCAG 2.0, currently a W3C Working Draft.
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.
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.
- Any software or service that authors may use to create or
modify Web content for publication. This includes software
that enables authors to perform any of the following
functions:
- 1. Text Editing: Authors manipulate plain text
data (e.g. markup text, program code, etc.). [Example 1]
2. Symbol-Level Editing: Authors manipulate
symbols (not WYSIWYG renderings) that represent low-level
functional groups in the underlying plain text data (e.g. symbols
in place of markup elements, programming code operations,
multi-element placeholder, etc.) .[Example
2]
3. WYSIWYG Editing: Authors manipulate
browser-like renderings of the underlying plain text data (e.g.
rendered text, images, etc. in place of markup elements). [Example 3]
4. Graphics Editing: Authors manipulate renderings
of object-oriented graphics (e.g. rendered lines, etc. in place of
markup elements in a drawing program, animation tool stage, etc.).
[Example 4]
5. Content Management: Authors exercise control of
changes to Web content across whole documents or groups of
documents, rather than at the level of individual instances of
content (e.g. site building wizards, site management tools,
courseware, content aggregators, etc.). [Example 5]
6. Constrained Editing: Authors make highly
constrained inputs that are structured and styled according to
static templates (e.g. guest books, message boards, etc.). [Example 6]
7. Timeline Editing: Authors manipulate
time-dependent Web content (e.g. animation, music, etc.) using a
user interface that represents a series of frames. [Example 7]
8. Format Conversion: Authors are assisted in
causing Web content encoded in one format to become encoded in
another (e.g. saving Web content created in one format in a
different format, importing Web content from a different format,
etc.) [Example 8]
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
regardless of disability. This includes people who need to use
their eyes for another task and are unable to view a screen, people
in environments where the use of sound is not practical, and people
who use small mobile devices with small screens, no keyboard, or no
mouse.
The guidelines promote the following goals:
- the accessibility of the authoring tool,
- the design of the tool to produce accessible content,
- the tool supporting the author in the production of accessible
content, and
- the integration of accessibility solutions into the overall
"look and feel" of the authoring tool.
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 sufficiently specific to be
verifiable, 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 indicate 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 choice of priority level for each
checkpoint is 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.
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, an
ATAG-friendly tool is one that 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 level of ATAG conformance.
2. Guidelines
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 gives priority 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 the accessibility
compliance of an authoring tool.
Where applicable use W3C Recommendations, which have been
reviewed to ensure accessibility and interoperability and which are relied
upon by assistive technology developers. If there are no applicable W3C Recommendations, use a published
standard that enables accessibility.
- 2.1 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 users' devices.
Techniques:
Implementation Techniques for Checkpoint 2.2, Evaluation Techniques
for Checkpoint 2.2
Success Criteria:
- All markup strings written by the tool must
be valid, as defined by the relevant W3C Recommendation or other
format specification. This does not apply where the markup itself
has been authored "by hand".
- All markup strings written automatically by the tool
(i.e. not authored "by hand") must conform to the applicable
markup language specification.
- 2.2 Use the latest versions
of W3C format Recommendations
when they are available and appropriate for a task. [Priority 2] @@ed. group must decide whether to keep this checkpoint
in its current form@@
-
Rationale: The W3C has implemented an accessibility
review process for language recommendations that has resulted in addition
of supports for accessibility within many of these languages as well
as published Notes describing best use practices for some of the most
popular languages. Because this process is ongoing, more recent versions
of W3C language recommendations are likely to include better supports
for accessibility than older ones.
Techniques:
Implementation Techniques for Checkpoint 2.1, Evaluation Techniques
for Checkpoint 2.1
Success Criteria:
- Provide an accessible reading of web content in available, relevant
W3C recommended language format and provide accessible means for
editing and writing 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
the features of the tool. Critical relevance criteria will depend
on the task, but may include support for media, scripting, or styling.
When comparing the appropriateness of W3C recommendations with other,
non-W3C formats for a particular task, accessibility must be included
as a comparison criteria.
- Inform the author in marketing, packaging and other 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.
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
other content intended to increase 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: If it is at least possible for
the author to produce accessible content, then well-informed authors
may be able to work around any accessibility short-comings in the rest
of the authoring tool.
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).
- Tools must always meet at least one
of the following:
- generate accessible content automatically
- provide a method for authoring "by hand"
- provide the author with accessible options for
every authoring task
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] @@ed. should
this be Relative Priority???@@
-
Rationale: Authors will be discouraged from adding
accessibility information if it is discarded during conversions (i.e.
taking content encoded in one markup language and re-encoding it in
another) or transformations (i.e. modifying the encoding of content
without changing the markup language).
Techniques:
Implementation Techniques for Checkpoint 2.4, Evaluation Techniques
for Checkpoint 2.4
Success Criteria:
- During all transformations and conversions, any accessibility
information must be preserved, unless prevented by limitations
of the target format.
- When accessibility information cannot be preserved
during a conversion or transformation, the author must
notified beforehand.
- When transformations or conversions move content
from grammatically-rich to grammatically-poor languages or markups
entities, the structure of the content may be flattened to the point
where it is insufficient to allow the reversal of the transformation.
The tool must utilize as much structural richness of the target
language or markup entity as is possible.
- When reversal of the transformation is not possible,
the author is notified prior to the conversion or transformation.
- Equivalent alternatives (e.g. labels, descriptions,
etc.) are preserved during every transformation or conversion and
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 and is still
available and useful for navigation.
- Separation of content from presentation is preserved
during every transformation or conversion and 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] @@Ensure that any automatically
generated content conforms to WCAG.@@
-
Rationale: Authoring tools that automatically generate
content that does not conform to WCAG are an obvious source of accessibility
problems.
Techniques:
Implementation Techniques for Checkpoint 2.5, Evaluation Techniques
for Checkpoint 2.5
Success Criteria:
- All markup strings written automatically by the tool
(i.e. not authored "by hand") must conform
to WCAG.
- 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 (e.g. templates, images,
videos, etc.) is often included with authoring tools for the convenience
of the author. Ensuring that pre-authored content is WCAG conformant
increases that convenience by ensuring that authors can use any of the
content without concern for the accessibility implications and relieving
subsequent authors from having to compose their own version of alternative
content.
Techniques:
Implementation Techniques for Checkpoint 2.6, Evaluation Techniques
for Checkpoint 2.6
Success Criteria:
- Any Web content (e.g. templates, clip art, multimedia
objects, scripts, applets, example pages, etc.) preferentially licensed
(i.e. better terms of use for users of tool than for others) for
users of the tool, must conform
to WCAG.
- Web content (e.g. templates, clip art, multimedia
objects, scripts, applets, example pages, etc.) included with the
distribution of the tool or provided preferentially to authors using
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 offered by the
developer or its partners to which authors not using the tool would
not have access, e.g., free clip art for registered owners.
- 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. Also, newer XML-based
languages, such as XHTML 1.1, allow authors to include multiple languages
in a single document, via namespaces. In the future, documents may contain
metadata, including accessibility information, in another namespace.
Authoring tools must not strip this information when it is encountered.
Techniques:
Implementation Techniques for Checkpoint 2.7, Evaluation Techniques
for Checkpoint 2.7
Success Criteria:
- When unrecognized markup (e.g. external entity, unrecognized
element or attribute name) is detected, the tool must query
the author for consent to modify the markup. If the author refuses,
and the markup cannot be processed, the tool must refuse
to open the markup for editing.
- All well-formed markup is preserved.
- The author is queried for their consent before
any unrecognized markup is removed or changed.
- The tool does not interfere with content in namespaces
it is not able to process.
Most authoring tools provide the author with at least some measure of control
over the produced content. This control may extend to the level of markup
coding (e.g. authoring "by hand") or it may be limited to higher-level
content, such as page layout and text content (e.g. WYSIWYG editing). In
either case, the intervention of the author has the potential to effect
the accessibility of content, either positively, if the author is purposefully
following accessibility guidelines, or negatively, if the author is not.
In order to manage these effects, authoring tools should support the author
by guiding them to follow accessibility authoring practices as they produce
that content that involves an element of human judgment or creativity, providing
automated or semi-automated checking and correction facilities and by providing
high quality accessibility-related documentation.
Conformance with accessibility authoring practices is an authoring constraint
that is little different, in principle, from the constraint to produce valid
code or grammatical text. Since the role of authoring tools is to facilitate
satisfaction of authoring constraints, it is natural that tools should include
features to facilitate the process of creating accessible content. For example,
tools may assist authors to follow specific practices by suggesting accessible
authoring practices or prompting for information that cannot be generated
automatically, such as equivalent alternatives (alternate text, descriptions,
captions, etc.).
Many authoring tools already allow authors to create documents with little
or no need for 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 when either the markup is hidden from the author or
the author does not know how to correct it.
Authoring tool support for the creation of accessible Web content should
account for different authoring styles. Authors who can choose how to configure
the tool's accessibility features to support their regular work patterns
are more likely to feel comfortable with their use of the tool and be receptive
to interventions from the tool. (see guideline 4). 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 choice is analogous to that offered in programming
environments that allow authors to decide whether to check syntax during
editing or at compilation.
- 3.1 Prompt and assist the author to create
accessible content. [Relative Priority]
-
Rationale: Appropriate assistance should increase
the likelihood that typical authors will create WCAG-conformant content.
Different tool developers will accomplish this goal in ways that are
appropriate to their products, processes and authors.
Techniques:
Implementation Techniques for Checkpoint 3.1, Evaluation Techniques
for Checkpoint 3.1
Success Criteria:
- When the actions of the author risk creating accessibility
problems (e.g. image inserted, author typing invalid element
into a code view, author initiating a page creation wizard, etc.),
the tool must intervene to introduce the appropriate accessible
authoring practice. This intervention may proceed according to a
user-configurable schedule.
- The intervention must occur at least once before completion
of authoring (e.g. final save, publishing, etc.).
- The authoring tool suggests accessible authoring
practices where appropriate.
- The authoring tool prompts (Important Definition) the author for
information that cannot be generated automatically (e.g. equivalent alternatives (see Checkpoint 3.4).
- Prompting may be combined with checking and repair,
but must be made available to the author at least once prior to
completion of authoring.
- 3.2 Check for and inform the author of accessibility problems. [Relative Priority] @@ed. Check for accessibility problems@@
-
Rationale: Authors may not notice or be able to identify
accessibility problems.
Techniques:
Techniques for checkpoint 3.2, Evaluation Techniques for Checkpoint
3.2.
-
Success Criteria:
- The tool must provide a check (automated
check, semi-automated check or
manual check) for detecting violations of each
requirement of WCAG.
- Must provide at least one check (automated, semi-automated
or manual) for each requirement of WCAG [WCAG].
- The author is made aware of accessibility problems
within the document.
- 3.3 Assist authors in repairing accessibility problems. [Relative Priority]
-
Rationale: Assistance may expedite the task of correcting
some authors' accessibility problems, while other authors may be unable
to correct accessibility problems without this help.
Techniques:
Techniques for checkpoint 3.3, Evaluation Techniques for Checkpoint
3.3
Success Criteria:
- The tool must provide a repair (automated
repair, semi-automated repair or manual repair) for correcting violations
of each requirement of WCAG.
- Context-sensitive help, semi-automated repairs
or fully automated repairs are provided for each requirement of
WCAG [WCAG].
- A typical author is able to successfully correct
any identified accessibility problem.
- 3.4 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 create
accessibility problems and interfere with accessibility checking.
Techniques:
Implementation Techniques for Checkpoint 3.4, Evaluation Techniques
for Checkpoint 3.4
Success Criteria:
- When the author inserts an unrecognized non-text object,
the tool must not insert an automatically generated text
equivalent (e.g. label generated from the file name).
- When the author inserts a non-text object for which
the tool has a previously authored equivalent (i.e. created by the
author, tool designer, pre-authored content developer, etc.), but
the function of the object is not known with certainty, the tool
must prompt the author to confirm insertion of the equivalent.
However, where the function of the non-text object is known with
certainty (e.g. "home button" on a navigation bar, etc.),
the tool may automatically insert the equivalent.
- When a recognized non-text object is inserted by
the tool, the tool must prompt the author to enter an appropriate
text equivalent, but an automatically generated default entry may
be offered.
- Only an alternative that has been explicitly associated
with an object is offered as a default entry for the author to approve.
- For new non-text objects, the tool prompts 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.
- 3.5 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 an alternative equivalent management
system will facilitate meeting the requirements of Checkpoint 3.4.
Techniques:
Implementation Techniques for Checkpoint 3.5, Evaluation Techniques
for Checkpoint 3.5
Success Criteria:
- When non-text objects have been previously inserted
using the tool, the tool must suggest any previously authored
textual equivalents for that non-text object.
- The tool recognizes when non-text objects have
previously-authored alternative equivalents.
- A typical author is able to reuse these previously-authored
alternative equivalents when non-text content is reused.
- 3.6 Provide the author with a summary of the
document's accessibility status. [Priority 3]
-
Rationale: This summary will prompt the author to:
improve the accessibility status; keep track of problems; and monitor
progress.
Techniques:
Techniques for checkpoint 3.6, Evaluation Techniques for Checkpoint
3.6.
Success Criteria:
- The tool must provide the author with an option to
view a listing of all current accessibility problems.
- A listing of the current accessibility problems
is available.
- From the summary, the typical author will be able
to tell whether their content meets the accessibility standard in
question.
Some Web authors may not be familiar with accessibility issues that arise
when creating Web content, while others may be authors familiar with these
issues, but may not know how the tool can help to address them. Therefore,
help and other supplied documentation must include explanations of accessibility problems, and
should demonstrate solutions with examples.
- 3.7 Document all features of the tool that
promote the production of accessible content. [Priority
1]
-
Rationale: Without documention of the features that
promote accessibility (e.g. prompts for alternates, code validators,
accessibility checkers, etc.) authors may not find or use them.
Techniques:
Techniques for checkpoint 3.7, Evaluation Techniques for Checkpoint
3.7.
Success Criteria:
- All features that play a role in creating accessible
content must be documented in the help system.
- All features that help create accessible content
are documented in the help system.
- A typical author, following a review of help and
other supplied documentation will be aware of and able to use features
of the tool that promote accessibility.
- All markup code examples meets all requirements
of WCAG, regardless of the purpose of the example.
- Only the WCAG requirements appropriate to code
segments of the content section 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.
- 3.8 Ensure that accessibility is modeled
in all documentation and help, including examples. [Priority
2]
-
Rationale: If authors must look somewhere special
for information on accessible authoring practices, they may be unlikely
to make the effort. Familiarity with these practices will be promoted
by their integration.
Techniques:
Implementation Techniques for Checkpoint 3.8, Evaluation Techniques
for Checkpoint 3.8
Success Criteria:
- All examples of markup code and views of the user
interface (dialog screenshots, etc.) must meet the requirements
of WCAG, regardless of whether the examples are intended to demonstrate
accessibility authoring practices.
- All markup code examples meet all
applicable WCAG requirements. (This includes examples that are
not meant to demonstrate accessibility.) For example, it is not
required to show a navigation mechanism for an example comprised
of only one element.
- All authoring tool interface examples, including
screenshots of dialog boxes, etc., meet all
applicable WCAG requirements. For example, a screenshot of an
image properties dialog that includes a field for a short descriptive
text label must include a value in that field.
Applicable WCAG requirements
are those appropriate to the scope of the example.
- 3.9 Document the workflow process
of using the tool to produce accessible content. [Priority 3]Note: The definition
of "workflow" still needs definition.
-
Rationale: Authors will be more likely to use features
that promote accessibility if they understand when and how to use them.
Techniques:
Techniques for checkpoint 3.9, Evaluation Techniques for Checkpoint
3.9
Success Criteria:
- The documentation must contain suggested
content creation workflow descriptions that include how and when
to use the accessibility-related features of the tool.
- For tools that lack a particular accessibility-related
feature, the workflow description must include a workaround
for that feature.
- The documentation contains sample or suggested
workflows which, if followed, are likely to increase the chance
of higher 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 workflow strategy will contain workarounds that are
likely to achieve the same result.
- A typical author should be able to find and understand
this workflow documentation.
GUIDELINE 4: Promote and integrate accessibility
solutions
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 accessibility prompting, checking,
repair functions and documentation are always clearly available to the
author [Priority 1]
-
Rationale: If the features that support accessible
authoring are difficult to find, activate or use, they are less likely
to be used. Ideally, these features should be turned on by default.
Techniques:
Implementation Techniques for Checkpoint 4.1, Evaluation Techniques
for Checkpoint 4.1
See Also: ATAG Checkpoints 3.1, 3.2, and 3.3.
Success Criteria:
- If accessibility prompting (see Checkpoint 3.1), checking (see Checkpoint 3.2), and repairing (see Checkpoint 3.3) functions are not already
active by default, the mechanism for activating them must
be available to the author at all times during authoring and, 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 functions must be
designed so that typical authors searching for the configuration
mechanism will be likely to find it and that typical authors performing
general configuration tasks will be likely to notice the configuration
mechanism.
- When these accessibility-related functions are combined
with other authoring functions (i.e. one accessibility-related field
in a general purpose dialog box), the y must be designed
so that typical authors searching for the function will be likely
to find it and that typical authors performing other general purpose
tasks will be likely to notice the function.
- If accessibility prompting (see Checkpoint 3.1), checking (see Checkpoint 3.2), and repairing (see Checkpoint 3.3) functions 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 functions 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 functions are
combined with other authoring functions (i.e. one accessibility-related
field in a general purpose dialog box), the design must allow (1)
authors searching for the function to find it easily and (2) authors
performing the other general purpose tasks to readily notice the
function.
- 4.2 Ensure that the most accessible option for
an authoring task is given priority. [Priority 2]
-
Rationale: Authors are most likely to use the first
and easiest options.
Techniques:
Implementation Techniques for Checkpoint 4.2, Evaluation Techniques
for Checkpoint 4.2
Success Criteria:
- When a tool provides a means for markup to be added
with a single mouse click or keystroke, that markup must
meet the requirements of WCAG unless the markup was authored "by hand".
- When an authoring action has several markup implementations
(e.g. changing the color of text with presentation markup or style
sheets), those markup implementation(s) that meet the requirements
of WCAG must be equal to or higher on all of the following
scales than those markup implementations that do not meet the WCAG
requirements.
- Prominence of location (in "power tools"
such as floating menus, toolbars, etc.)
- Position in layout (top to bottom and left to right
in menus, dialog boxes, etc. )
- Size of control (measured as screen area)
- Actions to activate (number of mouse clicks or keystrokes)
- 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 not meet
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.
- Accessible documentation is available in the help
subsystem.
- 4.3 Ensure that accessibility prompting, checking,
repair functions and documentation are naturally integrated into the overall
look and feel of the tool. [Priority 2]
-
Rationale: Most authors are reluctant to use features
that depart from the conventions of a tool.
Techniques:
Implementation Techniques for Checkpoint 4.3, Evaluation Techniques
for Checkpoint 4.3
Success Criteria:
- The mechanisms for accessibility prompting, checking,
repair and documentation must be similar to comparable
mechanisms in terms the following characteristics:
- visual design (design metaphors, artistic sophistication,
sizes, fonts, colors)
- operation (degree of automation, number of actions
for activation)
- configurability (number and types of features)
- 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
a 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.
- 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
- Any software or service that authors may use to create or
modify Web content. This includes software
that enables authors to perform any of the following
functions:
1. Text Editing: Authors manipulate plain text
data (e.g. markup text, program code, etc.). [Example 1]
2. Symbol-Level Editing: Authors manipulate
symbols (not WYSIWYG renderings) that represent low-level
functional groups in the underlying plain text data (e.g. symbols
in place of markup elements, programming code operations,
multi-element placeholder, etc.) .[Example
2]
3. WYSIWYG Editing: Authors manipulate
browser-like renderings of the underlying plain text data (e.g.
rendered text, images, etc. in place of markup elements). [Example 3]
4. Graphics Editing: Authors manipulate renderings
of object-oriented graphics (e.g. rendered lines, etc. in place of
markup elements in a drawing program, animation tool stage, etc.).
[Example 4]
5. Content Management: Authors exercise control of
changes to Web content across whole documents or groups of
documents, rather than at the level of individual instances of
content (e.g. site building wizards, site management tools,
courseware, content aggregators, etc.). [Example 5]
6. Constrained Editing: Authors make highly
constrained inputs that are structured and styled according to
static templates (e.g. guest books, message boards, etc.). [Example 6]
7. Timeline Editing: Authors manipulate
time-dependent Web content (e.g. animation, music, etc.) using a
user interface that represents a series of frames. [Example 7]
8. Format Conversion: Authors are assisted in
causing Web content encoded in one format to become encoded in
another (e.g. saving Web content created in one format in a
different format, importing Web content from a different format,
etc.) [Example 8]
- 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/1999/07/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.
- [WCAG-REFS]
- ATAG 2.0 References to WCAG, J. Treviranus,
J. Richards, and M. May, editors.
- [WOMBAT-CHECKLIST]
- Not available.
- [WOMBAT-TECHS]
- "
Implementation Techniques for Authoring Tools Accessibility
Guidelines 'Wombat'," Jutta Treviranus, Charles McCathieNevile,
Jan Richards, Matt May. Note: ATAG20-TECHS supersedes this
document. .
- [ATAG20-TECHS]
- " Implementation
Techniques for Authoring Tools Accessibility Guidelines 2.0,"
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.