Any software or service that authors may use to create or modify Web content
for publication. @@needs work@@
Within a single authoring tool Different parts of the authoring interface
will fall under one or more of the following types of authoring functionality
or functionality that falls outside this classification scheme. The types
of authoring functions used will help determine which of the ATAG 2.0 implementation
techniques are applicable to a particular tool:
1. Code-level Authoring Functions:
Author has full control over all aspects of the resulting Web content that
have bearing on the final outcome. This covers, but is not limited to plain
text editing, as this category also covers the manipulation of symbolic
representations that are sufficiently fine-grained to allow the author the
same freedom of control as plain text editing (e.g. graphical tag placeholders).
Examples: Text editors, text editors enhanced with graphical
tags, etc.
Techniques symbol: TBA
2. WYSIWYG ("What-you-see-is-what-you-get") Authoring Functions:
Author has control over entities that closely resemble the final appearance
and behaviour of the resulting Web content.
Examples: Rendered Web page editors, bitmap graphics editors,
etc.
Techniques symbol: TBA
3. Object Oriented Authoring Functions:
Author has control over non-WYSIWYG entities that represent a functional
abstraction from the low level aspects of the resulting Web content.
Examples: timelines, waveforms, vector-based graphic editors,
etc.
Techniques symbol: TBA
4. Indirect Authoring Functions:
Authors have control of only high-level parameters related to the automated
production of the resulting Web content.This may include interfaces that
assist the author to create and organize Web content without the author
having control over the markup or programming implementation.
Examples: Content managment systems, site building wizards,
site management tools, courseware, weblogging tools, content aggregators
and conversion tools, etc
Techniques symbol: TBA
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 ability (see "How People with Disabilities Use the Web [PWD-USE-WEB,
http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/]). 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,
- 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
@@some text describing how gl's 2,3,4 build on each other@@
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
- A rationale for the checkpoint
- A pointer to implementation techniques
- Success criteria for testing whether a checkpoint has been met
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.
2. Determining Conformance
2.1 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.
1.X USABILITY TESTING OPTION FOR GUIDELINE 4@@ NEW SECTION: @@
Guideline 4 deals with promoting and integrating accessibility features within
authoring tools. This, more than any other area of these guidelines, is an
area contingent on the nature of each authoring tool, the behaviour of users
and the creativity of tool developers. Therefore, while each checkpoint still includes success criteria, a second
option is also made available for developers who may wish to develop innovative
solutions that meet the general aim of the checkpoints but not necessarily
the success criteria as listed.
This second option involves conducting thorough
usability studies that meet the following conditions:
- the study maintains a high level of objectivity with measures taken to
avoid unduly influencing the subjects (to verify this, all experimenter-subject
interactions should be videotaped)
- the study user group have used the tool and resemble, on average, the
*typical user* in experience. etc.@@(other details from def'n@@
- the study user group numbers at least 50(@@?)individuals. (@@KM against)
- the details of the study are freely available and linked from the conformance
claim @@let's add this condition to the def'n of WCAG-capable@@
- statistically significant results are those would be expected
19 times out of 20 (95%). (@@KM against)
Note: The AUWG is interested in innovative solutions to the problems of promotion
and integration of accessibility-related functions. Please forward the details
of any successful user studies to the group at @@???@@.
2. Guidelines
GUIDELINE 2: Ensure that the
tool is designed to produce accessible content
The creation of accessible content is dependent on the actions of the tool
and the author. This guideline delineates the responsibilities that rest exclusively
with the tool.
The first responsibility is to create valid, standards-based Web content,
this can be rendered reliably by more user agents, including *assistive technologies*
(Checkpoint 2.1). The next responsibility is to support formats that enable
accessible content (Checkpoint 2.2).
Web content produced by an authoring tool is most likely to be accessible,
if the content is created in accordance with the requirements of WCAG and
preserved in that state throughout the authoring process. The checkpoint requirements
that support this include ensuring that it is possible to author accessible
content (Checkpoint 2.3), preserving accessible or unknown content (Checkpoint
2.4), automatically generating accessible content (Checkpoint 2.5), and including
accessible pre-authored content (Checkpoint 2.6).
- 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.1, Evaluation Techniques for Checkpoint 2.1
Success Criteria:
- All markup strings written automatically by the tool
(i.e. not authored "by hand") must conform to the applicable
markup language specification.
- 2.2 Support formats that enable the creation of WCAG-conformant
content. [Priority 1]
-
Rationale: Some formats are *WCAG-capable*, enabling
the creation of web content that conforms to WCAG, while other formats
may intrinsically preclude this possibility.
-
Techniques: Implementation Techniques for Checkpoint 2.2,
Evaluation Techniques for Checkpoint 2.2
Success Criteria:
- The authoring tool must support at least one WCAG-capable
format for each Web content type produced.
- When format selection is automatic, the selected format must
be WCAG-capable.
2.3 Ensure that the author can produce
accessible content in the markup language(s) supported by the tool. [Priority 1]
-
Rationale: The ability to produce accessible Web content
is the most basic requirement of this document.
Techniques: Implementation Techniques for
Checkpoint 2.3, Evaluation Techniques for Checkpoint 2.3
Success Criteria: (updated 22 July)
- Tools must always meet at least one of the following:
- generate accessible content automatically
- provide the author with accessible options for every authoring
task
- provide a method for authoring "by hand"
- 2.4 Ensure that the tool preserves all unrecognized
markup and accessibility information during transformations, and conversions. [Priority 1]
-
Rationale: Unrecognized markup may include recent technologies
that have been added to enhance accessibility and should be preserved
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). *Accessibility
information* should also be preserved.
Techniques: Implementation Techniques for Checkpoint
2.4, Evaluation Techniques for Checkpoint 2.4
Success Criteria:
- During all transformations and conversions, all unrecognized markup
and accessibility information must be preserved, unless prevented
by limitations of the target format.
- When unrecognized markup or accessibility information cannot be
preserved during a conversion or transformation, the author must
be notified before any change is made.
- 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:
- Unless the author explicitly instructs the authoring tool otherwise,
all content generated by the tool must conform to WCAG.
- 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) is often included with authoring tools for the convenience of
the author. When this content is WCAG-conformant, it is more convenient
for users and more easily reused.
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) that is bundled or preferentially licensed
(i.e. better terms of use for users of the authoring tool than for
the general public), must conform to WCAG.
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 affect 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.
Guiding the author to produce accessible content:
Conformance with accessibility authoring practices is an authoring constraint,
analogous to producing valid code or grammatical text. Since the role of any
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. The checkpoint requirements for this section
include prompting and assisting the author to create accessible content, especially
for information that cannot be generated automatically, such as descriptions
of graphics (Checkpoint 3.1), checking for accessibility problems (Checkpoint
3.2), and assisting in the repair of accessibility problems (Checkpoint 3.3).
Implementation Note: All functions added to support accessible authoring
should be flexible enough to take into account different authoring styles.
When authors can configure accessibility features to support their regular
work patterns, they will be more likely to feel comfortable with their use
and be more receptive to interventions from the tool. 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.
Specific considerations
when providing this guidance
When guiding the author towards the creation of accessible
content, several specific factors should must be considered. The checkpoint
requirements for this section include taking care not to automatically include
inappropriate equivalent alternatives (Checkpoint 3.4), providing automated
means for managing equivalent alternatives (Checkpoint 3.5), and providing
accessibility status summaries (Checkpoint 3.6)
Promoting accessibility in help and documentation:
@@Note: This is proposed text.
Because authors are likely to differ widely in their familiarity with Web
content accessibility issues, the help and documentation of the authoring
tool must address several types of use. The checkpoint requirements for this
section include documenting accessible content promoting features (Checkpoint
3.7), ensuring that accessibility solutions are modeled in the documentation
and help(Checkpoint 3.8), and including suggested workflow instructions for
using the tool to produce accessible content (Checkpoint 3.9)
- 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: (updated 22 July)
- 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.).
- 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.
- 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: (updated 22 July)
- The tool must provide a repair (automated repair, semi-automated
repair or manual repair) for correcting violations of each requirement
of WCAG.
- 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: (updated 22 July)
- 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.
- 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: (updated 22 July)
- 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.
- 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: (updated 22 July)
- The tool must provide the author with an option to view
a listing of all current accessibility problems.
- 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: (updated 22 July)
- All features that play a role in creating accessible content must
be documented in the help system.
- 3.8 Ensure that accessibility is modeled
in all documentation and help, including examples. [Priority
2]
-
@@KM Text: Accessibility should be consistent throughout the tool: in
the authoring tool interface, functionality, documentation, help, tutorials
and examples, and so on. This reinforces the message of accessibility
that is being promoted and facilitates a better understanding of the reasoning
behind its use and its consequences@@
-
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: (updated 22 July)
- 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.
- 3.9 Document the workflow process
of using the tool to produce accessible content. [Priority
3] @@Note: The term "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: (updated 22 July)
- 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.
GUIDELINE 4: Promote and integrate accessibility
solutions
@@Note: This is proposed text.
This guideline requires that authoring tools must promote accessible authoring
practices within the tool as well as smoothly integrate any functions added
to meet the other requirements in this document. The checkpoint requirements
for this section include ensuring the availability of accessibility-related
functions (Checkpoint 4.1), ensuring the priority for accessible means of
completing for an authoring tasks (Checkpoint 4.2) and ensuring that accessibility-related
functions fit into the overall look and feel of the tool (Checkpoint 4.3).
- 4.1 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:
Instructions: Tools may satisfy this checkpoint by meeting the succes
criteria in Part A or Part B or both..
Part A:
- 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)
Part B:
- A user study has been conducted that meets the following requirements:
- the study meets the *technical requirements in 1.X*
- the study covers all areas of the authoring tool interface
where accessible and less accessible options exist for performing
a task.
- the study asks users to identify the most obvious means for
performing each task.
- the study validly concludes that users identify the accessible
options to a significant degree.
- 4.2 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 and activate, 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
Success Criteria:
Instructions: Tools may satisfy this checkpoint by meeting the succes
criteria in Part A or Part B or both..
Part A:
- Continuously active processes (e.g. a checker that underlines
errors as they occur, a checker that activates at a save, a checker
that every 10 minutes, etc.) that implement functions required by
checkpoints 3.1, 3.2, 3.3 and 3.7 must be enabled by default.
- If the author chooses to disable these continuously active
processes, then the tool must inform the author of
the consequences of their choice.
- User-initiated processes (e.g. a checker that the user
requests each time) that implement functions required by checkpoints
3.1, 3.2, 3.3 and 3.7 must be available to the author at *all times
during authoring* with no more steps than other *high-priority functions*.
- When the functions required by checkpoints 3.1, 3.2, 3.3 and 3.7
are combined with other authoring functions (e.g. an accessibility-related
field in a general purpose dialog box), the resulting design must
include all accessibility-related functions in the top level of
the combined user interface.
Part B:
- A user study has been conducted that meets the following requirements:
- the study meets the *technical requirements in 1.X*
- the study covers a representaive sample of starting user interface
states related to various accessibility problems.
- the study asks users to identify what information is required
and how they could check for, repair or get more information
about accessibility errors.
- the study validly concludes that the users answer these questions
correctly to a significant degree.
- 4.X Ensure that accessible authoring practices are
integrated into the overall workflow when an author develops Web Content.
(Priority 2) [@@ed. new checkpoint - text by
JT - needs approval@@]
-
Rationale: Accessible design as an afterthought or
separate process is much more onerous and therefore costly than when
accessibility is considered from the start. If the authoring tool supports
a workflow in which the author considers accessibility before and/or
during the authoring process it is more likely that accessible authoring
practices will become a common practice.
Success Criteria:
- All mechanisms that guide the author in sequencing authoring
actions (e.g., wizards, documentation, templates, help files) must
integrate accessible authoring practices.
- 4.4 Ensure that accessibility prompting, checking,
repair functions and documentation are naturally integrated into appearance
and interactive style of the tool. [Priority 2
or 3?]
-
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: (updated 22 July)
Instructions: Tools may satisfy this checkpoint by meeting the succes
criteria in Part A or Part B or both..
Part A
- The mechanisms for accessibilty 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
Part B:
- A user study has been conducted that meets the following requirements:
- the study meets the *technical requirements in 1.X*
- the study covers a represenentative sample of the entire authoring
tool interface (including those related to accesibility and
those that are not - these will act as a control).
- the study asks users to identify which, if any, parts of the
authoring tool interface appear not to match the overall appearance
or interactive style of the tool.
- the study validly concludes that users did not identify accessibility-related
authoring functions significantly more than they did non-accesiblity
related functions.
- 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.
- Author
- For the purposes of this document, an author is a user of an authoring
tool.
- 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.
- WCAG-Capable Format
- A format is WCAG-capable when a public WCAG techniques document explains
how to meet each applicable WCAG checkpoint. Non-text formats may still
be WCAG-capable if they support *equivalent alternatives*.
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, Liddy Nevile,
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 supersedes this document. .
- [ATAG20]
- " 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.
