User Agent Accessibility Guidelines 1.0
31 July 2001
The twelve guidelines in this document state general principles for the
development of accessible user agents. Each guideline includes:
- The guideline number.
- The statement of the guideline.
- 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:
- The checkpoint number.
- Informative: The checkpoint title. This title is not a
requirement, just a phrase to help readers remember an important requirement
made by the checkpoint statement.
- Normative: The priority of the
checkpoint.
- Normative: The statement or statements of the checkpoint.
These statements include one or more requirements that must be satisfied by the
user agent (i.e., the "subject of the
claim) for the purposes of
conformance.
- Normative: An optional "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.
- Informative: A link to rationale, implementation details,
references, and more information in "Techniques for User Agent Accessibility
Guidelines 1.0" [UAAG10-TECHS].
- Normative:
Content type labels (zero or more). Content type labels are explained in
the section on conformance.
- Informative: Optional notes about the checkpoint
(beginning with the word "Note"). They 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.
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. "Techniques for User Agent Accessibility
Guidelines 1.0" [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 by most platforms, 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.6. 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
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.
Checkpoints
1.1 Full keyboard access. (P1)
- Ensure that the user can operate through keyboard input alone any user
agent functionality available through the user
interface.
For both content and user agent.
Techniques for checkpoint 1.1
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.
1.2 Activate event handlers.
(P1)
- For the element with
content focus, allow the user to activate
any explicitly associated input device event
handlers through keyboard input alone.
- 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.
Techniques for checkpoint 1.2
Note: 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. 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.
1.3 Provide text messages. (P1)
- 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.
Techniques for checkpoint 1.3
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.4, a text equivalent for each such message must be available through an
API. See also checkpoint 6.5 for requirements for programmatic alert 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:
- Not all content is rendered at all times. Automatic decision by the user
agent about when and where to render
conditional content is preferred, but manual choice by the user may
be necessary for access.
- Structure is preferred (both the author's specified preferences and the
user's structured access), but unstructured access may be necessary for access
to all content.
- 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).
Checkpoints
2.1 Render content according to
specification. (P1)
- Render content
according to format specification (e.g., for a markup language or style
sheet).
- 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.
- 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).
Techniques for checkpoint 2.1
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.). 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.
2.2 Provide text view. (P1)
- For content
authored in text formats, provide a
view of the text
source. For the purposes of this document, text formats are defined
to be:
- all media objects given an Internet media type of "text" (e.g., text/plain,
text/HTML, or text/*) as defined in RFC 2046
[RFC2046], section 4.1.
- all SGML and XML applications, regardless of Internet media type (e.g.,
HTML 4.01, XHTML 1.1, SMIL, SVG, etc.).
Techniques for checkpoint 2.2
Note: A user agent would also satisfy this checkpoint by
providing a source view for any text format, not just implemented text formats.
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.
2.3
Render conditional content. (P1)
- Allow
configuration to provide access to each piece of unrendered
conditional content "C".
- The configuration may be a switch that, for all content, turns on or off
the access mechanisms described in the next provision.
- 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 querying 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.
- To satisfy this checkpoint, 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).
For all content.
Techniques for checkpoint 2.3
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). See
checkpoint 2.10 for additional placeholder requirements.
2.4 Allow time-independent interaction.
(P1)
- 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. For example, if a presentation includes time-dependent user
input opportunities, pause automatically to allow for user input, and resume on
explicit user request. Or, offer a time-independent ("static") view of the
presentation in a different viewport that preserves the order and flow of the
presentation.
- If the user agent satisfies this checkpoint by pausing content
automatically, 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).
- 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).
Techniques for checkpoint 2.4
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. 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).
See also checkpoint 3.5, which involves client-driven content
refresh.
2.5 Make captions, transcripts available.
(P1)
- Allow
configuration or control to
render text
transcripts, collated text transcripts, captions,
and auditory
descriptions at the same time as the associated audio
tracks and visual
tracks.
For all content.
Techniques for checkpoint 2.5
Content
type labels: Video, Audio.
Note: This checkpoint is an important special case of checkpoint 2.1.
2.6 Respect synchronization cues.
(P1)
- Respect synchronization cues (e.g., in markup) during rendering.
Techniques for checkpoint 2.6
Content
type labels: Video, Audio.
Note: This checkpoint is an important special case of checkpoint 2.1.
2.7 Repair missing content. (P2)
- 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.
- 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.
For all content.
Techniques for checkpoint 2.7
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). Repair text based on URI reference, content
type, or element type is sufficient to satisfy the checkpoint, but may not
result in the most effective repair. Information that may be
recognized as relevant to repair might not be "near" the missing
conditional content in the document object. 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.
2.8 No repair text.
(P3)
- Allow at least two
configurations for when the user agent
recognizes that conditional content required by the format
specification is present but
empty:
For all content.
Techniques for checkpoint 2.8
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.
2.9 Render conditional
content automatically. (P3)
- Allow
configuration to render all
conditional content automatically. The user agent is not required to
render all conditional content at the same time in a single viewport.
- Provide access to this content according to format specifications or where
unspecified, by applying one of the techniques described in checkpoint 2.3: 1a, 2a, or
1b.
For all content.
Techniques for checkpoint 2.9
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.).
2.10
Toggle placeholders. (P3)
- Once the user has viewed the original author-supplied content associated
with a
placeholder, allow the user to turn off the rendering of the
author-supplied content.
Techniques for checkpoint 2.10
Note: For example, if the user agent substitutes the
author-supplied content for the placeholder in context, allow the user to
"toggle" between placeholder and the associated content. Or, if the user agent
renders the author-supplied content in a separate viewport, allow the user to
close that viewport. Note: See checkpoint 2.3, provision
(1b) for placeholder requirements.
2.11 Alert unsupported language.
(P3)
- 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.
- Indicate to the user in context that author-supplied content has not been
rendered.
- This checkpoint does not require the user agent to allow different
configurations for different natural languages.
Techniques for checkpoint 2.11
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, automatically redirected or refreshed pages, 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
may pose accessibility problems. Requirements for interactive
control of rendered content are part of
guideline 4.
Checkpoints
3.1 Toggle background images.
(P1)
- Allow
configuration not to render background image
content.
- In this configuration, the user agent is not required to retrieve
background images from the Web.
- 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".
Techniques for checkpoint 3.1
Content
type 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).
3.2
Toggle audio, video, animated images. (P1)
- Allow
configuration not to render audio, video, or animated image
content, except on explicit
user request. 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 (e.g., when the user activates a link).
- The user agent may satisfy this checkpoint by making video and animated
images
invisible and audio
silent, but this technique is not recommended.
- When configured not to render content except on explicit user request, the
user agent is not required to retrieve the audio, video, or animated image from
the Web until requested by the user.
Techniques for checkpoint 3.2
Content
type labels:
Animation, Video, Audio.
Note: See checkpoint 2.3 for information about how to provide access
to unrendered audio, video, and animated images. See also checkpoint 4.5, checkpoint 4.9, and checkpoint 4.10.
3.3
Toggle animated/blinking text. (P1)
- 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, any rate of
change.
- 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.
Techniques for checkpoint 3.3
Content
type labels:
VisualText.
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). See also checkpoint 3.5. This checkpoint does not apply for blinking and animation
effects that are caused by mechanisms that the user agent cannot
recognize.
3.4 Toggle scripts. (P1)
- Allow
configuration not to execute any executable
content (e.g.,
scripts and
applets).
- In this configuration, provide an option to alert the user when executable
content is available (but has not been executed).
- The user agent is only required to alert the user to the presence of more
than zero scripts or applets (i.e., per-element alerts are not required).
Techniques for checkpoint 3.4
Note: This checkpoint does not refer to
plug-ins and other programs that are not
part of content.
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.
3.5 Toggle content refresh. (P1)
- Allow
configuration so that the user agent only refreshes
content on explicit
user request.
- In this configuration, alert the user of the refresh rate specified in
content, and allow the user to request fresh content manually (e.g., by
following a link or confirming a prompt).
- When the user chooses not to refresh content, the user agent may ignore
that content; buffering is not required.
- This checkpoint only applies when the user agent (not the server)
automatically initiates the request for fresh content.
Techniques for checkpoint 3.5
Note: For example, allow configuration to prompt the user
to confirm content refresh, at the rate specified by the author.
3.6 Toggle redirects. (P2)
- Allow
configuration so that a "client-side redirect" (i.e., one initiated
by the user agent, not the server) only changes
content on explicit
user request.
- Allow the user to access the new content on demand (e.g., by following a
link or confirming a prompt).
- The user agent is not required to provide these functionalities for
client-side redirects specified to occur instantaneously (i.e., after no
delay).
Techniques for checkpoint 3.6
Note: Some HTML user agents support
client-side redirects authored using a META
element with
http-equiv="refresh"
. Authors (and Web masters) should use the redirect
mechanisms of HTTP instead.
3.7 Toggle images. (P2)
- Allow
configuration not to render image
content.
- The user agent may satisfy this checkpoint by making images
invisible, but this technique is not recommended.
Techniques for checkpoint 3.7
Content
type labels: Image.
Note: See checkpoint 2.3 for information about how to provide access
to unrendered images.
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, fast reverse, and fast advance it
manually. User agents rendering audio have to allow the user to control the
audio volume globally and to allow the user to control independently
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.
Checkpoints for visually rendered text
4.1
Configure text size. (P1)
- Allow global
configuration of the reference size of visually rendered
text, with an option to
override reference sizes specified by the author or user agent
defaults.
- 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.
Techniques for checkpoint 4.1
Content
type labels:
VisualText.
Note: The reference size of rendered text corresponds to
the default value of the CSS2 'font-size' property, which is 'medium' (refer to
CSS2
[CSS2], section 15.2.4). For example, in HTML, this might be
paragraph text. The default reference size of rendered text may vary among user
agents. User agents may offer different mechanisms to allow control of the size
of rendered text (e.g., font size control, zoom, magnification, etc.). Refer,
for example to the Scalable Vector Graphics specification [SVG]
for information about scalable rendering.
4.2 Configure font family. (P1)
- 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.
- 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.
- For text that
cannot be rendered properly using the user's preferred font family, the user
agent may substitute an alternative font family.
Techniques for checkpoint 4.2
Content
type labels:
VisualText.
Note: For example, allow the user to specify that all text is to be rendered in a particular
sans-serif font family.
4.3
Configure text colors. (P1)
- 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.
- 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.
Techniques for checkpoint 4.3
Content
type labels:
ColorText.
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.3 for more information about highlight
styles.
Checkpoints for multimedia presentations and other
presentations that change continuously over time
4.4 Slow multimedia. (P1)
- Allow the user to slow the presentation rate of rendered audio and
animations (including video and animated images).
- For a visual
track, provide at least one setting between 40% and 60% of the
original speed.
- For a prerecorded audio
track including audio-only presentations, provide at least one
setting between 75% and 80% of the original speed.
- When the user agent allows the user to slow the visual track of a
synchronized multimedia presentation to between 100% and 80% of its original
speed, synchronize the visual and audio tracks. Below 80%, the user agent is
not required to render the
audio track.
- The user agent is not required to satisfy this checkpoint for audio and
animations whose
recognized role is to create a purely stylistic effect.
Techniques for checkpoint 4.4
Content
type labels:
Animation, Audio.
Note: Purely stylistic effects include background sounds,
decorative animated images, and effects caused by style sheets. 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). See checkpoint 2.6 and checkpoint 4.7.
4.5 Start, stop, pause, advance,
reverse multimedia. (P1)
- Allow the user to stop, pause, resume, fast advance, and fast reverse
rendered audio and
animations (including video and animated images) that last three or
more seconds at their default playback rate.
- The user agent is not required to satisfy this checkpoint for audio and
animations whose
recognized role is to create a purely stylistic effect.
- The user agent is not required to play synchronized audio during fast
advance or reverse of animations (though doing so may help orient the
user).
- The user agent is not required to play animations during fast advance and
fast reverse.
- When the user pauses a real-time audio or animation, the user agent may
discard packets that continue to arrive during the pause.
Techniques for checkpoint 4.5
Content
type labels:
Animation, Audio.
Note: See
checkpoint 4.4 for more information about the exception for purely
stylistic effects. This checkpoint applies to content that is either rendered
automatically or on request from the user. Respect synchronization cues per checkpoint 2.6.
4.6 Position captions. (P1)
- For graphical
viewports, allow the user to position rendered captions
with respect to synchronized
visual tracks as follows:
- if the user agent satisfies this checkpoint by using a markup language or
style sheet language to provide configuration or control, then the user agent
must allow the user to choose from among at least the range of positions
enabled by the format
- otherwise the user agent must allow both non-overlapping and overlapping
positions (e.g., by rendering captions in a separate viewport
that may be positioned on top of the visual track).
- In either case, the user agent must allow the user to override
the author's specified position.
- The user agent is not required to change the layout of other content (i.e.,
reflow) after the user has changed the position of captions.
- The user agent is not required to make the captions background transparent
when those captions are rendered above a related video track.
Techniques for checkpoint 4.6
4.7 Slow other multimedia. (P2)
- Allow the user to slow the presentation rate of rendered audio and
animations (including video and animated images) not covered by checkpoint 4.4.
- The same speed percentage requirements of checkpoint 4.4 apply.
Techniques for checkpoint 4.7
Content
type labels:
Animation, Audio.
Note: User agents automatically satisfy this checkpoint if
they satisfy checkpoint 4.4
for all audio and animations.
4.8 Control other multimedia.
(P2)
- Allow the user to stop, pause, resume, fast advance, and fast reverse
rendered audio and
animations (including video and animated images) not covered by checkpoint 4.5.
Techniques for checkpoint 4.8
Content
type labels:
Animation, Audio.
Note: User agents automatically satisfy this checkpoint if
they satisfy checkpoint
4.5 for all audio and animations.
Checkpoints for audio volume control
4.9 Global volume control. (P1)
- 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.
- Allow the user to choose zero volume (i.e.,
silent).
Techniques for checkpoint 4.9
Content
type labels: Audio.
Note: User agents should allow configuration of volume
through available operating environment controls.
4.10 Independent volume control.
(P1)
- Allow independent control of
the volumes of rendered audio sources
synchronized to play simultaneously.
- The user agent is not required to satisfy this checkpoint for audio whose
recognized role is to create a purely stylistic effect.
- The user control required by this checkpoint includes the ability to override
author-specified volumes for the relevant sources of audio.
Techniques for checkpoint 4.10
Content
type labels: Audio.
Note: See
checkpoint 4.4 for more information about the exception for purely
stylistic effects. 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 also checkpoint 4.13.
4.11
Control other volume. (P2)
- Allow independent control of
the volumes of rendered audio sources
synchronized to play simultaneously that are not covered by checkpoint
4.10.
Techniques for checkpoint 4.11
Content
type labels: Audio.
Note: User agents automatically satisfy this checkpoint if
they satisfy
checkpoint 4.10 for all audio.
Checkpoints for synthesized speech rendering
4.12 Configure synthesized speech rate.
(P1)
- Allow
configuration of the synthesized speech rate, according to the full
range offered by the speech synthesizer.
Techniques for checkpoint 4.12
Content
type labels:
Speech.
Note: The range of synthesized speech rates offered by the
speech synthesizer may depend on natural language.
4.13 Configure synthesized speech volume.
(P1)
- Allow control of
the synthesized speech volume, independent of other sources of audio.
- The user control required by this checkpoint includes the ability to override
author-specified synthesized speech volume.
Techniques for checkpoint 4.13
Content
type labels:
Speech.
Note: See also checkpoint 4.10.
4.14 Configure
synthesized speech characteristics. (P1)
- Allow
configuration of synthesized speech characteristics according to the
full range of values offered by the speech synthesizer.
Techniques for checkpoint 4.14
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.
4.15 Specific synthesized speech characteristics. (P2)
- Allow
configuration of the following synthesized speech characteristics:
pitch, pitch range, stress, richness.
- Pitch refers to the average frequency of the speaking voice.
- Pitch range specifies a variation in average frequency.
- Stress refers to the height of "local peaks" in the intonation contour of
the voice.
- Richness refers to the richness or brightness of the voice.
Techniques for checkpoint 4.15
Note: This checkpoint is more specific than checkpoint
4.14: 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.
Content
type labels:
Speech.
4.16 Configure synthesized speech features.
(P2)
- Provide support for
user-defined extensions to the synthesized speech dictionary, as well as the
following functionalities:
- spell-out: spell text one character at a time or according to
language-dependent pronunciation rules;
- speak-numeral: speak a numeral as individual digits or as a full number;
and
- speak-punctuation: speak punctuation literally or render as natural
pauses.
Techniques for checkpoint 4.16
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.
Checkpoints related to style sheets
4.17
Choose style sheets. (P1)
- For user agents that support
style sheets:
- Allow the user to choose from and apply available
author style sheets (in
content).
- Allow the user to choose from and apply available user style
sheets.
- Allow the user to ignore author and user style sheets.
Techniques for checkpoint 4.17
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. For people with visual disabilities or
certain types of learning disabilities, it is important that the point of
regard – what the user is presumed to be viewing –
remain as stable as possible. Unexpected changes may cause users to lose track
of how many viewports
are open, which viewport has the
current focus, etc. This guideline includes requirements for control
of opening and closing viewports, the relative position of graphical viewports,
changes to focus, and inadvertent form submissions and micropayments.
Checkpoints
5.1 No automatic content focus change.
(P2)
- Allow
configuration so that if a
viewport opens without explicit user request, its content
focus does not automatically become the current
focus.
- Configuration is preferred, but is not required if the content focus can
only ever be moved on explicit
user request.
Techniques for checkpoint 5.1
5.2 Keep viewport on top. (P2)
- 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.
Techniques for checkpoint 5.2
5.3 Manual viewport open only. (P2)
- Allow
configuration so that viewports only open on explicit
user request.
- In this configuration, 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.
- If a viewport (e.g., a frame set) contains other viewports, these
requirements only apply to the outermost container viewport.
- Configuration is preferred, but is not required if viewports can only ever
open on explicit
user request.
- 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.
Techniques for checkpoint 5.3
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.5 (for programmatic
alert of changes to the user interface).
5.4 Selection and focus in viewport.
(P2)
- Ensure that when a viewport's
selection or
content focus changes, it is at least partially in the viewport
after the change.
Techniques for checkpoint 5.4
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.
5.5 Confirm form submission. (P2)
- Allow
configuration to prompt the
user to confirm (or cancel) any form submission.
- Configuration is preferred, but it not required if forms can only ever be
submitted on explicit
user request.
Techniques for checkpoint 5.5
Note: For example, do not submit a form automatically when
a menu option is selected, when all fields of a form have been filled out, or
when a "mouseover" or "change" event occurs.
5.6 Confirm fee links. (P2)
- Allow
configuration to prompt the
user to confirm (or cancel) any payment that results from activation
of a fee
link.
- Configuration is preferred, but is not required if fee links can only ever
be activated on explicit
user request.
Techniques for checkpoint 5.6
5.7
Manual viewport close only. (P3)
- Allow
configuration to prompt the
user to confirm (or cancel) closing any viewport that starts to close without
explicit
user request.
Techniques for checkpoint 5.7
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 superior access.
When conventional APIs do not allow users to satisfy the requirements of these
checkpoints, however, developers may implement alternative APIs in order to
conform to this document.
Checkpoints
6.1 DOM read access. (P1)
- Provide programmatic read access to HTML and
XML content by
conforming to the following modules of the W3C Document Object Model DOM Level 2 Core Specification [DOM2CORE] and exporting the
interfaces they define:
- the Core module for HTML;
- the Core and XML modules for XML.
Techniques for checkpoint 6.1
Note: Please refer to the "Document Object Model (DOM)
Level 2 Core Specification"
[DOM2CORE] for information about HTML and
XML versions covered.
6.2 DOM write access. (P1)
- If the user can modify HTML and XML
content through the user
interface, provide the same functionality programmatically by
conforming to the following modules of the W3C Document Object Model DOM Level 2 Core Specification [DOM2CORE] and exporting the
interfaces they define:
- the Core module for HTML;
- the Core and XML modules for XML.
Techniques for checkpoint 6.2
Note: For example, if the user interface allows users to
complete HTML forms, this must also be possible through the
required DOM APIs. Please refer to the "Document Object
Model (DOM) Level 2 Core Specification"
[DOM2CORE] for information about HTML and
XML versions covered.
6.3 Programmatic access to
non-HTML/XML content. (P1)
- For markup languages other than HTML and
XML, provide programmatic read access to
content.
- Provide programmatic write access for those parts of
content that the user can modify through
the user interface. To satisfy these requirements, implement at least one API that is either
- defined by a W3C Recommendation, or
- a publicly documented API 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, implement at least one publicly documented
API to satisfy the requirements, and follow operating environment
conventions for the use of input and output
APIs.
- 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.
Techniques for checkpoint 6.3
Note: This checkpoint addresses content not covered by
checkpoints checkpoint 6.1
and checkpoint 6.2.
6.4 Programmatic operation. (P1)
- Provide programmatic read access to user agent user interface controls.
- Provide programmatic write access for those controls that the user can
modify through the user interface. For security reasons, user agents are not
required to allow instructions in
content to modify user agent user interface controls.
- To satisfy these requirements, implement at least one API that is either
- defined by a W3C Recommendation, or
- a publicly documented API 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, implement at least one publicly documented
API that allows programmatic operation of all of the functionalities that are
available through the user agent user interface, and follow operating
environment
conventions for the use of input and output
APIs.
- 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.
For user agent features.
Techniques for checkpoint 6.4
Note: APIs used to satisfy the requirements of this
checkpoint may be platform-independent APIs such as 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.
6.5 Programmatic alert of changes. (P1)
- Provide programmatic alert of changes to
content, user
interface controls,
selection, content
focus, and user
interface focus.
- To satisfy these requirements, implement at least one API that is either
- defined by a W3C Recommendation, or
- a publicly documented API 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, implement at least one publicly documented
API to satisfy the requirements, and follow operating environment
conventions for the use of input and output
APIs.
- 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.
For both content and user agent.
Techniques for checkpoint 6.5
Note: For instance, when user interaction in one frame
causes automatic changes to content in another, provide a programmatic alert.
This checkpoint does not require the user agent to alert the user of
rendering changes caused by content (e.g., an animation effect or an
effect caused by a style sheet), just changes to the
content itself.
6.6 Conventional keyboard APIs. (P1)
- Follow
operating environment conventions when implementing
APIs for the keyboard.
- If such APIs for the keyboard do not exist, implement
publicly documented APIs for the keyboard.
Techniques for checkpoint 6.6
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.
6.7 API character encodings. (P1)
- For an API implemented to satisfy requirements of this document, support
the character
encodings required for that API.
For both content and user agent.
Techniques for checkpoint 6.7
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.
6.8 DOM CSS access. (P2)
- For user agents that implement
Cascading Style Sheets (CSS), provide programmatic access to
those style sheets in content by
conforming to the CSS module of the W3C Document Object Model (DOM) Level 2 Style Specification [DOM2STYLE] and exporting the
interfaces it defines.
- For the purposes of satisfying this checkpoint, Cascading Style Sheets
(CSS) are defined by either CSS Level 1 [CSS1] or CSS Level 2 [CSS2].
Techniques for checkpoint 6.8
Note: Please refer to the "Document Object Model (DOM)
Level 2 Style Specification"
[DOM2STYLE] for information about CSS versions
covered.
6.9 Timely access. (P2)
- Ensure that programmatic exchanges proceed in a timely manner.
For both content and user agent.
Techniques for checkpoint 6.9
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 increases predictability for users
and for developers of assistive technologies. Platform guidelines
explain what users will expect from the look and feel of the user interface,
keyboard conventions, documentation, etc. Platform guidelines also include
information about accessibility features that the user agent should adopt
rather than reimplement.
Checkpoints
7.1 Focus and selection conventions.
(P1)
- Follow
operating environment conventions that benefit accessibility when
implementing the
selection, content
focus, and user
interface focus.
Techniques for checkpoint 7.1
Note: This checkpoint is an important special case of checkpoint 7.3. See also checkpoint 9.1 and checkpoint 9.2.
7.2 Respect input configuration conventions. (P1)
- Ensure that default input configurations of the user agent do not
interfere with
operating environment accessibility conventions (e.g., for keyboard
accessibility).
For user agent features.
Techniques for checkpoint 7.2
Note: Information about operating environment accessibility
conventions is available in the Techniques document
[UAAG10-TECHS].
See also checkpoint 11.5.
7.3 Operating environment conventions.
(P2)
- Follow
operating environment conventions that benefit accessibility. In
particular, follow conventions that benefit accessibility for user
interface design, keyboard configuration, product installation, and
documentation.
- 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.
Techniques for checkpoint 7.3
Note: Some of these conventions (e.g., sticky keys, mouse
keys, show sounds, etc.) are discussed in the Techniques document
[UAAG10-TECHS].
7.4 Input configuration indications.
(P2)
- Follow
operating environment conventions to indicate the input
configuration.
For user agent features.
Techniques for checkpoint 7.4
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 also checkpoint
11.5.
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.
Checkpoints
8.1 Implement accessibility features.
(P1)
- Implement the accessibility features of specifications (markup languages,
style sheet languages, metadata languages, graphics formats, etc.). For the
purposes of this checkpoint, an accessibility feature is either
- one identified as such, or
- one that allows the author to satisfy any requirement of the "Web Content
Accessibility Guidelines 1.0"
[WCAG10].
For all content.
Techniques for checkpoint 8.1
Note: This checkpoint applies to both W3C-developed and
non-W3C specifications. The Techniques document
[UAAG10-TECHS] provides information about the accessibility features
of some specifications, including W3C specifications. 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.
8.2 Conform to specifications. (P2)
- 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].
- 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.
- 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.
For all content.
Techniques for checkpoint 8.2
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]. 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.
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.).
Checkpoints
9.1 Provide content focus. (P1)
- 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.
Techniques for checkpoint 9.1
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.
9.2 Provide user interface focus. (P1)
- Provide a user
interface focus.
Techniques for checkpoint 9.2
9.3 Move content focus. (P1)
- 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 also checkpoint
5.1.
- If the author has not specified a navigation order, allow at least forward
sequential navigation to each element, in document order.
- The user agent may also include disabled
elements in the navigation order.
Techniques for checkpoint 9.3
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.
9.4 Restore history. (P1)
- 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, restore the
saved values for these three state variables.
Techniques for checkpoint 9.4
Note: For example, when the user uses the "back button",
restore the point of regard, content focus, and selection for previous state in
the viewport's history.
9.5 No events on focus change.
(P2)
- Allow
configuration so that moving the content
focus to or from an enabled element does not automatically activate
any explicitly associated
event handlers.
Techniques for checkpoint 9.5
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.
9.6 Show event handlers. (P2)
- For the element with
content focus, make available the list of input device event
handlers explicitly associated with the element.
Techniques for checkpoint 9.6
Note: For example, allow the user to query the element with
content focus for the list of input device event handlers, 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.
9.7 Move content focus optimally. (P2)
- Allow the user to move the
content focus to any enabled element in the
viewport.
- If the author has not specified a navigation order, allow at least forward
and reverse sequential navigation to each element, in document order.
- The user agent must not include disabled
elements in the navigation order.
Techniques for checkpoint 9.7
Note: This checkpoint is a special case of checkpoint 9.3.
9.8 Text search.
(P2)
- 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.
For all rendered content.
Techniques for checkpoint 9.8
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 environments conventions for indicating the result of a
search (e.g., selection
or content
focus).
9.9 Structured navigation. (P2)
- Allow the user to navigate efficiently to and among important structural
elements in rendered
content.
- Allow forward and backward sequential navigation to these important
structural elements.
Techniques for checkpoint 9.9
Note: This specification intentionally does not identify
which "important elements" must be navigable as this will vary according to
markup language. 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.
9.10
Configure important elements. (P3)
- Allow
configuration of the set of important elements required by checkpoint 9.9 and checkpoint 10.5.
- Allow the user to include and exclude element types in the set of
elements.
Techniques for checkpoint 9.10
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. These clues need to
be available to the user in a device-independent manner;
- information about specific elements, such as the dimensions of a table, the
length of an audio clip, the structure of a form, whether following a link will
involve a fee, etc.
- information about relationships among elements, such as between table cells
and related table headers.
- information about the structure of content. For instance, a navigable
outline view can accelerate access to content while preserving context.
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.
This guideline also includes requirements to allow the user to control some
user agent behavior (form submission and activation of fee links) that, if
carried out automatically, might go unnoticed by some users (e.g., users with
blindness) or might disorient others (e.g., some users with a cognitive
disability).
Checkpoints
10.1 Table orientation. (P1)
- Make available to the user the purpose of each rendered table (e.g., as
expressed in a summary or table caption) and the relationships among the table
cells and headers.
Techniques for checkpoint 10.1
Note: This checkpoint refers only to table purpose and
cell/header relationship information that the user agent can
recognize. Depending on the table, some techniques may be more
efficient than others for conveying data relationships. For many tables, user
agents rendering in two dimensions may satisfy this checkpoint by rendering a
table as a grid and by ensuring that users can find headers associated with
cells. However, for large tables or small viewports, allowing the user to query
cells for information about related headers may improve access. This checkpoint
is an important special case of checkpoint 2.1.
10.2 Highlight selection and content focus.
(P1)
- Provide a mechanism for
highlighting the
selection and
content focus of each viewport.
- The highlight mechanism must not rely on color alone.
- Allow global
configuration of selection and focus highlight styles.
- For graphical viewports, if the highlight mechanism involves colors or text
decorations, offer a range of colors or text decorations 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 text
decorations,
- or, if no such utility is available, the range of colors or text
decorations supported by the conventional APIs of the operating environment for
specifying colors or drawing text.
Techniques for checkpoint 10.2
Note: Examples of highlight mechanisms include foreground
and background color variations, underlining, distinctive synthesized speech
prosody, rectangular boxes, 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.
See also checkpoint
7.1.
10.3 Distinct default highlight
styles. (P1)
- Ensure that all of the default
highlight styles for the
selection and
content focus, as well as for enabled
elements, recently visited links, and fee links
in rendered
content:
- do not rely on color alone, and
- differ from each other, and not by color alone.
- This checkpoint does not apply to those highlight styles inherited from the
operating environment as default values, as long as the user can change the
styles in the operating environment.
Techniques for checkpoint 10.3
Note: For instance, by default a graphical user agent may
present the selection using color and a dotted outline, the focus using a solid
outline, enabled elements as underlined in blue, recently visited links as
dotted underlined in purple, and fee links using a special icon or flag to draw
the user's attention.
10.4 Highlight special elements. (P2)
- Provide a mechanism for
highlighting all enabled elements, recently visited links, and
fee links
in rendered
content.
- Allow the user to configure the highlight styles. The highlight mechanism
must not rely on color alone.
- For graphical viewports, if the highlight mechanism involves text size,
font family, colors, or text decorations, offer the corresponding range
of values required by
checkpoint 4.1,
checkpoint 4.2,
checkpoint 4.3, or checkpoint 10.2.
- For a graphically rendered enabled elements, highlight
the most specific rendered element that:
- encompasses the enabled element, and
- is rendered as a coherent unit according to specification.
For example, an HTML user agent rendering a PNG image as part of an image map
is only required to highlight the image as a whole, not each enabled region. On
the other hand, an SVG user agent rendering an SVG image with embedded
graphical links is required to highlight each graphical link that may be
rendered independently according to the SVG specification.
Techniques for checkpoint 10.4
Note: Examples of highlight mechanisms include foreground
and background color variations, font variations, underlining, distinctive
synthesized speech prosody, rectangular boxes, etc.
10.5
Outline view. (P2)
- 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, etc.).
- What constitutes a label is defined by each markup language specification.
A label is not required to be text
only.
Techniques for checkpoint 10.5
Note: This checkpoint is meant to provide the user with a
simplified view of content (e.g, a table of contents). 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. For important
elements that do not have associated labels, user agents may generate labels
for the outline view. 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
also checkpoint 9.10.
10.6 Provide link information. (P3)
- 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,
- whether traversing it may involve a fee, and
- information about the type, size, and natural language of linked Web
resources.
- The user agent is not required to compute or make available information
that requires retrieval of linked
Web resources.
Techniques for checkpoint 10.6
Checkpoints for the user interface
10.7 Highlight current viewport.
(P1)
- Provide a mechanism for
highlighting the viewport with the current
focus (including any frame that takes current focus).
- For graphical viewports, the default highlight mechanism must not rely on
color alone.
- This default color requirement does not apply if the highlight mechanism is
inherited from the operating environment as the default and the user can change
it in the operating environment.
Techniques for checkpoint 10.7
Note: This checkpoint is an important special case of checkpoint 1.1. See also
to checkpoint
checkpoint 7.1.
10.8 Indicate rendering progress. (P3)
- 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.).
- 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.
- For two-dimensional renderings, relative position includes both vertical
and horizontal positions.
- 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.
Techniques for checkpoint 10.8
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.
Checkpoints
11.1 Current user bindings. (P1)
- Provide information to the user about current user preferences for input
configurations.
- 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).
For user agent features.
Techniques for checkpoint 11.1
11.2 Current author bindings.
(P2)
- Provide a centralized view of the current author-specified input
configuration bindings.
- The user agent may satisfy this checkpoint by providing different views for
different input modalities (keyboard, pointing device, voice, etc.).
For all content.
Techniques for checkpoint 11.2
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.
11.3 Override bindings. (P2)
- Allow the user to override
any binding that is part of the user agent default input
configuration.
- 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.
Techniques for checkpoint 11.3
Note: See also checkpoint 11.5, checkpoint 11.7, and checkpoint 12.3.
11.4 Single key access. (P2)
- 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. In this checkpoint, "key"
refers to a physical key of the keyboard (rather than, say, a character of the
document character set).
- For each functionality in the set required by checkpoint 11.5, allow the
user to configure
a single-key binding (i.e., one key press performs the task, with zero modifier
keys).
- If the number of physical keys on the keyboard is less than the number of
functionalities required by checkpoint 11.5, allow single-key bindings for as many of
those functionalities as possible.
- The single-key binding requirements 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).
- The user agent is not required to allow the user to override
conventional bindings for the operating environment (e.g., for access to
help).
- This checkpoint does not require single physical key bindings for character
input, only for the activation of user agent functionalities.
For user agent features.
Techniques for checkpoint 11.4
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.6.
11.5
Default binding requirements. (P2)
- 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, fast advance, and fast reverse 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 new resource;
- add to favorites (i.e., bookmarked resources);
- view favorites;
- stop loading resource;
- reload resource;
- refresh rendering;
- forward one viewport, and back one viewport;
- next line, and previous line.
For user agent features.
Techniques for checkpoint 11.5
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 ensured by the configuration requirements of checkpoint 11.3.
11.6 User profiles. (P2)
- 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).
For user agent features.
Techniques for checkpoint 11.6
11.7 Configure tool bars. (P3)
- For graphical user interfaces, allow the user to configure
the position of controls on tool bars of the user agent user interface, to add or remove
controls for the user interface from a predefined set, and to restore the
default user interface.
For user agent features.
Techniques for checkpoint 11.7
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 (e.g.,
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 (checkpoint 12.2, checkpoint 12.3, and checkpoint 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).
Refer to checkpoint 7.3
for information about following system conventions for documentation.
Checkpoints
12.1 Accessible documentation. (P1)
- 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].
For user agent features.
Techniques for checkpoint 12.1
12.2 Document accessibility features.
(P1)
-
Document all user agent features that benefit accessibility.
- 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).
- 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.
For user agent features.
Techniques for checkpoint 12.2
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.
12.3 Document default bindings.
(P1)
-
Document the default user agent input
configuration (e.g., the default keyboard bindings).
For user agent features.
Techniques for checkpoint 12.3
Note: If the default input configuration is inconsistent
with conventions of the operating environment, the documentation should alert
the user.
12.4 Document changes. (P2)
-
Document changes from the previous version of the user agent to
accessibility features, including accessibility features of the user
interface.
- Accessibility features are those defined in checkpoint 12.2.
For user agent features.
Techniques for checkpoint 12.4
12.5 Dedicated section on accessibility.
(P2)
- Provide a centralized view of all features of the user agent that benefit
accessibility in a dedicated section of the
documentation.
- The features that benefit accessibility are those defined in checkpoint 12.2.
For user agent features.
Techniques for checkpoint 12.5
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.