User Agent Accessibility Guidelines 1.0
31 August 2001
This normative
section defines what it means to conform to this document and explains how to
make a valid conformance claim. The following
are important conformance concepts.
- Conformance and conformance claims differ. This document
distinguishes conformance requirements and conformance claim
requirements. The sections on
unconditional conformance and
conditional conformance explain the conformance requirements. The section
on well-formed claims explains the claim
requirements (e.g., identification of the components that make up the user
agent, the operating environment in which they run, etc.) Here is a sample claim (expressed in HTML):
<p>On 31 August
2001, Project X (version 2.3) running on MyOperatingSystem (version 4.2)
conforms to <abbr title="the World Wide Web
Consortium">W3C</abbr>'s "User Agent Accessibility Guidelines 1.0",
http://www.w3.org/WAI/UA/WD-UAAG10-20010831, level Double-A. Unsupported
content types: Video, Speech. Unsupported input modalities: Voice. (see section
3.1 of the UAAG 1.0). The <a href="http://example.com/checkpoints">list
of checkpoints that do not apply</a> is available
online.</p>
- Modular conformance. A conforming user
agent is not required to be a single piece of software. In general,
a conforming user agent will consist of several coordinated components, such as
a browser, a multimedia player, documentation on the Web, etc. The current
document places no restrictions on the type or number of components that make
up the "subject of a conformance
claim", i.e., the user agent (i.e., set of components) about which someone
has made a conformance claim.
- Conditional conformance. A user agent is not required to
satisfy every checkpoint in order to conform. This document allows "conditional conformance", which means
conformance to less than (or more than) a default set of requirements.
Claimants may not pick and choose which requirements they wish to satisfy in
order to conform conditionally; conditional conformance is governed by several
mechanisms described below:
- conformance levels,
- content type labels,
- input modality labels,
- selection label.
When a user agent conforms conditionally, a conformance claim about the user
agent must indicate how the set of satisfied requirements differs from the
default set; see the section on well-formed
claims.
- Applicability. Some checkpoints may not apply to a particular user agent because of the nature
of the user agent's user interface or the nature of the format(s) implemented
by the user agent. If a checkpoint (or portion of a checkpoint) doesn't apply,
the user agent is not required to satisfy it for conformance. A claimant must
state in a well-formed conformance claim which
checkpoints, if any, do not apply. See the section on
applicability for information about how to determine whether a checkpoint
applies.
In this document (notably in the checkpoints and in this section on
conformance), the terms "must", "should", and "may" (and related terms) are
used in accordance with RFC 2119
[RFC2119].
Note: Conformance to the requirements of this document is
expected to be a strong indicator of accessibility, but it is neither a
necessary nor sufficient condition for ensuring the accessibility of software.
Some software may not conform to this document but still be accessible to some
users with disabilities. Conversely, some software may conform to this document
but still be inaccessible to some users with disabilities. Some requirements of
this document may not benefit some users for some content, but the requirements
are expected to benefit many users with disabilities, for general purpose
content. For more information, please see the sections on known limitations of this document and restricted functionality and
conformance.
A user agent conforms unconditionally to this document if:
- it satisfies all of the requirements of all the checkpoints. Note that each
checkpoint statement includes one or more requirements. The requirements made
by a checkpoint include those associated with any content type labels for that checkpoint.
Certain checkpoints also include labels that indicate (when there might be
ambiguity) whether the requirements are for all
content, for all rendered content, for user agent features, or for both user
agent features and content;
- for each checkpoint in guideline 6, it satisfies the requirements by implementing
APIs. For every other checkpoint, it satisfies
the requirements by implementing at least one mechanism other than an API. Note: The checkpoints
outside of
guideline 6 may be satisfied by assistive technologies as well, but are
required by the current document to be satisfied by a conforming user agent.
For example,
checkpoint 9.3 involves navigation that must be possible through the user
interface, not just via an API. Note that an assistive technology may be part
of the subject of a claim.
These requirements together form the "default" set of conformance requirements.
To allow user agents with different capabilities to conform, and to
facilitate comparisons of claims about different user agents, this document
defines allows conditional conformance. A user agent conforms conditionally if
it satisfies any set of requirements that results from starting with the default set of requirements and removing or adding
requirements according to these steps:
- Choose a conformance level; conformance
levels A or Double-A remove requirements from the default set.
- Remove the requirements associated with any unsupported content type labels. In order to conform
conditionally, a user agent must satisfy the requirements of at least one
content type label.
- Add requirements associated with any supported input modality label. Note:
In the default set of requirements, the only input device requirements relate
to keyboard input.
- If the user agent does not implement a selection
mechanism, remove the requirements of any checkpoints or parts of checkpoints
associated with the selection label.
- Remove the requirements of any checkpoints or parts of checkpoints that do
not apply.
Since these steps may produce very different sets of checkpoints for
different user agents, a well-formed conformance
claim must indicate how the set of requirements chosen for the claim
differs from the default set. The checklist
[UAAG10-CHECKLIST] may
prove useful when documenting the details of a conditional conformance
claim.
The following example illustrates how to apply the above steps to determine
which requirements must be satisfied for conformance, and what would be
required as part of a well-formed conformance claim. This
informative example does not illustrate a complete user agent
evaluation.
Consider a user agent with these capabilities:
- it supports keyboard and pointing device input;
- it renders text (in color) and implements:
- one audio format,
- two image formats,
- two other animation formats (besides video, which is considered an
animation format in this document);
- it feeds video to a plug-in for rendering;
- it doesn't support synthesized speech output;
- it implements a selection mechanism.
Step 1: Choose a conformance level.
The claimant wishes to conform at level Double-A. This establishes a set of
requirements consisting of all of the requirements of all the priority 1 and 2
checkpoints.
Step 2: Remove the requirements associated with any
unsupported content type labels.
The claimant wishes to claim conformance for the user agent's support of
text, images, audio, and video. The claimant does not wish to claim conformance
for other animation
formats.
The following content type labels are therefore relevant: VisualText,
ColorText, Image, Animation, Video, and Audio. This means that:
- the claimant must remove the set of requirements associated with the Speech
content type label.
- the claimant must satisfy the requirements associated with the other
content type labels.
Step 3: Remove the requirements of any checkpoints or parts of
checkpoints that do not apply.
Consider checkpoint 4.4, for example, which is associated with both the
Audio and Animation content type labels:
4.4 Slow multimedia.
(P1)
- Allow the user to slow the presentation rate of rendered audio and
animations (including video and animated images).
- For a visual
track, provide at least one setting between 40% and 60% of the
original speed.
- For a prerecorded audio
track including audio-only presentations, provide at least one
setting between 75% and 80% of the original speed.
- When the user agent allows the user to slow the visual track of a
synchronized multimedia presentation to between 100% and 80% of its original
speed, synchronize the visual and audio tracks. Below 80%, the user agent is
not required to render the
audio track.
- The user agent is not required to satisfy this checkpoint for audio and
animations whose
recognized role is to create a purely stylistic effect.
Suppose that:
- The claimant wishes to claim support for the two image formats, the one
audio format, and the one video format;
- The claimant does not wish to claim support for the other two animation
formats (e.g., because the user agent doesn't satisfy the requirements of checkpoint 4.4
for those animation formats);
- The user agent does not implement any synchronized multimedia formats.
The resulting applicable requirements from this checkpoint would be:
- For the audio format: Allow the user to slow the presentation rate of
audio. For a prerecorded audio track including audio-only presentations,
provide at least one setting between 75% and 80% of the original speed.
- For the video format: Allow the user to slow the presentation rate of
video. For a visual track, provide at least one setting between 40% and 60% of
the original speed.
- For the image formats: None, since the Image content type label does not
include
checkpoint 4.4.
- Limitation of scope for any format: The user agent is not required to
satisfy the requirements of this checkpoint for audio and animations whose
recognized role is to create a purely stylistic effect.
The following requirements would not apply:
- When the user agent allows the user to slow the visual track of a
synchronized multimedia presentation to between 100% and 80% of its original
speed, synchronize the visual and audio tracks. Below 80%, the user agent is
not required to render the audio track. Note: The relevant applicability provision is provision three: control of a
content property that the subject cannot recognize. In this case, no format
implemented by the user agent supports synchronized multimedia.
Step 4: Add requirements related to the selection.
In this example, since the user agent implements a selection
mechanism, it must satisfy the requirements associated with the selection label.
Step 5: Add requirements associated with any supported input
modality label.
In this example, the claimant does not wish to claim conformance for
complete operation for pointing device or voice input, so no requirements are
added.
Construct a well-formed conformance claim.
The following information is an excerpt of that required for a well-formed
claim:
- Conformance level satisfied: Double-A
- Information about the subject. Both the "main" user agent and the
plug-in used to support video must be
identified in the claim (since the plug-in is the component used to satisfy the
requirements for video).
The user agent does not conform
unconditionally, therefore, the claim must also include the following
information (excerpted from a complete claim):
- A general statement about lack of support for the Speech content type
label: "This user agent does not support the requirements of the Speech content
type label. "
- A specific statement about content type support for checkpoint 4.4:
"This user agent satisfies the requirements of the Animation content type label
for the audio format A and the video format V. It does not satisfy the
Animation requirements for animation formats Y and Z."
- A specific statement about applicability for checkpoint 4.4:
"The synchronized multimedia requirements of checkpoint checkpoint 4.4
do not apply because the user agent does not implement any formats that support
synchronized multimedia."
The following normative subsections provide detail that is relevant to both
unconditional and conditional conformance.
The requirements of certain checkpoints might apply equally well to content
or to user agent user interface features. When it is necessary to remove
ambiguity about the scope of a checkpoint, the checkpoint includes a label to
indicate whether the requirements must be satisfied:
- for content
only, i.e., the document
object only;
- for rendered
content only;
- for user agent features only, i.e., everything that is not
content (such as components of the user
agent user interface, user preferences, the user agent
documentation, and the user interface focus);
- for both content and user agent features.
Many of the content-only and rendered content-only requirements also make
sense for the user agent user interface (e.g., allow the user to render
blinking text as motionless text). User agent developers are encouraged to
consider the content-only requirements when designing the user agent's user
interface.
The user agent may satisfy a content-only or rendered content-only
requirement with a mechanism that also involves user agent features.
For instance, to satisfy checkpoint 4.9, the user agent may provide a single control
for all volume (including content and user interface features). Similarly, to
satisfy
checkpoint 3.3, the user agent may offer a single configuration that turns
off blinking in both content and the user interface.
A user agent may conform by satisfying the checkpoint requirements of this
document for some, but not all,
implemented specifications and
APIs. For example, a developer may
implement ten image formats but only wish to claim "Image" conformance for three of them.
In particular, the following requirements may be satisfied for some but not
all implemented specifications:
The user agent may satisfy the configuration requirements of this document
through configuration files (e.g., profiles, initialization files, themes,
etc.). For instance, style sheets might be used as a mechanism to satisfy the
highlight and configuration requirements of checkpoints 10.2
and 10.4.
Any functionality that is configurable through a configuration file should also
be configurable through the user
agent user interface. Furthermore, if configuration files may be
edited by hand, the user agent documentation should explain the configuration
file format, or refer to an explanation (such as a format specification).
For some of the checkpoints in this document (checkpoint
3.3,
checkpoint 5.1, checkpoint 5.3, checkpoint 5.5,
checkpoint 5.6),
configuration is preferred, but not required to satisfy the checkpoint in some
circumstances. For other checkpoints, the configuration requirement is
considered as important as the functionality being configured.
Since this document allows conformance by multiple software components
(e.g., a browser, a media player, and several plug-ins), there are likely to be
times when, to satisfy the configuration requirements of the document, each
component has to provide for configuration independently. To make configuration
easier for the user, components should share and inherit configurations
(including from the operating environment).
To satisfy the requirements of this document, developers are encouraged to
adopt
operating environment conventions and features that benefit
accessibility. When an operating environment feature (e.g., the operating
system's audio control feature, including its user interface) is adopted to
satisfy the requirements of this document, it is part of the subject of the claim.
Developers may provide access through the user agent's user interface to
operating environment features adopted to satisfy the requirements of this
document. For example, if the user agent adopts the operating system's audio
control feature to satisfy checkpoint
4.9, the user agent may (but is not required to) include those controls in
its own user interface.
Some of the checkpoints in this document involve operating environment
conventions. When a user agent runs in more than one operating environment
(e.g., a user agent implemented in Java on top of another operating system),
developers may satisfy the requirements of this document by following the
conventions of a single operating environment. Developers should follow the
conventions that benefit accessibility most, while meeting the developers'
design goals. For instance, some developers may prefer cross-platform
consistency over consistency with other user agents running in a given
operating environment, and this might affect which conventions would be
preferred.
User agents do not conform to this document on a per-resource basis; claims
are not as specific as "the user agent conforms for this particular Web page."
A user agent conforms if it satisfies the requirements of this document for
most general-purpose content, in ordinary operating conditions.
In some cases, an author may wish to limit the user agent's functionality
for specific reasons, such as to protect intellectual property rights, for
security reasons, or to provide a read-only view (allowing no user
interaction). Content that limits the functionality of the user agent in some
cases does not automatically invalidate a conformance claim. A valid
conformance claim remains valid as long as the user agent is capable of
satisfying the requirements of the document (i.e., the functionalities have
been implemented), and does so for most general-purpose content.
Note: The User Agent Accessibility Guidelines Working Group
recognizes that further work is necessary in the area of digital rights
management as it relates to accessibility. Digital rights management refers to
methods of describing and perhaps enforcing intellectual property associated
with Web resources.
Each conformance level defines a set of requirements, based on priority.
Note: Conformance levels are spelled out in text (e.g.,
"Double-A" rather than "AA") so they may be understood when rendered as
synchronized speech.
Each content type label defines a set of requirements related to support for
images, video, animations generally, visually displayed text (in color), and
synthesized speech.
- VisualText
- This content type label refers to all of the requirements related to the
visual rendering of text for the following checkpoints: 3.3, 4.1, and 4.2. To
conform, the user agent must support
visually rendered text.
- ColorText
- This content type label refers to all of the requirements related to text
foreground and background color for the following checkpoint: 10.4. To
conform, the user agent must support
more than one text foreground color and more than one text background
color.
-
Image
- This content type label refers to all of the requirements related to images
(excluding animated images) for the following checkpoints: 3.1,
and 3.7. To
conform, the user agent must
implement at least one image format. The image requirements apply to
content that is
recognized as distinct and that, according to the encoding format,
may be rendered as a coherent unit.
- Animation
- This content type label refers to all of the requirements related to
animations (including video and animated images) for the following
checkpoints: 3.2, 4.4, 4.5, 4.7, and 4.8. To
conform, the user agent must
implement at least one animation format. The animation requirements
apply to animation content that is
recognized as distinct and that, according to the encoding format,
may be rendered as a coherent unit.
-
Video
- This content type label refers to all of the requirements related to video
for the following checkpoints: 2.5, 2.6, and 3.2. To
conform, the user agent must
implement at least one video format. The video requirements apply to
video content that is
recognized as distinct and that, according to the encoding format,
may be rendered as a coherent unit.
-
Audio
- This content type label refers to all of the requirements related to audio for the following checkpoints: 2.5, 2.6, 3.2, 4.4, 4.5, 4.7, 4.8, 4.9, 4.10,
and 4.11
To conform, the user agent must
implement at least one audio format. The audio requirements apply to
audio content that is
recognized as distinct and that, according to the encoding format,
may be rendered as a coherent unit.
- Speech
- This content type label refers to all of the requirements related to
synthesized speech for the following checkpoints: 4.12, 4.13,
4.14,
4.15, and 4.16. To conform, the user agent must
support synthesized speech.
Note: Some of the labels above require implementation of at
least one format (e.g., for images). This document does not require
implementation of specific formats, (e.g., PNG [PNG]
versus SVG [SVG] for images). However, please see
the requirements of checkpoint 8.2.
Each input modality label defines a set of requirements related to support
for pointing device and voice input. Input device requirements in this document
are either stated generically (e.g., "input configuration" requirements) or as
keyboard-specific requirements (e.g., "keyboard API").
-
Pointer
- This input modality label refers to all of the input device requirements of
this document, applied to pointing device input. For keyboard-specific
requirements, substitute "pointing device input" for "keyboard." The set of
pointing device input requirements does not include the requirements of checkpoint 11.4.
-
Voice
- This input modality label refers to all of the input device requirements of
this document, applied to voice input. For keyboard-specific requirements,
substitute "voice input" for "keyboard." The set of voice input requirements
does not include the requirements of checkpoint 11.4.
Note: Developers are encouraged to design user agents that
are at least partially operable through all three input modalities.
This document does not require the user agent to implement a selection
mechanism in order to conform. However, if the user agent does implement a
selection mechanism, in order to conform it must satisfy the relevant portions
of the following checkpoints: 6.5, 7.1,
9.4, 10.2,
10.3, and
5.4.
The Selection label refers to the selection
requirements of these checkpoints.
If a user agent does not implement a selection mechanism, then a well-formed claim must say so.
Note: This document does require implementation of both content
focus and user
interface focus; see checkpoint 9.1
and checkpoint
9.2.
A checkpoint (or part of a checkpoint) applies unless any one of the
following conditions is met:
- The checkpoint makes requirements for graphical user interfaces or
graphical viewports and the subject of the claim only has audio or tactile user
interfaces or viewports.
- The checkpoint refers to a role of content (e.g., transcript, captions,
associated
conditional content, fee
link, synchronization cue, client-side redirect, purpose of a table,
etc.) that the subject of the claim cannot recognize
because of how the content has been encoded in a particular format. For
instance, HTML user agents can recognize "
alt",
OBJECT content, or NOFRAMES content as specified mechanisms
for
conditional content. HTML user agents are not expected to recognize
that a nearby paragraph is a text
equivalent for the image (when not marked up as such).
- The checkpoint requires control of a content property that the subject
cannot recognize
because of how the content has been encoded in a particular format. Some
examples of this include:
- captioning information that is "burned" into a video presentation and
cannot be recognized as captions in the presentation format;
- streamed content that cannot be fast advanced or reversed;
- information encoded in an unrecognized XML namespace;
- information or relationships encoded in
scripts in a manner that cannot be recognized. For instance, the
requirements of checkpoint 3.3 would not apply for animation effects
unrecognized in a script. Some input device behavior may be controlled by
scripts in a manner that the user agent cannot recognize. For example, when the
author uses event
bubbling to dispatch events, the user agent is not likely to
recognize the full set of elements that may receive those events; the user
agent is expected to recognize which element has the explicitly associated event handler.
A claim is well-formed if meets the following conditions.
Condition 1: The claim must include the following information:
- The date of the claim.
- The guidelines title/version: "User Agent Accessibility Guidelines
1.0".
- The URI of the guidelines:
http://www.w3.org/WAI/UA/WD-UAAG10-20010831.
- The conformance level satisfied: "A",
"Double-A", or "Triple-A".
- Information about the subject. The subject of the claim may consist of one
or more software components (e.g., a browser plus a multimedia player plus a
plug-in). For each component, the claim must include the following:
- The user agent name and version information. Version information must be
sufficient to identify the user agent (e.g., vendor name, version number, minor
release number, required patches or updates, natural language of the user
interface or documentation). The version information may refer to a range of
user agents (e.g., "this claim refers to all user agents version 6.x").
- The name and version number of the
operating environment(s) in which the user agent is running.
- If a conformance icon is part of a claim
on the Web, it must link to the W3C explanation of the icon.
Condition 2: The claim must include the following information if the user
agent conforms conditionally:
- Content type labels. Content type labels
are used in assertions that the subject either (1) does not satisfy the
requirements associated with the label (e.g., for a specific checkpoint, for
any checkpoint, etc.), or (2) does satisfy the requirements associated with the
label (e.g., for a particular format when satisfying the requirements of a
checkpoint). In order to conform conditionally, a user agent must satisfy the
requirements of at least one content type label.
- Input modality labels. Each input
modality label ("Pointer" or "Voice") is an assertion that the user agent
satisfies the requirements associated with the label.
- Selection label. If the user agent does not
implement a selection
mechanism, the claim must say so.
- A list of requirements (checkpoints or portions of checkpoints) that the
claim asserts do not apply.
Condition 3: At least one version of the claim must conform to the "Web
Content Accessibility Guidelines 1.0"
[WCAG10], level A. This claim may appear on the Web, on a CD-ROM,
etc.
A well-formed claim should also include the following information:
This specification imposes no restrictions on the format used to make a well-formed claim. For instance,
the claim may be marked up using HTML (see sample
claim), or expressed in the Resource Description Framework
(RDF) [RDF10].
A conformance claim is valid if the following conditions are met:
- The claim is well-formed.
- It is verified that the user agent satisfies the default set of requirements, in addition to (or
except) those requirements added (or exempted) by the allowable mechanisms: conformance levels, content type labels, input modality labels, and applicability.
It is not currently possible to validate a claim entirely automatically.
Notes:
- The subject of the claim may consist of more than one software component,
and taken together they must satisfy all requirements that are not excluded
through the claim. These components may run on the user's computer or on a
server. This includes assistive technologies and
operating environment features that are part of a claim. Some
components may not have to satisfy some requirements as long as the subject
as a whole satisfies them. For instance, a particular component of the
subject may not have to conform to the DOM APIs required by guideline 6
as long as the subject of the claim as a whole makes all content
available through those APIs.
- The document has been designed so that non-experts can determine the
validity of a claim. In some cases, a requirement might be clear, but without
documentation or feedback from developers (e.g., about implemented APIs), it may be difficult to verify that the
subject of the claim has satisfied the
requirement. Some checkpoints (e.g., those requiring developers to follow
conventions or implement specifications defined outside this document) are
inherently more open to interpretation than others.
- Ideally, the default user agent installation procedure should provide and
install all components that are part of a conformance claim. This is because,
the more software components the user must install in order to construct a
conforming user agent, the higher the risk of failure. Failure may be due to
inaccessible mechanisms for downloading and installing
plug-ins, or lack of installation access
privileges for a computer in a public space, etc.
This specification imposes no restrictions about:
- who may make a claim (e.g., vendors about their own user agents, third
parties about those user agents, journalists about user agents, etc.), or
- where claims may be published (e.g., on the Web or in paper
documentation).
Claimants (or relevant assuring parties) are solely responsible for the
validity of their claims, keeping claims up to date, and proper use of the conformance icons. As of the publication of this
document, W3C does not act as an assuring party, but it may do so in the
future, or it may establish recommendations for assuring parties.
Claimants are expected to modify or retract a claim if it may be
demonstrated that the claim is not valid. Claimants are encouraged to claim
conformance to the most recent User Agent Accessibility Guidelines
Recommendation available.
As part of a conformance claim, people may use a conformance icon (or,
"conformance logo") on a Web site, on user agent packaging, in documentation,
etc. A conformance icon does not represent that a claim is valid, only that a claim has been made. The
appearance of a conformance icon does not imply that W3C has reviewed the
claim.
It is inappropriate and meaningless to use a conformance icon on its own,
i.e., to use the icon without an associated
well-formed claim.
Draft Note: In the event this document becomes a W3C
Recommendation this document will link to the W3C Web site for additional
information about the icons and how to use them.