User Agent Accessibility Guidelines 1.0
8 July 2002
The twelve guidelines in this document state general principles for the
development of accessible user agents. Each guideline includes:
- The guideline number.
- The guideline title.
- The rationale behind the guideline and identification of some groups of
users who benefit from it.
- A list of checkpoint definitions. This list may be split into groups of
related checkpoints. For instance, the list might be split into one group of
"checkpoints for visually rendered text" and second group of "checkpoints for
audio volume control"." Within each group, checkpoints are ordered according to
their priority, e.g., Priority 1 before Priority 2.
Within a guideline, checkpoint groupings and checkpoint order have no bearing
on conformance.
Each checkpoint definition includes the following parts. Some parts are normative (i.e., relate to conformance);
others are informative only.
- The checkpoint number.
- The checkpoint title. This title is not a requirement, just a phrase to
help readers remember an important requirement made by the checkpoint
provision(s). (Informative)
- The priority of the checkpoint. (Normative)
- A link to the Techniques document
[UAAG10-TECHS] for more information about the checkpoint: rationale,
who benefits, example techniques, references, and more. (Informative)
- The checkpoint provisions, which include one or more requirements that must
be satisfied by the user agent (i.e., the subject of the claim) for conformance. (Normative)
- Optional: Techniques that are sufficient for satisfying
all or part of a checkpoint provision. (Normative)
- Optional: Normative inclusions and exclusions. These are
normative qualifications about what is required (inclusion) or is not required
(exclusion) to satisfy the checkpoint. Two important types of inclusions that
may appear are:
- A "content/rendered content/user
agent feature/both" label that indicates whether the requirements of the
checkpoint must be satisfied by the subject of the claim for all content, all rendered content, for user agent
features only, or for both content and user agent features. The label only
appears when necessary to disambiguate the checkpoint.
- Content type labels,
which are explained in the section on
conformance.
(Normative)
- Optional: Notes about the checkpoint (beginning with the
word "Note"). The notes clarify the scope of the checkpoint
through further description, examples, cross references, and commentary. Some
checkpoints in this document are more general than others, and some may overlap
in scope. Therefore, a checkpoint may be identified as a "special case" or an
"important special case" of one or more other checkpoints. (Informative)
Note: A user agent may conform to this document without
satisfying every checkpoint. See the section on conditional conformance for
more information about how to eliminate some checkpoints and still conform.
Each checkpoint definition expresses one or more requirements. These
requirements are not technology specific. In fact, they have been designed to
be largely technology independent, in order to make sense for a variety of
existing and future technologies. The Techniques document [UAAG10-TECHS] is an
important resource to help developers understand how to "apply" the
requirements to HTML, CSS, SMIL, and SVG, and several operating environments.
The User Agent Accessibility Guidelines Working Group welcomes comments and
anticipates discussion on how to apply these requirements to new technologies
in different operating environments.
Each requirement is a "minimal" requirement, which means that for
conformance, the user agent is required to satisfy no more than the stated
requirement. In many cases, however, it may be easier or less costly (or just
be better design) to implement a general feature that satisfies more than a
minimal requirement. One general solution might satisfy five checkpoints and be
easier to implement than five disconnected features. For instance, a navigable
structure view of content that allows users to query elements for their
properties is likely to benefit all users and may be used to satisfy a number
of requirements of this document.
Some requirements have a wider impact than others. For instance, the
keyboard requirements of
checkpoint 1.1 have an impact on all other requirements in the document
related to user input: any requirement that involves user input must be
satisfied through the keyboard. Because the keyboard requirements of checkpoint 1.1 have been
factored out, the other checkpoints are shorter; they are written "Allow
configuration" instead of "Allow configuration through the keyboard."
First-time readers of the document are encouraged to read the full context
provided for each checkpoint, including the guideline prose, the surrounding
checkpoints (since nearby checkpoints are generally related), notes after
checkpoints, and associated techniques (in the Techniques document
[UAAG10-TECHS]). The checklist [UAAG10-CHECKLIST] is
also a useful tool (e.g., for evaluating a user agent for conformance), but
does not provide the same contextual support.
Each checkpoint in this document is assigned a priority that indicates its
importance for users with disabilities.
- Priority 1
(P1)
- This checkpoint must be satisfied by user agents,
otherwise one or more groups of users with disabilities will find it impossible
to access the Web. Satisfying this checkpoint is a basic requirement for
enabling some people to access the Web.
- Priority 2
(P2)
- This checkpoint should be satisfied by user agents,
otherwise one or more groups of users with disabilities will find it difficult
to access the Web. Satisfying this checkpoint will remove significant barriers
to Web access for some people.
- Priority 3
(P3)
- This checkpoint may be satisfied by user agents to make it
easier for one or more groups of users with disabilities to access information.
Satisfying this checkpoint will improve access to the Web for some people.
Since people use a variety of devices for input and output, user agent
developers need to ensure redundancy in the user interface. The user may have to
operate the user interface with a variety of input devices (keyboard, pointing
device, voice input, etc.) and output modalities (e.g., graphical, speech, or braille
rendering).
Though it may seem contradictory, enabling full user agent operation through
the keyboard is an important part of promoting device-independence given
today's user agents. In addition to the fact that some form of keyboard is
supported in most operating environments, there are several reasons for
this:
- For some users (e.g., users with blindness or physical disabilities),
operating a user agent with a pointing device may be difficult or impossible
since it requires tracking the pointing device position in a two-dimensional
visual space. Keyboard operation does not generally require as much movement
"through space".
- Some assistive technologies that support a diversity of input and output
mechanisms use keyboard APIs for communication with some
user agents; see checkpoint
6.7. People who cannot or do not use a pointing device may interact with
the user interface with the keyboard, through voice input, a head wand, touch
screen, or other device.
While this document only requires keyboard operation for conformance, it promotes input device
independence by also allowing people to claim conformance for full pointing
device support or full voice support.
As a way to promote output device independence, this guideline requires
support for text messages in the user interface because text may be rendered
visually, as synthesized speech, and as braille.
The API requirements of
guideline 6 also promote device independence by ensuring communication with
specialized software.
Checkpoint definitions
- Ensure that the user can operate
through keyboard input alone any user agent functionality available through the
user interface.
Note: User agents may support at least two types of
keyboard access to functionalities: direct access (where user awareness of a
location "in space" is not required, as is the case with keyboard shortcuts and
navigation of user agent menus) and spatial access (where the user moves the
pointing device "in space" via the keyboard). To satisfy this checkpoint, user
agents are expected to provide a mix of both types of keyboard access. User
agents should allow direct keyboard access where possible, and this may be
redundant with spatial input techniques. Furthermore, the user agent should
satisfy this requirement by offering a combination of keyboard-operable user
interface controls (e.g., keyboard operable print menus and settings) and
direct keyboard operation of user agent functionalities (e.g., a short cut to
print the current page). As examples of functionalities, ensure that the user
can interact with enabled elements, select content,
navigate viewports, configure the user agent, access documentation, install the
user agent, operate controls of the user interface, etc., all entirely through
keyboard input. It is also possible to claim conformance to this document for full
support through pointing device input and voice input. See the section on Input modality labels.
- Allow the user to activate, through keyboard input alone, all
event handlers of any input
device event type that are explicitly associated with the element designated by
the content focus.
- In order to satisfy provision
one, the user must be able to activate as a group all event handlers of the
same input device event type.
Normative inclusions and exclusions
- The user agent is not required to allow activation of event handlers
associated with a given device (e.g., the pointing device) in any order other
than what the device itself allows (e.g., a mouse down event followed by a
mouse drag event followed by a mouse up event).
- The requirements for this checkpoint refer to any
explicitly associated input device event handlers associated with an
element, independent of the
input modalities for which the user agent conforms. For example, suppose
that an element has an explicitly associated handler for pointing device
events. Even when the user agent only conforms for keyboard input (and does not
conform for the pointing device, for example), this checkpoint requires the
user agent to allow the user to activate that handler with the keyboard.
- Conformance labels: Events.
Note: This checkpoint is an important special case of checkpoint 1.1. Please
refer to the checkpoints of guideline
9 for more information about focus requirements.
-
Ensure that every message (e.g.,
prompt, alert, notification, etc.) that
is a non-text element and
is part of the user agent user
interface has a text equivalent.
Note: For example, if the user is alerted of an event by an
audio cue, a visually-rendered text equivalent in the status bar could satisfy
this checkpoint. Per checkpoint
6.5, a text equivalent for each such message must be available through an
API. See also
checkpoint 6.6 for
requirements for programmatic notification of changes to the user
interface.
The checkpoints in this section require the user agent to provide access to
all content through a series of complementary mechanisms designed so that if
one fails, another will provide some access. The following preferences are
embodied in the checkpoints:
- Both manual and automatic selection of which conditional content to render are
important to accessibility.
- Both structured navigation and unstructured access to content are important
to accessibility.
- Rendering according to format specification is preferred, but a source view
of text content may be necessary for access (e.g., because of user-side error
conditions, authoring errors, inadequate specification, or incorrect user agent
implementation). For example, the user may have to look at
URIs for information, HTML comments,
XML element names, or script data. The user agent should respect
authoring synchronization cues for content that changes over time, but also
needs to allow the user to control the time intervals when user input is
possible.
- Configuration and control of rendering are important for access.
Authors may use the conditional content mechanisms of
a specification to satisfy the requirements of the Web Content Accessibility
Guidelines 1.0 [WCAG10]. Ensuring access to conditional
content benefits all users since some users may not have access to some
content due to a technological limitation (e.g., their mobile browser cannot
display graphics) or simply a configuration preference (e.g., they have a slow
Internet connection and prefer not to download movies or images).
Checkpoint definitions
- Render
content according to format specification (e.g., for a markup language or
style sheet language).
Normative inclusions and exclusions
- Rendering requirements include format-defined interactions between author
preferences and user preferences/capabilities (e.g., when to render the
"
alt
" attribute in HTML, the
rendering order of nested OBJECT
elements in HTML, test attributes
in SMIL, and the cascade in CSS2).
- When a rendering requirement of another specification contradicts a
requirement of the current document, the user agent may disregard the rendering
requirement of the other specification and still satisfy this checkpoint.
- The user agent is not required to satisfy this checkpoint for all
implemented specifications; see the section on conformance and implementing
specifications for more information.
Note: If a conforming user agent does not render a content
type, it should allow the user to choose a way to handle that content (e.g., by
launching another application, by saving it to disk, etc.).
- For
content authored in text formats, provide a
view of the text source. For the
purposes of this checkpoint, a text format is any media object given an
Internet media type of "text" (e.g., text/plain, text/html, or text/*) as
defined in RFC 2046 [RFC2046], section 4.1.
Normative inclusions and exclusions
- The user agent is only required to satisfy this checkpoint for text formats
that are part of a conformance claim; see the section on conformance and implementing
specifications for more information. However, user agents should provide a
text view for all implemented text formats. A user agent would also satisfy
this checkpoint by providing a source view for any text format, not just
implemented text formats.
- Allow configuration to provide access to each
piece of unrendered conditional content "C".
- When a specification does not explain
how to provide access to this content, do so as follows:
- If C is a summary, title, alternative, description, or expansion of another
piece of content D, provide access through at least one of the following
mechanisms:
- (1a) render C in place of D;
- (2a) render C in addition to D;
- (3a) provide access to C by allowing the user to query D. In this case, the
user agent must also alert the user, on a per-element basis, to the existence
of C (so that the user knows to query D);
- (4a) allow the user to follow a link to C from the context of D.
- Otherwise, provide access to C through at least one of the following
mechanisms:
- (1b) render a placeholder for C, and
allow the user to view the original author-supplied content associated with
each placeholder;
- (2b) provide access to C by query (e.g., allow the user to query an element
for its attributes). In this case,
the user agent must also alert the user, on a per-element basis, to the
existence of C;
- (3b) allow the user to follow a link in context to C.
Sufficient techniques
- To satisfy provision one, the configuration may be a switch that, for all
content, turns on or off the access mechanisms described in provision two.
- To satisfy provision two, the user agent may provide access on a
per-element basis (e.g., by allowing the user to query individual elements) or
for all elements (e.g., by offering a configuration to render conditional
content all the time).
Note: For instance, an HTML user agent might allow users to
query each element for access to conditional content supplied for the
"alt
", "title
", and "longdesc
"
attributes. Or, the user agent might allow configuration so that the value of
the "alt
" attribute is rendered in place of all IMG
elements (while other conditional content might be made available through
another mechanism).
- For rendered content where user input is
only possible within a finite time interval controlled by the user agent, allow
configuration to provide a view where user
interaction is time-independent.
Sufficient techniques
- The user agent may satisfy this checkpoint by pausing processing
automatically to allow for user input, and resuming processing on explicit user request. When
this technique is used, pause at the end of each time interval where user input
is possible. In the paused state:
- Alert the user that the rendered content has been paused
(e.g., highlight the "pause" button in a multimedia player's control
panel).
- Highlight which enabled elements are
time-sensitive.
- Allow the user to interact with the enabled elements.
- Allow the user to resume on explicit user request (e.g., by
pressing the "play" button in a multimedia player's control panel; see also checkpoint 4.5).
- The user agent may satisfy this checkpoint by generating a
time-independent ("static") view, based on the original
content, that offers the user the same opportunities for interaction. The
static view should reflect the structure and flow of the original
time-sensitive presentation; orientation cues will help users understand the
context for various interaction opportunities.
Normative inclusions and exclusions
- When satisfying this checkpoint for a real-time presentation, the user
agent may discard packets that continue to arrive after the construction of the
time-independent view (e.g., when paused or after the construction of a static
view).
- This checkpoint does not apply
when the user agent cannot recognize the time interval in the
presentation format, or when the user agent cannot control the timing (e.g.,
because it is controlled by the server).
Note: If the user agent satisfies this checkpoint by
pausing automatically, it may be necessary to pause more than once when there
are multiple opportunities for time-sensitive user interaction. When pausing,
pause synchronized content as well (whether rendered in the same or different
viewports) per checkpoint
2.6. In SMIL 1.0 [SMIL], for example, the
"begin
", "end
", and "dur
" attributes synchronize presentation
components. See also checkpoint 3.5, which involves client-driven content
retrieval.
- Allow configuration or
control to render text transcripts, collated text
transcripts, captions, and audio descriptions at the same time
as the associated audio tracks and visual tracks.
Note: This checkpoint is an important special case of checkpoint 2.1.
- Respect synchronization cues (e.g., in
markup) during rendering.
Normative inclusions and exclusions
- Conformance labels: Video, Audio.
Note: This checkpoint is an important special case of checkpoint 2.1.
-
Allow configuration to generate repair text when the user agent recognizes that the author has failed to
provide conditional
content that was required by the format specification.
Sufficient techniques
- The user agent may satisfy this checkpoint by basing the repair text on any
of the following available sources of information: URI reference, content type,
or element type. Note, however, that additional information that would enable
more helpful repair might be available but not "near" the missing conditional
content. For instance, instead of generating repair text on a simple URI
reference, the user agent might look for helpful information near a different
instance of the URI reference in the same document object, or might retrieve
useful information (e.g., a title) from the resource designated by the URI
reference.
Note: Some markup languages (such as HTML 4
[HTML4] and SMIL 1.0 [SMIL] require the author to provide
conditional content for some elements (e.g., the "alt
" attribute on the IMG
element).
- Allow at
least two configurations for when the
user agent recognizes that conditional
content required by the format specification is present but empty:
Note: In some authoring scenarios, empty content (e.g., a
string of zero characters) may make an appropriate text equivalent, such as when non-text content has no other
function than pure decoration, or when an image is part of a "mosaic" of
several images and doesn't make sense out of the mosaic. Please refer to the
Web Content Accessibility Guidelines 1.0
[WCAG10] for more information about text equivalents.
- Allow configuration to render all conditional
content automatically.
- As part of satisfying
provision one, provide access according to specification, or where unspecified,
by applying one of the techniques described in checkpoint 2.3: 1a, 2a, or
1b.
Normative inclusions and exclusions
- The user agent is not required to render all conditional content at the
same time in a single viewport.
- For all content.
Note: For instance, an HTML user agent might allow
configuration so that the value of the "alt
" attribute is rendered in place of all
IMG
elements (while other conditional content might be made
available through another mechanism). The user agent may offer multiple
configurations (e.g., a first configuration to render one type of conditional
content automatically, a second to render another type, etc.).
- Allow configuration not to render content in
unsupported natural languages,
when that content would otherwise be rendered. Content "in a natural language"
includes pre-recorded spoken language and
text in a given script, i.e., writing
system.
- When configured per provision
one, indicate to the user in context that author-supplied content has not been
rendered.
Normative inclusions and exclusions
- This checkpoint is designed primarily to benefit users who access content
serially, allowing them to skip portions of content that would be unusable if
rendered as "garbage". This checkpoint does not require the user agent to allow
different configurations for different natural languages.
Note: For example, use a text substitute or accessible
graphical icon to indicate that content in a particular language has not been
rendered.
Some content or behavior specified by the author may make the user agent
unusable or may obscure information. For instance, flashing content may trigger
seizures in people with photosensitive epilepsy, or may make a Web page too
distracting to be usable by someone with a cognitive disability. Blinking text
can affect screen reader users, since screen readers (in conjunction with
speech synthesizers or braille displays) may re-render the text every time it
blinks. Distracting background images, colors, or sounds may make it impossible
for users to see or hear other content. Dynamically changing Web content may
cause problems for some assistive technologies. Scripts
that cause unanticipated changes (viewports that open, automatic content
retrieval, etc.) may disorient some users with cognitive disabilities.
This guideline requires the user agent to allow configuration so that, when
loading Web resources, the user
agent does not render content in a manner that might pose accessibility
problems. Requirements for interactive
control of rendered content are part of guideline 4.
Checkpoint definitions
- Allow configuration not to render background
image content.
Sufficient techniques
- The user agent may satisfy this checkpoint with a configuration to not
render any images, including background images. However, user agents
should satisfy this checkpoint by allowing users to turn off background images
alone, independent of other types of images in
content.
Normative inclusions and exclusions
- This checkpoint must be satisfied for all applicable implemented formats; see the
section on conformance and
implementing specifications.
- When configured not to render background images, the user agent is not
required to retrieve them until the user requests them explicitly; see checkpoint 2.3 for
information about access to conditional content.
- This checkpoint only requires control of background images for "two-layered
renderings", i.e., one rendered background image with all other content
rendered "above it".
- Conformance labels: Image.
Note: See checkpoint 2.3 for information about how to provide access
to unrendered background images. When background images are not rendered, user
agents should render a solid background color instead; see checkpoint 4.3.
- Allow configuration not to render audio, video,
or animated image content, except on explicit user request.
Sufficient techniques
- The user agent may satisfy this checkpoint by making video and animated
images invisible and audio
silent, but this technique is not
recommended.
Normative inclusions and exclusions
- This configuration is required for content rendered without any user
interaction (including content rendered on load or as the result of a script),
as well as content rendered as the result of user interaction that is not an explicit user request (e.g.,
when the user activates a link).
- This checkpoint must be satisfied for all applicable implemented formats; see the
section on conformance and
implementing specifications.
- When configured not to render audio, video, or animated images except on
explicit user request, the user agent is not required to retrieve them until
the user requests them explicitly; see checkpoint 2.3 for information about access to conditional
content.
- Conformance labels: Animation, Video, Audio.
Note: See
guideline 4 for additional requirements related to the control of rendered
audio, video, and animated images.
- Allow configuration to render animated or blinking text content as motionless, unblinking text.
Blinking text is text whose visual rendering alternates between visible and
invisible, at any rate of change.
Sufficient techniques
- In this configuration, the user must still have access to the same text
content, but the user agent may render it in a separate viewport (e.g., for
large amounts of streaming text).
- The user agent also satisfies this checkpoint by always
rendering animated or blinking text as motionless, unblinking text.
Note: Animation (a rendering effect) differs from streaming
(a delivery mechanism). Streaming content might be rendered as an animation
(e.g., an animated stock ticker or vertically scrolling text) or as static text
(e.g., movie subtitles, which are rendered for a limited time, but do not give
the impression of movement).
-
Allow configuration not to execute
any executable content (e.g., scripts and
applets).
Normative inclusions and exclusions
- This checkpoint does not apply to
plug-ins and other programs that are not part
of content.
Note: Scripts and applets may provide very useful
functionality, not all of which causes accessibility problems. Developers
should not consider that the user's ability to turn off scripts is an effective
way to improve content accessibility; turning off scripts means losing the
benefits they offer. Instead, developers should provide users with finer
control over user agent or content behavior known to raise accessibility
barriers. The user should only have to turn off scripts as a last resort.
- Allow configuration so that the user agent only
retrieves content on explicit user request.
Normative inclusions and exclusions
- When the user chooses not to retrieve (fresh) content, the user agent may
ignore that content; buffering is not required.
- The user agent is not required to satisfy this checkpoint for "client-side
redirects", i.e., author-specified instructions that a piece of content is
temporary and intermediate, to be replaced by content that results from a
second request. Authors (and Webmasters) should use the redirect mechanisms of
HTTP instead of client-side redirects.
- This checkpoint only applies when the user agent (not the server)
automatically initiates the request for fresh content.
Note: For example, if an HTML author has used a
META
element for automatic content retrieval, allow configuration to
override the automatic behavior with manual confirmation.
-
Allow configuration not to render
image content.
Sufficient techniques
- The user agent may satisfy this checkpoint by making images invisible, but this technique is
not recommended.
Normative inclusions and exclusions
- This checkpoint must be satisfied for all applicable implemented formats; see the
section on conformance and
implementing specifications.
- When configured not to render images, the user agent is not required to
retrieve them until the user requests them explicitly; see checkpoint 2.3 for
information about access to conditional content.
- Conformance labels: Image.
Checkpoints: 4.1,
4.2, 4.3,
4.4, 4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12, 4.13, 4.14
Providing access to content (see guideline 2) includes enabling users to configure and
control its rendering. Users with low vision may require that text be
rendered at a size larger than the size specified by the author or by the user
agent's default rendering. Users with color blindness may need to impose or
prevent certain color combinations.
For dynamic presentations such as synchronized multimedia presentations
created with SMIL 1.0 [SMIL], users with cognitive,
hearing, visual, and physical disabilities may not be able to interact with a
presentation within the time frame assumed by the author. To make the
presentation accessible to these users, user agents rendering multimedia
content (audio, video, and other animations), have to allow the user to
control the playback rate of this content, and also to stop, start, pause, and
navigate it quickly. User agents rendering audio have to allow the user to
control the audio volume globally and to allow the user to control
distinguishable audio tracks.
User agents with speech synthesis capabilities need to allow users to
control various synthesized speech rendering parameters. For instance, users
who are blind and hard of hearing may not be able to make use of high or low
frequencies; these users have to be able to configure their speech synthesizers
to use suitable frequencies.
Checkpoint definitions for visually rendered text
- Allow global configuration of the
scale of visually rendered text. Preserve text size
differences when the user changes the scale.
- As part of satisfying provision one,
provide a configuration option to override rendered text sizes specified by
the author or user agent defaults.
- As part of satisfying provision one,
offer a range of text sizes to the user that includes at least:
- the range offered by the conventional utility available in the operating
environment that allows users to choose the text size (e.g., the font
size), or
- if no such utility is available, the range of text sizes supported by the
conventional
APIs of the operating environment for drawing text.
Sufficient techniques
- The user agent may satisfy provision one of this checkpoint through a
number of mechanisms, including zoom, magnification, and allowing the user to
configure a reference size for rendered text (e.g., render text at 36 points
unless otherwise specified). For example, for CSS2
[CSS2] user agents, the 'medium' value of the 'font-size' property
corresponds to a reference size.
Note: The user agent's default reference size of rendered
text may vary among user agents. Refer, for example to the Scalable Vector
Graphics specification [SVG] for information about scalable
rendering.
- Allow global configuration of the font
family of all visually rendered text, with an option to override font families specified by the
author or by user agent defaults.
- As part of satisfying provision one,
offer a range of font families to the user that includes at least:
- the range offered by the conventional utility available in the operating
environment that allows users to choose the font family, or
- if no such utility is available, the range of font families supported by
the conventional
APIs of the operating environment for drawing text.
Sufficient techniques
- For text that cannot be rendered properly using the
user's preferred font family, the user agent may substitute an alternative font
family.
Note: For example, allow the user to specify that all text is to be rendered in a particular
sans-serif font family.
- Allow global configuration of the
foreground and background color of all visually rendered text, with an option to override foreground and background colors
specified by the author or user agent defaults.
- As part of satisfying provision one,
offer a range of colors to the user that includes at least:
- the range offered by the conventional utility available in the operating
environment that allows users to choose colors, or
- if no such utility is available, the range of colors supported by the
conventional
APIs of the operating environment for specifying colors.
Normative inclusions and exclusions
- Color includes black, white, and greys.
Note: User configuration of foreground and background
colors may inadvertently lead to the inability to distinguish ordinary text
from selected text, focused text, etc. See checkpoint 10.2 for more
information about highlight styles.
Checkpoint definitions for multimedia presentations and other
presentations that change continuously over time
- Allow the user to slow the presentation rate
of rendered audio and animations (including video and animated
images).
- As part of satisfying provision one, for a
visual track, provide at least one
setting between 40% and 60% of the original speed.
- As part of satisfying provision one, 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 (per checkpoint 2.6). Below 80%,
the user agent is not required to render the audio track.
Normative inclusions and exclusions
- The user agent is not required to satisfy this checkpoint for audio and
animations whose recognized role is to create
a purely stylistic effect. Purely stylistic effects include background sounds,
decorative animated images, and effects caused by style sheets.
- Conformance labels: Animation, Audio.
Note: The style exception of this checkpoint is based on
the assumption that authors have satisfied the requirements of the "Web Content
Accessibility Guidelines 1.0" [WCAG10] not to convey information
through style alone (e.g., through color alone or style sheets alone).
- Allow the user to stop, pause, and resume
rendered audio and animations (including video
and animated images) that last three or more seconds at their default playback
rate.
- Allow the user to navigate efficiently
within audio and animations (including video
and animated images) that last three or more seconds at their default playback
rate.
Sufficient techniques
- The user agent may satisfy the navigation requirement of provision two
through forward and backward sequential access techniques (e.g., advance three
seconds), or direct access techniques (e.g., play starting at the 10-minute
mark), or some combination.
Normative inclusions and exclusions
- When serial techniques are used to satisfy provision two, the user agent is
not required to play back content during serial advance or rewind (though doing
so may help orient the user).
- When the user pauses a real-time audio or animation, the user agent may
discard packets that continue to arrive during the pause.
- This checkpoint applies to content that is either rendered automatically
(e.g., on load) or on explicit request from the user.
- The user agent is not required to satisfy this checkpoint for audio and
animations whose recognized role is to create
a purely stylistic effect; see
checkpoint 4.4 for more information about what constitutes a stylistic
effect.
- Conformance labels: Animation, Audio.
Note: Respect synchronization cues, per checkpoint 2.6.
- For graphical viewports, allow configuration so
that captions synchronized with a visual track are not obscured by
it.
Sufficient techniques
- Render captions "on top" of the visual track and, as part of satisfying checkpoint 4.3, allow the
user to configure the foreground and background color of the rendered captions
text.
- Render captions and video in separate viewports so that the user may position
them independently.
Checkpoint definitions for audio volume control
- Allow global configuration of the
volume of all rendered audio, with an option to override audio volumes specified by the
author or user agent defaults.
- As part of satisfying provision one,
allow the user to choose zero volume (i.e., silent).
Note: User agents should allow configuration of volume
through available operating environment
controls.
- Allow independent control of the volumes of rendered audio sources synchronized to play
simultaneously.
Normative inclusions and exclusions
- The user control required by this checkpoint includes the ability to override author-specified volumes for the
relevant sources of audio.
- The user agent is not required to satisfy this checkpoint for audio whose
recognized role is to create a purely
stylistic effect; see checkpoint
4.4 for more information about what constitutes a stylistic effect.
- Conformance labels: Audio.
Note: The user agent should satisfy this checkpoint by
allowing the user to control independently the volumes of all audio sources (e.g., by implementing a general
audio mixer type of functionality). See checkpoint 4.10 for information about controlling the volume
of synthesized speech.
Checkpoint definitions for synthesized speech rendering
- Allow configuration of the synthesized speech
rate, according to the full range offered by the speech synthesizer.
Normative inclusions and exclusions
- Conformance labels: Speech.
Note: The range of synthesized speech rates offered by the
speech synthesizer may depend on natural language.
- Allow
control of the synthesized speech volume, independent of other sources of
audio.
Normative inclusions and exclusions
- The user control required by this checkpoint includes the ability to override author-specified synthesized speech
volume.
- Conformance labels: Speech.
Note: See also checkpoint 4.8.
- Allow configuration of synthesized speech
characteristics according to the full range of values offered by the speech
synthesizer.
Normative inclusions and exclusions
- Conformance labels: Speech.
Note: Some speech synthesizers allow users to choose values
for synthesized speech characteristics at a higher abstraction layer, i.e., by
choosing from present options that group several characteristics. Some typical
options one might encounter include: "adult male voice", "female child voice",
"robot voice", "pitch", "stress", etc. Ranges for values may vary among speech
synthesizers.
- Allow configuration of synthesized speech pitch.
Pitch refers to the average frequency of the speaking voice.
- Allow configuration of synthesized speech pitch
range. Pitch range specifies a variation in average frequency.
- Allow configuration of synthesized speech stress.
Stress refers to the height of "local peaks" in the intonation contour of the
voice.
- Allow configuration of synthesized speech
richness. Richness refers to the richness or brightness of the voice.
Normative inclusions and exclusions
- Conformance labels: Speech.
Note: This checkpoint is more specific than checkpoint
4.11: it requires support for the voice characteristics listed. Definitions
for these characteristics are based on descriptions in section 19 of the
Cascading Style Sheets Level 2 Recommendation
[CSS2]; please refer to that specification for additional informative descriptions. Some speech
synthesizers allow users to choose values for synthesized speech
characteristics at a higher abstraction layer, i.e., by choosing from present
options distinguished by "gender", "age", "accent", etc. Ranges of values may
vary among speech synthesizers.
- Provide
support for user-defined extensions to the synthesized speech
dictionary.
- Provide
support for spell-out: where text is spelled one character at a time, or
according to language-dependent pronunciation rules.
- Allow at least two configurations for speaking numerals: one
where numerals are spoken as individual digits, and one where full numbers are
spoken.
- Allow at least two configurations for speaking punctuation:
one where punctuation is spoken literally, and one where punctuation is
rendered as natural pauses.
Normative inclusions and exclusions
- Conformance labels: Speech.
Note: Definitions for the functionalities listed are based
on descriptions in section 19 of the Cascading Style Sheets Level 2
Recommendation [CSS2]; please refer to that
specification for additional informative descriptions.
Checkpoint definitions related to style sheets
- Allow the user to choose from and apply
alternative author style sheets
(such as linked style sheets).
- Allow the user to choose from and apply
at least one user style sheet.
- Allow the user to ignore author and user
style sheets.
Normative inclusions and exclusions
- This checkpoint only applies to user agents that
support style sheets.
Note: By definition, the user agent's default style
sheet is always present, but may be overridden by author or user styles.
Developers should not consider that the user's ability to turn off author and
user style sheets is an effective way to improve content accessibility; turning
off style sheet support means losing the many benefits they offer. Instead,
developers should provide users with finer control over user agent or content
behavior known to raise accessibility barriers. The user should only have to
turn off author and user style sheets as a last resort.
Control of viewport behavior is
important to accessibility. Unexpected changes to the point of regard – what the user
is presumed to be viewing – may cause users to lose track of how many viewports are open, which viewport has the
current focus, etc. If carried out
automatically, these changes might go unnoticed (e.g., by some users with
blindness) or be disorienting (e.g., to some users with a cognitive
disability). This guideline includes requirements for control of opening and
closing viewports, the relative position of graphical viewports, changes to
focus, and inadvertent form submissions.
Checkpoint definitions
- Allow configuration so that if a viewport opens without explicit user request, its content focus does not automatically
become the current focus.
Sufficient techniques
- Configuration is preferred, but is not required if the content focus can
only ever be moved on explicit user request.
- For graphical user interfaces, allow configuration so that the viewport with the
current focus remains "on top" of all
other viewports with which it overlaps.
- Allow configuration so that viewports only open
on explicit user request.
- When configured per provision one, instead
of opening a viewport automatically, alert the user and allow the user to open
it on demand (e.g., by following a link or confirming a prompt).
- Allow the user to close viewports.
Sufficient techniques
- Configuration is preferred, but is not required if viewports can only ever
open on explicit user
request.
Normative inclusions and exclusions
- If a viewport (e.g., a frame set) contains other viewports, these
requirements only apply to the outermost container viewport.
- User creation of a new viewport (e.g., empty or with a new resource loaded)
through the user agent's user interface constitutes an explicit user
request.
Note: Generally, viewports open automatically as the result
of instructions in content. See also checkpoint 5.1 (for
control over changes of focus when a viewport opens) and checkpoint 6.6 (for
programmatic notification of changes to the user interface).
- Ensure that when a viewport's selection or content focus changes, it is at least
partially in the viewport after the
change.
Normative inclusions and exclusions
- Conformance labels: Selection.
Note: For example, if users navigating links move to a
portion of the document outside a graphical viewport, the viewport should
scroll to include the new location of the focus. Or, for users of audio
viewports, allow configuration to render the selection or focus immediately
after the change.
- Allow configuration to
prompt the user to confirm (or cancel) any form submission.
Sufficient techniques
- Configuration is preferred, but it not required if forms can only ever be
submitted on explicit user
request.
Note: Examples of automatic form submission include:
script-driven submission when the user changes the state of a particular form
control associated with the form (e.g., via the pointing device), submission
when all fields of a form have been filled out, and submission when a
"mouseover" or "change" event
occurs.
This guideline addresses interoperability between a conforming user agent
and other software, in particular assistive technologies. The
checkpoints of this guideline require implementation of application programming
interfaces (APIs) for
communication. There are three types of requirements in this guideline:
- Requirements for what information must be communicated through an
API.
- Requirements for which APIs or types of
APIs must be used to communicate this information.
- Requirements for additional characteristics of these
APIs.
Note: The User Agent Accessibility Guidelines Working Group
believes that, in order to promote interoperability between a conforming user
agent and more than one assistive technology, it is more important to
implement conventional APIs than custom
APIs, even though custom APIs may offer
specialized access.
Checkpoint definitions
-
Provide programmatic read access to XML content by making available
all of the information items defined by the W3C XML Infoset [INFOSET].
-
Provide programmatic read access to HTML content by making available all of the
following information items defined by the W3C XML Infoset [INFOSET]:
- Document Information item: children, document element, base URI,
charset
- Element Information items: element-type name, children, attributes,
parent
- Attribute Information items: attribute-type name, normalized value,
specified, attribute type, references, owner element
- Character Information items: character code, parent element
- Comment Information items: content, parent
-
If the user can modify HTML and XML content through the user interface
(e.g., through form controls), allow for the same modifications
programmatically.
-
As part of satisfying
checkpoint 6.1, conform to the following modules of the W3C Document Object
Model DOM Level 2 Core
Specification [DOM2CORE] and exporting bindings
for the interfaces they define:
- for HTML: the Core module.
- for XML: the Core and XML modules.
-
As part of satisfying provision one:
- Export the normative bindings specified in the DOM Level 2 Core
Specification [DOM2CORE] (namely, for Java
[JAVA] and ECMAScript [ECMASCRIPT] operating
environments).
- For other environments, the bindings exported to satisfy provision one must
be publicly documented.
Normative inclusions and exclusions
- The user agent is not required to export the bindings outside of the user
agent process.
Note: Please refer to the "Document Object Model (DOM)
Level 2 Core Specification"
[DOM2CORE] for information about HTML and
XML versions covered.
- For
content other than HTML and XML,
provide structured programmatic read access to
content, and write access to those parts of content that the user can
modify through the user interface.
- As part of satisfying provision one,
implement at least one
API according to this API cascade:
- The API is defined by a W3C Recommendation, or the API is
publicly documented and designed to enable interoperability with assistive
technologies.
- If no such API is available, or if available APIs do not enable the user
agent to satisfy the requirements,
Normative inclusions and exclusions
- "Structured programmatic access" means access through an API to recognized
information items of the content (such as the information items of the XML
Infoset [INFOSET]). Plain text has little
structure, so an API that provides access to it will be correspondingly less
complex than an API for XML content. For content more structured than plain
text, an API that only provides access to a stream of characters does not
satisfy the requirement of providing structured programmatic access. This
document does not otherwise define what is sufficiently structured access.
- An API is considered "available" if the specification of the API is
published (e.g., as a W3C Recommendation) in time for integration into a user
agent's development cycle.
Note: This checkpoint addresses content not covered by checkpoint 6.1 and checkpoint 6.2.
- For graphical user agents, provide
programmatic read access to visually rendered information.
- As part of satisfying provision one,
implement at least one API according to the API cascade described in provision
2 of checkpoint 6.3.
Note: The API used to provide access to visually rendered
information should provide access to both structured information and
pixel-level information. User agents should also provide information about the
correspondence (in both directions) between locations in content and related locations in the
rendering structure.
-
Provide programmatic read access to user agent user interface
controls.
-
Provide programmatic write access for those user agent user interface
controls that the user can modify through the user interface.
-
As part of satisfying provisions one and two, implement at least one API
according to the API cascade described in provision 2 of checkpoint 6.3.
Note: APIs used to satisfy the requirements of this
checkpoint may be independent of a particular operating environment (e.g., the
W3C DOM), conventional APIs for a particular operating environment,
conventional APIs for programming languages,
plug-ins, virtual machine environments, etc. User agent developers are
encouraged to implement APIs that allow assistive technologies to interoperate
with multiple types of software in a given operating environment (user agents,
word processors, spreadsheet programs, etc.), as this reuse will benefit users
and assistive technology developers. User agents should always follow operating
environment conventions for the use of input and output APIs.
- Provide programmatic notification of
changes to content, user interface controls, selection, content focus, and user interface focus.
- As part of satisfying provision one,
implement at least one API according to the API cascade of provision 2 of checkpoint 6.3.
Normative inclusions and exclusions
- The user agent is not required to provide notification of rendering
changes (e.g., due to an animation effect or an effect caused by a style
sheet), just changes to the
content itself.
- Conformance labels: Selection.
- For both content and user
agent.
Note: For instance, provide programmatic notification when
user interaction in one frame causes automatic changes to content in
another.
-
Implement
APIs for the keyboard as follows:
Note: An operating environment may define more than one
conventional API for the keyboard. For instance, for Japanese and Chinese,
input may be processed in two stages, with an API for each.
- For an API implemented to satisfy
requirements of this document, support the character encodings required for
that API.
Note: Support for character encodings is important so that
text is not "broken" when communicated to assistive technologies. For example,
the DOM Level 2 Core Specification [DOM2CORE], section 1.1.5
requires that the DOMString
type be encoded using UTF-16. This
checkpoint is an important special case of the other API
requirements of this document.
-
For user agents that implement Cascading Style Sheets
(CSS), provide programmatic access to style sheets by
conforming to the CSS module of the W3C Document Object Model (DOM) Level 2 Style Specification [DOM2STYLE] and exporting
bindings for the interfaces it defines.
-
As part of satisfying provision one:
- Export the normative bindings specified in the CSS module of the
DOM) Level 2 Style Specification
[DOM2STYLE] (namely, for Java
[JAVA] and ECMAScript
[ECMASCRIPT] operating environments).
- For other environments, the bindings exported to satisfy provision one must
be publicly documented.
Normative inclusions and exclusions
- For the purposes of satisfying this checkpoint, Cascading Style Sheets
(CSS) are defined by either CSS Level 1 [CSS1] or CSS Level 2 [CSS2].
- The user agent is not required to export the bindings outside of the user
agent process.
Note: Please refer to the "Document Object Model (DOM)
Level 2 Style Specification"
[DOM2STYLE] for information about CSS versions
covered.
- For APIs implemented to satisfy the
requirements of this document, ensure that programmatic exchanges proceed in a
timely manner.
Note: For example, the programmatic exchange of information
required by other checkpoints in this document should be efficient enough to
prevent information loss, a risk when changes to content or user interface
occur more quickly than the communication of those changes. Timely exchange is
also important for the proper synchronization of alternative renderings. The
techniques for this checkpoint explain how developers can reduce communication
delays. This will help ensure that assistive technologies have timely access to
the document object model and other
information that is important for providing access.
Part of user agent accessibility involves following the conventions of the
user's operating environment. This includes:
Following operating environment
conventions also increases predictability for users and for developers of assistive
technologies. These guidelines explain what users will expect from the look
and feel of the user interface, keyboard conventions, documentation, etc. These
guidelines also include information about accessibility features that the user
agent should adopt rather than reimplement.
The chapter on conformance explains more on the use of operating environment features as part of
conformance.
Checkpoint definitions
- Follow operating environment
conventions that benefit accessibility when implementing the selection, content focus, and user interface focus.
Normative inclusions and exclusions
- Conformance labels: Selection.
Note: This checkpoint is an important special case of checkpoint 7.3. See also checkpoint 9.1 and checkpoint 9.2.
- Ensure that default input
configurations of the user agent do not interfere with operating
environment accessibility conventions (e.g., for keyboard
accessibility).
Note: Information about operating environment accessibility
conventions is available in the Techniques document
[UAAG10-TECHS]. See checkpoint 11.5 for information about the user agent's
default input configuration.
-
Follow operating environment
conventions that benefit accessibility. In particular, follow conventions that
benefit accessibility for user interface design, keyboard
configuration, product installation, and documentation.
Normative inclusions and exclusions
- For the purposes of this checkpoint, an operating environment convention
that benefits accessibility is either
- one identified as such in operating environment design or accessibility
guidelines, or
- one that allows the author to satisfy any requirement of the "Web Content
Accessibility Guidelines 1.0"
[WCAG10] or of the current document.
- For user agent features.
Note: Some of these conventions (e.g., sticky keys, mouse
keys, show sounds, etc.) are discussed in the Techniques document
[UAAG10-TECHS].
- Follow operating environment
conventions to indicate the input configuration.
Note: For example, in some operating environments, when a
functionality may be triggered through a menu and through the keyboard, the
developer may design the menu entry so that the character of the activating key
is also shown. This checkpoint is an important special case of checkpoint 7.3. See checkpoint 11.5 for
information about the user agent's default input configuration.
Developers should implement open specifications. Conformance to open
specifications benefits interoperability and accessibility by making it easier
to design assistive
technologies (also discussed in guideline 6).
While developers should implement the accessibility features of any
specification (checkpoint 8.1), this document recommends conformance to W3C
Recommendations in particular (checkpoint 8.2) for several reasons:
- W3C specifications include "built-in" accessibility features.
- W3C specifications undergo early review to ensure that accessibility issues
are considered during the design phase. This review includes review from
stakeholders in accessibility.
- W3C specifications are developed in a consensus process (refer to the
process defined by the W3C Process Document
[W3CPROCESS]). W3C encourages the public to review and comment on
these specifications (public Working Drafts, Candidate Recommendations, and
Proposed Recommendations). For information about how specifications become W3C
Recommendations, refer to the
W3C Recommendation track ([W3CPROCESS], section 6.2). W3C
Recommendations (and other technical
reports) are published at the W3C Web site.
Checkpoint definitions
- Implement the accessibility
features of specifications (markup languages, style sheet languages, metadata
languages, graphics formats, etc.).
Normative inclusions and exclusions
- This checkpoint applies to both W3C-developed and non-W3C
specifications.
- For the purposes of this checkpoint, an accessibility feature of a
specification is either:
- one identified as such in the specification, or
- one that allows the author to satisfy any requirement of the "Web Content
Accessibility Guidelines 1.0"
[WCAG10].
- The user agent is not required to satisfy this checkpoint for all
implemented specifications; see the section on conformance and implementing
specifications for more information.
- For all content.
Note: The Techniques document
[UAAG10-TECHS] provides information about the accessibility features
of some specifications, including W3C specifications.
- Use and
conform to either
- W3C Recommendations when they are available and appropriate for a task,
or
- non-W3C specifications that enable the creation of content that conforms at
level A or better to the Web Content Accessibility Guidelines 1.0
[WCAG10].
Sufficient techniques
- When a requirement of another specification contradicts a requirement of
the current document, the user agent may disregard the requirement of the other
specification and still satisfy this checkpoint.
Normative inclusions and exclusions
- A specification is considered available if it is published (e.g., as a W3C
Recommendation) in time for integration into a user agent's development
cycle.
- The user agent is not required to satisfy this checkpoint for all
implemented specifications; see the section on conformance and implementing
specifications for more information.
- For all content.
Note: For instance, for markup, the user agent may conform to HTML 4
[HTML4], XHTML 1.0 [XHTML10], or
XML 1.0 [XML]. For style sheets, the user
agent may conform to CSS ([CSS1],
[CSS2]). For mathematics, the user agent may conform to MathML 2.0
[MATHML20]. For synchronized
multimedia, the user agent may conform to SMIL 1.0
[SMIL].
Users should be able to navigate to important pieces of content within a
configurable view, identify the type of object they have navigated to, interact
with that object easily (if it is an enabled element), and review the
surrounding context (to orient themselves). Providing a variety of navigation
and search mechanisms helps users with disabilities (and all users) access
content more efficiently. Navigation and searching are particularly important
to users who access content serially (e.g., as synthesized speech or
braille).
Sequential navigation (e.g., line scrolling, page scrolling, sequential
navigation through enabled elements, etc.) means advancing (or rewinding)
through rendered content in well-defined steps (line by line, screen by screen,
link by link, etc.). Sequential navigation can provide context, but can be
time-consuming. Sequential navigation is important to users who cannot scan a
page visually for context and also benefits users unfamiliar with a page.
Sequential access may be based on element type (e.g., links only), content
structure (e.g., navigation from heading to heading), or other criteria.
Direct navigation (e.g., to a particular link or paragraph) is faster than
sequential navigation, but generally requires familiarity with the content.
Direct navigation is important to users with some physical disabilities (who
may have little or no manual dexterity and/or increased tendency to push
unwanted buttons or keys), to users with visual disabilities, and also benefits
"power users." Direct navigation may be possible with the pointing device or
the keyboard (e.g., keyboard shortcuts).
Structured navigation mechanisms offer both context and speed. User agents
should allow users to navigate to content known to be structurally important:
blocks of content, headers and sections, tables, forms and form elements,
enabled elements, navigation mechanisms, containers, etc. For information about
programmatic access to document structure, see guideline 6.
User agents should allow users to configure navigation mechanisms (e.g., to
allow navigation of links only, or links and headings, or tables and forms,
etc.).
Checkpoint definitions
- Provide at least one content focus for each viewport (including frames) where enabled elements are part of the rendered content.
- Allow the user to make the content focus
of each viewport the current focus.
Note: For example, when two frames of a frameset contain
enabled elements, allow the user to make the content focus of either frame the
current focus. Note that viewports "owned" by
plug-ins that are part of a conformance claim are also covered by this
checkpoint. See
checkpoint 7.1 for information about implementing content focus according
to operating
environment conventions.
-
Provide a user interface
focus.
Note: See checkpoint 7.1 for information about implementing user
interface focus according to operating environment
conventions.
-
Allow the user to move the content focus to any enabled element in the viewport.
-
Allow configuration so that the content focus of
a viewport only changes on explicit user request.
Configuration is not required if the content focus only ever changes on
explicit user request. See checkpoints 5.1 and
6.6 for more information about focus changes.
- If
the author has not specified a navigation order, allow at least forward
sequential navigation, in document order, to each element in the set
established by provision one.
Normative inclusions and exclusions
- The user agent may also include disabled elements in the navigation
order.
Note: In addition to forward sequential navigation, the
user agent should also allow reverse sequential navigation. This checkpoint is
an important special case of
checkpoint 9.9.
- For user agents that implement a
viewport history mechanism, for each state in a viewport's browsing history, maintain
information about the point of regard, content focus, and selection.
- When the user returns to any state in
the viewport history (e.g., via the "back button"), restore the saved values
for the point of regard, content focus, and selection.
Normative inclusions and exclusions
- The viewport history associates values for these three state variables (point of regard, content focus, and selection) with a particular document
object. If the user returns to a state in the history and the user agent
retrieves new content, the user agent is not required to restore the saved
values of the three state variables.
- Conformance labels: Selection.
- Allow configuration so that moving the content focus to or from an enabled element does not
automatically activate any explicitly
associated event handlers of any
event type.
Normative inclusions and exclusions
- Conformance labels: Events.
Note: For instance, in this configuration for an HTML
document, do not activate any handlers for the 'onfocus
',
'onblur
', or 'onchange
' attributes. In this
configuration, user agents should still apply any stylistic changes (e.g., highlighting) that may occur when there is
a change in content focus.
-
For the element with content focus, make available the list
of input device event types for which there are event handlers explicitly associated
with the element.
Normative inclusions and exclusions
- Conformance labels: Events.
Note: For example, allow the user to query the element with
content focus for the list of input device event types, or add them directly to
the serial navigation order described in checkpoint 9.3. See checkpoint 1.2 for
information about activation of event handlers associated with the element with
focus.
- As part of satisfying provision three of checkpoint 9.3, allow the same
sequential navigation in reverse document order.
- As part of satisfying provision three of checkpoint 9.3, the user agent must
not include disabled elements in
the navigation order.
Note: This checkpoint is a special case of checkpoint 9.3.
-
Allow the user to search within rendered text for a sequence of
characters from the document character set.
-
Allow the user to start a forward search (in document order) from any selected
or focused location in content.
-
When there is a match, do both of the following:
- move the viewport so that the matched text content is within it,
and
- allow the user to search for the next instance of the text from the
location of the match.
-
Alert the user when there is no match, when the search reaches the end of
content, and prior to any wrapping. A wrapping search is one that restarts
automatically at the beginning of content once the end of content has been
reached.
-
Provide a case-insensitive search option for text in
scripts (i.e., writing systems) where case is significant.
Note: If the user has not indicated a start position for
the search, the search should start from the beginning of content. Per checkpoint 7.3, use operating
environment conventions for indicating the result of a search (e.g., selection or content focus).
-
Allow the user to navigate efficiently to and among important structural
elements in rendered
content.
-
As part of satisfying provision one, allow forward and backward sequential
navigation.
Note: This specification intentionally does not identify
which "important elements" must be navigable as this will vary by
specification. What constitutes "efficient navigation" may depend on a number
of factors as well, including the "shape" of content (e.g., serial navigation
of long lists is not efficient) and desired granularity (e.g., among tables,
then among the cells of a given table). Refer to the Techniques document
[UAAG10-TECHS] for
information about identifying and navigating important elements.
- Allow configuration of the set of important
elements identified in checkpoints 9.9 and
10.4.
- As part of satisfying provision one,
allow the user to include and exclude element types in the set.
Note: For example, allow the user to navigate only
paragraphs, or only headings and paragraphs, or to suppress and restore
navigation bars, to navigate within and among tables and table cells, etc.
All users require clues to help them understand their "location" when
browsing: where they are, how they got there, where they can go, what's nearby,
etc. Some mechanisms that provide such clues through the user interface
(visually, as audio, or as braille) include:
- information about the current state of the user's interaction with content:
where the viewport is in content (shown, for example, through proportional
scroll bars), which viewport has the current focus, where the user has
selected content, a history mechanism, the title of the current document or
frame, etc.
- information about specific elements, such as the dimensions of a table, the
length of an audio clip, the structure of a form, etc.
- information about relationships among elements, such as between table cells
and related table headers.
- information about the structure of content, e.g., through an outline view
of a document.
Orientation mechanisms such as these are especially important to users who
view content serially, (e.g., when rendered as synthesized speech or braille).
For instance, these users cannot "scan" a graphically displayed table with
their eyes for information about a table cell's headers, neighboring cells,
etc. User agents need to provide other means for users to understand table cell
relationships, frame relationships (what relationship does the graphical layout
convey?), form context (have I filled out the form completely?), link
information (have I already visited this link?), etc.
Checkpoint definitions
-
For graphical user agents that render tables, allow the user to view the
header information associated with any table cell in the same viewport and at
the same time as the table cell.
Sufficient techniques
- The user agent may satisfy this checkpoint with a technique frequently
employed by spreadsheet applications: the user agent fixes the position of
headers in the viewport and allows the user to scroll through associated data
cells. Through horizontal and vertical alignment, the data cells and header
cells are visually associated.
Normative inclusions and exclusions
- This checkpoint refers only to cell/header relationships that the user
agent can recognize.
10.2 Highlight selection, content focus, enabled elements, visited
links. (P1)
Techniques for checkpoint 10.2
- Allow global configuration to highlight the following four classes of
information in each viewport: the selection, content focus, enabled elements, and recently
visited links.
- For graphical user interfaces, as part
of satisfying provision one, allow at least one configuration where the
highlight mechanisms for the four classes of information:
- differ from each other, and
- do not rely on rendered text foreground and background
colors alone.
- For graphical user interfaces, as part
of satisfying provision one, if a highlight mechanism involves text size, font
family, rendered text foreground
and background colors, or text decorations, offer at least the following range
of values:
- for text size, the range required by provision two of checkpoint 4.1.
- for font family, the range required by provision two of checkpoint 4.2.
- for text foreground and background colors and decorations, the range
offered by the conventional utility available in the operating environment for
users to choose rendered text colors or decorations (e.g., the standard font
and color dialog box resources supported by the operating system). If no such
utility is available, the range supported by the conventional APIs of the
operating environment for specifying text colors or drawing text.
- Highlight enabled elements according to the
granularity specified in the format. For example, an HTML user agent rendering
a PNG image as part of a client-side image map is only required to highlight
the image as a whole, not each enabled region. An SVG user agent rendering an
SVG image with embedded graphical links is required to highlight each (enabled) link that may be rendered
independently according to the SVG specification.
Normative inclusions and exclusions
- Conformance labels: Selection.
Note: Examples of highlight mechanisms for selection and
content focus include foreground and background color variations, underlining,
distinctive synthesized speech prosody, border styling, etc. Because the
selection and focus change frequently, user agents should not highlight them
using mechanisms (e.g., font size variations) that cause content to reflow, as
this may disorient the user. Graphical highlight mechanisms that generally do
not rely on rendered text foreground and background color alone include
underlines or border styling. Per checkpoint 7.1, follow operating environment conventions
that benefit accessibility when implementing the selection and content focus.
For instance, if specified at the level of the operating environment, inherit
the user's preferences for selection styles.
- As part of satisfying provision two
of checkpoint 10.2,
allow configuration through a single
setting.
Normative inclusions and exclusions
- Conformance labels: Selection.
- Make available to the user an "outline"
view of content, composed of labels for important
structural elements (e.g., heading text, table titles, form titles, and other
labels that are part of the content).
Normative inclusions and exclusions
- What constitutes a label is defined by each markup language specification.
For example, in HTML, a heading (
H1
-H6
) is a label
for the section that follows it, a CAPTION
is a label for a table,
the "title
" attribute is a label for its element, etc.
- The user agent is not required to generate a label for an important element
when no label is present in content. The user agent may generate a label when
one is not present.
- A label is not required to be
text only.
Note: This outline view will provide the user with a
simplified view of content (e.g, a table of contents). For information about
what constitutes the set of important structural elements, please see the Note
following checkpoint 9.9. By
making the outline view navigable, it is possible to satisfy this checkpoint
and checkpoint 9.9 together:
allow users to navigate among the important elements of the outline view, and
to navigate from a position in the outline view to the corresponding position
in a full view of content. See checkpoint 9.10 for additional configuration options.
- To
help the user decide whether to traverse a link, make available the following
information about it:
- link element content,
- link title,
- whether the link is internal to the resource (e.g., the link is to a target
in the same Web page),
- whether the user has traversed the link recently, and
- information about the type, size, and natural language of linked Web
resources.
Normative inclusions and exclusions
- The user agent is not required to compute or make available information
that requires retrieval of linked Web resources.
Checkpoint definitions for the user interface
- Allow global configuration to highlight the viewport with the current focus (including any frame that
takes current focus).
- For graphical viewports, as part of
satisfying provision one, allow at least one configuration where the highlight
mechanism does not rely on rendered text foreground and background
colors alone (e.g., use a thick outline).
- If the techniques used to satisfy
provision one involve rendered text size, font family, rendered text foreground and background
colors, or text decorations, offer the same ranges of values required by
provision three of
checkpoint 10.2.
Note: See checkpoint 7.1 for information about implementing highlight
mechanisms according to operating environment
conventions.
- Indicate the viewport's position relative to rendered content (e.g., the
proportion of an audio or video clip that has been played, the proportion of a
Web page that has been viewed, etc.).
Sufficient techniques
- The user agent may calculate the relative position according to content
focus position, selection position, or viewport position, depending on how the
user has been browsing.
- The user agent may indicate the proportion of content viewed in a number of
ways, including as a percentage, as a relative size in bytes, etc. See checkpoint 1.3 for more information
about text versions of messages to the user, including messages about position
information.
Normative inclusions and exclusions
- For two-dimensional renderings, relative position includes both vertical
and horizontal positions.
- This checkpoint does not require the user agent to present information
about retrieval progress. However, for streaming content, viewport
position may be closely tied to retrieval progress.
Web users have a wide range of capabilities and need to be able to configure the user agent according to their
preferences for styles, graphical user interface configuration, keyboard
configuration, etc. Most of the checkpoints in this guideline pertain to the
input configuration: how user agent behavior is controlled through keyboard
input, pointing device input, and voice input. An input configuration is the
set of "bindings" between user agent functionalities and user interface input mechanisms.
The chapter on conformance explains more about configuration requirements and
conformance.
Checkpoint definitions
- Provide information to the user about
current user preferences for input configurations.
Sufficient techniques
- To satisfy this checkpoint, the user agent may make available binding
information in a centralized fashion (e.g., a list of bindings) or a
distributed fashion (e.g., by listing keyboard shortcuts in user interface
menus). See related checkpoints 12.2,
12.3, and
12.5.
- Provide a centralized view of the
current author-specified input configuration.
Sufficient techniques
- The user agent may satisfy this checkpoint by providing different views for
different input modalities (keyboard, pointing device, voice, etc.).
Note: For example, for HTML documents, provide a view of
keyboard bindings specified by the author through the "accesskey
"
attribute. The intent of this checkpoint is to centralize information about
author-specified bindings so that the user does not have to read the entire
content first to find out what bindings are available.
- Allow the user to override any binding that is part of the
user agent default input configuration.
Normative inclusions and exclusions
- The user agent is not required to allow the user to override conventional
bindings for the operating environment (e.g.,
for access to help).
- The override requirement only applies to bindings for the
same input modality (e.g., the user must be able to override a keyboard binding
with another keyboard binding).
- For user agent features.
Note: See also checkpoints 11.5, 11.7, and 12.3.
- As
part of satisfying checkpoint
11.3 for the keyboard, allow the user to override any binding in the user agent
default keyboard configuration with a binding to either a key plus modifier
keys or to a single key.
- For
each functionality in the set required by checkpoint 11.5, allow the user to configure a single-key binding. A
single-key binding is one where a single key press performs the task, with zero
modifier keys.
Sufficient techniques
- The requirements of provision two may be satisfied with a "single-key mode"
(i.e., a mode where the current bindings are replaced by a set of single-key
bindings).
Normative inclusions and exclusions
- In this checkpoint, "key" refers to a physical key of the keyboard (rather
than, say, a character of the document character set).
- The user agent is not required to allow the user to override conventional bindings for the operating
environment (e.g., for access to help).
- Provision two does not require single physical key bindings for character
input, only for the activation of user agent functionalities.
- If the number of physical keys on the keyboard is less than the number of
functionalities required by checkpoint 11.5, provision two does not require the user
agent to allow single-key bindings for all of the functionalities. The user
agent should give preference to those functionalities listed in provision one
of that checkpoint.
- For user agent features.
Note: Because single-key access is so important to some
users with physical disabilities, user agents should ensure that (1) most keys
of the physical keyboard may be configured for single-key bindings, and (2)
most functionalities of the user agent may be configured for single-key
bindings. For information about access to user agent functionality through a
keyboard API, see checkpoint
6.7.
- Ensure that the user agent default input
configuration includes bindings for the following functionalities required
by other checkpoints in this document:
- move focus to next enabled element, and move focus to
previous enabled element;
- activate focused link;
- search for text;
- search again for same text;
- increase size of rendered text, and decrease size of
rendered text;
- increase global volume, and decrease global volume;
- stop, pause, resume, and navigate efficiently selected audio and animations (including video and animated
images).
- If the user agent supports the following functionalities, the
default input configuration must also include bindings for them:
- next history state (forward), and previous history state (back);
- enter URI for a new resource;
- add a URI to favorites (i.e., bookmarked resources);
- view favorites;
- reload a resource;
- interrupt a request to reload a resource;
- for graphical viewports: navigation forward and backward through rendered
content by approximately the height of the viewport;
- for user agents that render content in lines of (at least) text: move point
of regard to next line, and previous line.
Sufficient techniques
- The user agent may satisfy the functionality of entering a URI for a new
resource in a number of ways, including by prompting the user, or by moving the
user interface focus to a user
interface control for entering URIs
Note: This checkpoint does not make any requirements about
the ease of use of default input configurations, though clearly the default
configuration should include single-key bindings and allow easy operation. Ease
of use is addressed by the configuration requirements of checkpoint 11.3.
-
For the configuration requirements of this document, allow the user to save
user preferences in at least one
user profile.
-
Allow the user to choose from among available default profiles, profiles
created by the same user, and no profile (i.e., the user agent default
settings).
Normative inclusions and exclusions
- This checkpoint does not require that user profiles be portable, i.e.,
removable from the user agent to be reread by a different instance of the
agent. Portable user profiles are very useful, however.
- For user agent features.
- For graphical user agent user interfaces
with tool bars, allow the user to configure the position of controls on those
tool bars.
- Offer a predefined set of controls that
may be added to or removed from tool bars.
- Allow the user to restore the default
tool bar configuration.
Note: This checkpoint is a special case of checkpoint 11.3.
Documentation of the user interface is important, as is documentation of the
user agent's underlying functionalities. While intuitive user interface design
is valuable to many users, some users may still not be able to understand or be
able to operate the native user interface without thorough documentation. For
instance, a user with blindness may not find a graphical user interface
intuitive without supporting documentation.
There are three types of requirements in this guideline:
- accessibility of the documentation (checkpoint 12.1);
- minimal requirements of what must be documented (checkpoints 12.2, 12.3, and 12.4). Documentation should include much more
to explain how to install, get help for, use, or configure the user agent;
- organization of the documentation (checkpoint 12.5).
See checkpoint 7.3 for
information about following system conventions for documentation.
Checkpoint definitions
-
Ensure that at least one version of the user agent documentation conforms to at least
level Double-A of the Web Content Accessibility Guidelines 1.0 [WCAG10].
- Document all user agent features that
benefit accessibility.
Sufficient techniques
- The user agent may satisfy this checkpoint either by
- providing a centralized view of the accessibility features, or
- integrating accessibility features into the rest of the documentation.
Normative inclusions and exclusions
- For the purposes of this checkpoint, a user agent feature that benefits
accessibility is one implemented to satisfy the requirements of this document
(including the requirements of checkpoints 8.1 and 7.3, and the API requirements of
guideline 6).
- For user agent features.
Note: The help system should include discussion of user
agent features that benefit accessibility. The user agent should satisfy this
checkpoint by providing both centralized and integrated views of accessibility
features in the documentation.
- Document the default user agent input
configuration (e.g., the default keyboard bindings).
Sufficient techniques
- If the user agent does not allow the user to override the default user
agent input configuration (see
checkpoint 11.3), the documentation used to satisfy this checkpoint also
satisfies checkpoint
11.1.
Note: Documentation should warn the user whenever the
default input configuration is inconsistent with conventions of the operating
environment.
- Document changes from the previous
version of the user agent to features that benefit accessibility, including
features of the user interface.
- As part of satisfying checkpoint 12.2, provide
a centralized view of all features of the user agent that benefit
accessibility, in a dedicated section of the documentation.
Note: The user agent satisfies this checkpoint
automatically by providing a centralized view of accessibility features to
satisfy checkpoint
12.2. However, developers are encouraged to integrate descriptions of
accessibility features into the documentation alongside other features, in
addition to providing a centralized view.