User Agent Accessibility Guidelines 1.0
22 June 2001
This normative
section defines what it means to conform to this document and explains how to
make a valid conformance claim. Please note
that this document includes both conformance requirements and conformance claim
requirements.
Here is a sample claim (expressed in
HTML):
<p>On 22 June
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/TR/2001/WD-UAAG10-20010622, 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>
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]. This section uses the expression "subject of a claim" to refer to a user
agent about which someone wishes to claim some level of conformance
to this document. The subject of a claim may be one or more software components
(e.g., a browser plus additional software).
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. Please refer to the
section on known limitations of this
document.
The conformance model of this document has been designed to allow different
types of user agents with different input and output capabilities to conform.
At the same time, the model is designed so that:
- people reading claims can determine whether a conforming user agent is
likely to meet their accessibility needs, and
- people can compare claims about different user agents with relative ease.
Note: The checklist [UAAG10-CHECKLIST] may be
used when evaluating a user agent for conformance.
The conformance model works as follows:
- A user agent conforms to this document by satisfying a set of requirements.
Conformance requirements only come from the checkpoint
statements. Each checkpoint statement includes one or more requirements.
- The "default" set of
requirements for conformance consists of all the requirements of all of the
checkpoint statements. A user agent conforms unconditionally to this document if it
satisfies all of these requirements.
- Different user agents may conform to different sets of checkpoints. A user
agent conforms conditionally if it
satisfies any set of requirements that results from carrying out the four steps
below. Since these steps may produce very different sets of checkpoints for
different user agents, a valid conformance
claim must indicate how the set of requirements chosen for the claim
differs from the default set.
A user agent conforms conditionally if it satisfies any set of
requirements that results from following these steps:
- Choose a conformance level. Each
conformance level corresponds to a set of checkpoints (and thus a set of
requirements).
- 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.
- Remove the requirements of any checkpoints or parts of checkpoints that do
not apply.
- 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.
- 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.
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 hands off video to be rendered by a plug-in;
- it doesn't support 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 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 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."
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
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.
- ColorText
- This content type label refers to all of the requirements related to text
foreground and background color for the following checkpoint: 10.4.
-
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.
- 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.
-
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.
-
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.
- 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 (though 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/TR/2001/WD-UAAG10-20010622.
- 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
operating environment (e.g., operating system) name and version
number.
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. 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. Each conformance icon (chosen according to the appropriate conformance level) used on the Web must link to
the W3C explanation of the icon. The appearance of a conformance icon does not
imply that W3C has reviewed or validated the claim. An icon must be accompanied
by a 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.
The following sections describe additional conformance requirements and
exemptions.
User agents may conform (both
unconditionally and conditionally)
by satisfying the the specification 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:
Each checkpoint definition indicates whether the requirements of the
checkpoint must be satisfied by the subject of the claim for:
- content
only, i.e., the document
object.
- user agent features only, i.e., everything besides the document object
(e.g., components of the user
agent user interface, the user agent
documentation, and the user interface focus).
- both content and user agent features.
Many of the 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" 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.
Note. Depending on the checkpoint, content
focus and selection
requirements may have any of the three labels. Content focus and selection are
"state variables" that straddle both worlds of content and user agent user
interface.
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.
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).
The requirements of guideline 6 must be satisfied by implementing APIs.
The requirements of the other guidelines must be satisfied by at least one
mechanism other than an API. These requirements are not meant
to be satisfied by assistive technologies (unless those technologies are part
of a conformance claim). For example, checkpoint 9.3
involves navigation that must be possible through the user interface, not just
via an API.
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.
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.