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 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:@@check with group@@
- 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.
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 difficulty meeting the checkpoints in
Guideline 4 (Integrate accessibility solutions into the overall "look and
feel") than single, integrated tools.
Conformance Icons: There are currently no conformance icons
available for this draft specification. If it becomes a Recommendation, it 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, 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 1: Ensure that the tool itself is
accessible
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. Authors who use screen readers, refreshable Braille
displays, or screen magnifiers can make limited use (if any) of graphical
artifacts that communicate the structure of the document and act as signposts
when traversing it. Authors who cannot use a mouse (especially 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 accessibility.
(This applies 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: If the authoring tool interface does not follow
these conventions, the author who depends upon the techniques associated
with the conventions is not likely to be able to use the tool.
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. 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.
http://www.w3.org/WAI/AU/wombatissues.html#issue7 there is no
minimum requirement here]
- 1.2 Ensure that the authoring interface
enables accessible editing of all element and
object properties. [Priority 1]
-
Rationale: Element or object properties displayed and
edited through graphic means are not accessible to authors using screen
readers, Braille displays or screen enhancers. The explicit property value
should be accessible to those technologies which read text and support authors
editing text.
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 Allow the display preferences of
the authoring interface to be changed without affecting the document markup.
[Priority 1] @@THIS WAS 1.4@@
-
Rationale: Authors may require a set of display preferences
to view and control the document that is different from the desired default
display style for the published document (e.g. a particular text-background
combination that differs from the published version).
Techniques: Implementation
Techniques for Checkpoint 1.3, Evaluation Techniques for Checkpoint
1.3
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.
http://www.w3.org/WAI/AU/wombatissues.html#issue8 - need to
clean this paragraph up - some is techniques, plus wording and some is
useful for the checkpoint]
Although there are many ways this can be achieved, there must be one way
for the author to change the display of the content during authoring in
a way that differs from the most likely rendering of the content.The author
must be able to access the text alternatives in the place of any non-text
elements.
- 1.4 Ensure that the authoring interface
enables the author to edit the structure of the document [Priority 2] @@THIS WAS 1.3@@
-
Rationale:
@@JT's proposed text>@@ When using a screen reader, screen magnifier,
on-screen keyboard or Braille display it is very difficult to get an overview
of the document. Items are viewed and controlled sequentially at the
lowest level. To effectively edit a document, authors require the ability
to flexibly collapse the document so that chunks of the document can be
edited, moved or deleted at a less granular level.
@@JR's proposed text>@@ When documents are well structured, they are
often easier to navigate for both the author (see Checkpoint
1.5) and the end-user. However, because some assistive technologies
(e.g. screen reader, screen magnifier, on-screen keyboard, Braille display,
etc.) may make it difficult to view the document as a whole, additional
supports (e.g. a document trees display, etc.) are useful.
Techniques: Implementation
Techniques for Checkpoint 1.4, Evaluation Techniques for Checkpoint
1.4
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 and retain the content's hierarchical level.
- 1.5 Ensure that the authoring interface
enables accessible navigation of editing views
via the document structure. [Priority 2]
-
Rationale: Structure-based navigation should be provided
to allow authors using screen readers, Braille displays, or keyboard alternatives
to move quickly and accurately through appropriately structured documents.
Techniques: Implementation
Techniques for Checkpoint 1.5, Evaluation Techniques for Checkpoint
1.5
The author must be able to access the means to navigate the content via
the document structure.
- 1.6 Ensure the authoring interface allows
the author to search within the editing views.
[Priority 2]
-
Rationale: Search functions, such as simple string matching
or more complex mechanisms that take advantage of the structure (elements,
attributes, etc.) inherent in marked-up content, facilitate author navigation
of content as it is being authored.@@check with group@@
-
Techniques: Implementation
Techniques for Checkpoint 1.6, Evaluation Techniques for Checkpoint
1.6
-
Success Criteria:
The author must be able to access one way to search the content being
authored and quickly move the editing focus to the occurrences.
The tool should allow basic text search with a choice of skipping or
including markup.
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)
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 Use the latest versions of W3C Recommendations when they are
available and appropriate for a task. [Priority
2]
-
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.
@@check with group@@
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.
- 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 users'
devices.
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 Recommendation or other format specification. This does not
apply where the markup itself 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 Recommendation or other 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 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).
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: 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:
- 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]
-
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 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:
- 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 @@authors using the tool@@CHANGED@@, 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.
Techniques: Implementation
Techniques for Checkpoint 2.7, Evaluation Techniques for Checkpoint
2.7
Success Criteria:
- All well-formed markup is preserved.
- The author is queried for their consent before any unrecognized markup
is removed or changed.
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.
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 avoid
creating accessibility problems when they add or edit content. [Relative Priority]
-
Rationale: Appropriate assistance should increase the
likelihood that typical users of the tool 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:
- The authoring tool suggests accessible authoring practices where
appropriate.
- The authoring tool prompts (Important
Definition) the typical author for information that cannot be
generated automatically (e.g. equivalent
alternatives (see Checkpoint
3.4).
- Prompt 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]
-
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:
- Must provide at least one check (automated, semi-automated or manual)
for each requirement of WCAG [WCAG].
- A typical author is made aware of accessibility problems within the
document.
- 3.3 Assist authors in correcting
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:
- 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:
- 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.
- In content authored by the typical author, there are no improperly
generated alternatives.
- 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:
- The tool recognizes when non-text objects have previously-authored
alternative equivalents.
- A typical author is able to reuse these previously-authored authored
alternative equivalents when non-text objects are 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:
- A listing of the current accessibility problems is available.
- From the summary, the typical author will be 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 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.
- 3.8 Document the process of
using the tool to produce accessible content. [Relative
Priority]
-
Rationale: Authors will be more likely to use features
that promote accessibility, if they can integrate them into their existing
authoring practices.
Techniques: Techniques
for checkpoint 3.8, Evaluation Techniques for Checkpoint 3.8
Success Criteria:
- The documentation contains sample or suggested workflows which, if
followed, are likely to increase the chance of higher levels of WCAG
conformance than otherwise. 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:
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.3 and 3.4 are always clearly available to the author [Priority
1]
-
Rationale: If the features that support accessibility
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-related functionalities (see Checkpoint 3.1,
Checkpoint 3.2,
and Checkpoint
3.3) 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: 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 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.
- 4.3 Ensure that any 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: 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 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.
- 4.4 Ensure that accessible authoring
practices are integrated into documentation, including examples. [Priority
?] [@@ No longer relative - suggested P2]
-
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 4.4, Evaluation Techniques for Checkpoint
4.4
Success Criteria:
- All markup code examples must meet 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.
- 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
for publication. This includes software that enables authors to perform
any of the following functions:@@check with group@@
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.
- [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.
![Valid XHTML 1.0!]()