This section describes the status of this document at the time of its
publication. Other documents may supersede this document. The latest status of
this document series is maintained at the W3C.

This is the 10 June 2000 Working Draft of Techniques for User Agent
Accessibility Guidelines 1.0, for review by W3C Members and other interested
parties. It is a draft document and may be updated, replaced or obsoleted by
other documents at any time. It is inappropriate to use W3C Working Drafts as
reference material or to cite them as other than "work in progress". This is
work in progress and does not imply endorsement by, or the consensus of, either
W3C or participants in the WAI User Agent (UA) Working
Group.

While User Agent Accessibility Guidelines 1.0 strives to be a stable
document (as a W3C Recommendation), the current document is expected to evolve
as technologies change and content developers discover more effective
techniques for designing accessible Web sites and pages.

Note: This document supports direct keyboard navigation to
the table of contents via the "c" character. Users may have to use additional
keyboard strokes depending on their operating environment. Not all user agents
support direct keyboard access.

This document provides some suggestions for satisfying the requirements of
the "User Agent Accessibility Guidelines 1.0" [UAAG10]. The techniques listed in this document are
not required for conformance to the Guidelines. These techniques are not
necessarily the only way of satisfying the checkpoint, nor are they necessarily
a definitive set of requirements for satisfying a checkpoint.

Section 2 of this document reproduces the guidelines and checkpoints of the
User Agent Accessibility Guidelines 1.0 [UAAG10]. Each checkpoint definition includes a link to
the checkpoint definition in User Agent Accessibility Guidelines 1.0 [UAAG10]. Each checkpoint
definition is followed by a list of techniques, information about related
resources, and references to the accessibility topics in section 3. These
accessibility topics may apply to more than one checkpoint and so have been
split off into a stand-alone section.

Note: Most of the techniques in this document are designed
for graphical desktop browsers and multimedia players. However, some of them
also make sense for assistive technologies and other user agents. In
particular, techniques about communication between user agents will benefit
assistive technologies. Refer, for example, to the
appendix on loading assistive technologies for access to the document object
model.

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.

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.

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.

This section lists each checkpoint of User Agent Accessibility Guidelines
1.0 [UAAG10] along
with some possible techniques for satisfying it. Each checkpoint also links to
more general accessibility topics where appropriate.

1.1 Ensure that every functionality
available through the user
interface is also available through every input API implemented by the user agent. [Priority 1] (Checkpoint
1.1)

Note: This checkpoint does not require developers to
implement all operating system input APIs, only to make the software accessible through
those they do implement. The device-independence required by this checkpoint
applies to the functionalities described by the other checkpoints in this
document (e.g., installation, documentation, user agent user interface configuration, etc.). This
checkpoint does not require developers to reimplement the input methods
associated with the keyboard, pointing device, voice, and other device APIs. For example,
developers are not required to implement text input through a mouse API or
pointer motion through a keyboard API.

Techniques:

Ensure that the user can do the following with all supported input
devices:

Select content and operate on it. For
example, if the user can select text with the mouse and make that text the
content of a new link by pushing a button, they must also be able to do so
through the keyboard and other supported devices. Other operations include cut,
copy, and paste.

Set the focus. Ensure that software may be
installed, uninstalled, and updated in a device-independent manner.

Do not bypass the standard output APIs when rendering information (e.g.,
for reasons of speed, efficiency, etc.). For example, do not bypass standard APIs to manipulate the
memory associated with rendered
content, since assistive
technologies monitor rendering through the APIs. Note: When available,
developers should use
APIs at a higher level of abstraction than the standard device APIs
for the operating system. If these higher level APIs do not use the standard
device APIs properly, developers should also use the standard device APIs.

Techniques:

Operating system and application frameworks provide standard mechanisms for
communication with input devices. In the case of Windows, OS/2, the X Windows
System, and Mac OS, the window manager provides Graphical User Interface
(GUI) applications with this information through the
messaging queue. In the case of non-GUI applications, the compiler run-time
libraries provide standard mechanisms for receiving keyboard input in the case
of desktop operating systems. Should you use an application framework such as
the Microsoft Foundation Classes, the framework used must support the same
standard input mechanisms.

Do not communicate directly with an input device; this may circumvent
system messaging. For instance, in Windows, do not open the keyboard device
driver directly. It is often the case that the windowing system needs to change
the form and method for processing standard input mechanisms for proper
application coexistence within the user interface framework.

Do not implement your own input device event queue mechanism; this may
circumvent system messaging. Some assistive technologies use standard system
facilities for simulating keyboard and mouse events. From the application's
perspective, these events are no different than those generated by the user's
actions. The Journal Playback Hooks (in both OS/2 and Windows) is one example
of an application that feeds the standard event queues.

Operating system and application frameworks provide standard mechanisms for
using standard output devices. In the case of common desktop operating systems
such as Windows, OS/2, and Mac OS, standard APIs are provided for writing to the display and the
multimedia subsystems.

Do not render text in the form of a bitmap before transferring to the
screen, since some screen readers rely on the user agent's offscreen model. An
offscreen model is rendered
content created by an assistive technology that is based on the rendered content of another user
agent. Assistive technologies that rely on an offscreen model generally
construct it by intercepting standard system drawing calls. For example, in the
case of display drivers, some screen readers are designed to monitor what is
drawn on the screen by hooking drawing calls at different points in the drawing
process. While knowing about the user agent's formatting may provide some
useful information to assistive technologies, this document emphasizes access
to the document object model rather than
a particular rendering. For instance, instead of relying on system calls to
draw text, assistive technologies should access the text through the document
object model.

Common operating system 2D graphics engines and drawing libraries provide
functions for drawing text to the screen. Examples of this are the Graphics
Device Interface (GDI) for Windows, Graphics Programming Interface (GPI) for
OS/2, and the X library (XLIB) for the X Windows System or Motif.

Do not communicate directly with an output device.

Do not draw directly to the video frame buffer.

Do not provide your own mechanism for generating pre-defined system
sounds.

When writing textual information in a GUI operating system, use standard operating system APIs for drawing
text.

Use operating system resources for rendering audio information. When doing
so, do not take exclusive control of system audio resources. This could prevent
an assistive technology such as a screen reader from speaking if they use
software text-to-speech conversion. Also, in operating systems like Windows, a
set of standard audio sound resources are provided to support standard sounds
such as alerts. These preset sounds are used to activate SoundSentry graphical cues when a problem occurs; this
benefits users with hearing disabilities. These cues may be manifested by
flashing the desktop, active caption bar, or active window. It is important to
use the standard mechanisms to generate audio feedback so that operating system
or special assistive technologies can add additional functionality for users
with hearing disabilities.

Enhance the functionality of standard system controls to improve
accessibility where none is provided by responding to standard keyboard input
mechanisms. For example provide keyboard navigation to menus and dialog box
controls in the Apple Macintosh operating system. Another example is the Java
Foundation Classes, where internal frames do not provide a keyboard mechanism
to give them focus. In this case, you will need to add keyboard activation
through the standard keyboard activation facility for Abstract Window Toolkit
components.

1.3 Implement the standard keyboard API of the operating system
and ensure that every functionality available through the user interface is
available through this API.
[Priority 1] (Checkpoint
1.3)

For example, users who are blind or have physical disabilities must be able
to activate text links, the links in a client-side
image map, and form controls without a pointing
device. Note: This checkpoint is an important special case of
checkpoint 1.1.

In the "Document Object Model (DOM) Level 2
Specification" [DOM2],
all elements may have associated behaviors. Assistive technologies should be
able to activate these elements through the DOM. For example, a DOM 'focusin'
event may cause a JavaScript function to construct a pull-down menu. Allowing
programmatic activation of this function will allow users to operate the menu
through speech input (which benefits users of voice browsers in addition to
assistive technology users). Note that, for a given element, the same event may
trigger more than one event handler, and assistive technologies must be able to
activate each of them. Descriptive information about handlers can allow
assistive technologies to select the most important functions for activation.
This is possible in the Java Accessibility API [JAVAAPI], which provides an an
AccessibleAction Java interface. This interface provides a list of actions and
descriptions that enable selective activation. Refer also to checkpoint
5.3.

1.5 Ensure every non-text message (e.g., prompt, alert,
notification, etc.) that is part of the user agent's user interface also has a
text equivalent in the user interface.
[Priority 1] (Checkpoint 1.5)

Note: For example, if the user is
notified of an event by an auditory cue, a text equivalent in the status bar
would satisfy this checkpoint. Use standard interface controls so that text
equivalents are available through standard APIs. The text equivalent must be
available to assistive technologies so that it can be rendered visually, as
synthesized speech, or as Braille.
Refer also to checkpoint 5.5.

Techniques:

Render text messages graphically on the status bar of the user
interface.

For graphical user interface elements such as proportional scroll bars,
provide a text equivalent that conveys the proportion of the content viewed
(e.g., as a percentage) and that may be rendered graphically, as synthesized
speech, and as Braille.

For beeps or flashes provide a text
equivalent that can be rendered as Braille, synthesized speech, or
graphically-rendered text.

For user interface components that convey important information using
sound, also provide alternate, parallel graphical representation of the
information for individuals who are deaf, hard of hearing, or operating the
user agent in a noisy or silent environment where the use of sound is not
practical. Provide Braille renderings of text equivalents for deaf-blind users
who cannot use audio or graphical cues and who rely on Braille.

Users must have access to the entire document object, including equivalent alternatives for
content, attributes, style sheets, etc. through the user interface.
This checkpoint does not require that all content be available in every view. A document source view is part of a solution for
providing access to content, but is not a sufficient solution on its own. Refer
to guideline 5 for more
information about programmatic access to content.

Techniques:

Some users benefit from concurrent access to primary and alternative
content. For instance, users with low vision may want to view images (even
imperfectly) but require a text
equivalent for the image; the text may be rendered with a large font
or as speech. If a multimedia presentation has several
captions (or subtitles) available, allow the user to choose from
among them. Captions might differ in level of detail, reading levels, natural language, etc.

When content changes dynamically (e.g., due to scripts or content refresh),
users must have access to the content before and after the change.

Provide structured (not all at once) access to attribute values. For
instance, allow the user to select and element and read values for all
attributes set for that element. For many attributes, this type of inspection
should be significantly more usable than a document source view.

A document source view may be the most usable readily-achievable view for
some content such as embedded fragments of style and script languages.

Sections 10.4 ("Client Error 4xx") and 10.5 ("Server Error 5xx") of the
HTTP 1.1 specification state that user agents should have the following
behavior in case of these error conditions:

Except when responding to a HEAD request, the server SHOULD include an
entity containing an explanation of the error situation, and whether it is a
temporary or permanent condition. These status codes are applicable to any
request method. User agents SHOULD display any included entity to the user.

Make available information about abbreviation and acronym expansions. For
instance, in HTML, look for abbreviations specified by the ABBR and ACRONYM
elements. The expansion may be given with the "title" attribute (refer to the
Web Content Accessibility Guidelines 1.0 [WCAG10], checkpoint 4.2). To provide expansion
information, user agents may:

Allow the user to configure that the expansions be used in place of the
abbreviations,

Provide a list of all abbreviations in the document, with their expansions
(a generated glossary of sorts)

Generate a link from an abbreviation to its expansion.

Allow the user to query the expansion of a selected or input
abbreviation.

If an acronym has no explicit expansion in one location, look for another
occurrence in content with an explicit expansion. User agents may also look for
possible expansions (e.g., in parentheses) in surrounding context, though that
is a less reliable repair.

2.2 For presentations that require user
input within a specified time interval, allow the user to configure the time interval (e.g., to
extend it or to cause the user agent to pause the presentation automatically
and await user input before proceeding).
[Priority 1] (Checkpoint
2.2)

Techniques:

Render time-dependent links as a static list that occupies the same screen
real estate; authors may create such documents in SMIL 1.0 [SMIL]. Include temporal context in the list
of links. For example, provide the time at which the link appeared along with a
way to easily jump to that portion of the presentation.

Provide easy-to-use controls (including both mouse and keyboard commands)
to allow users to pause a presentation and advance and rewind by small or large
time increments. Note: When a user must respond to a link by
pausing the program and activating the link, the time dependent nature of the
link does not change since the user must respond somehow in the predetermined
time. The pause feature is only effective in conjunction with the ability to
rewind to the link, or when the pause can be configured to stop the
presentation automatically and require the user to respond before continuing,
either by responding to the user input or by continuing with the flow of the
document.

Highlight the fact that there are active elements in a presentation and
allow users to navigate to and activate them. For example, indicate the
presence of active elements on the status bar and allow the user to navigate
among them with the keyboard or mouse.

For example, if an image in an HTML document has text equivalents, provide access to them by
rendering them nearby, allowing the user to configure the user agent to render
them in place of the image, or allowing the user to follow a readily available
link to them.

Allow users to choose more than one equivalent at a given time. For
instance, multilingual audiences may wish to have captions in different natural languages on the screen
at the same time. Users may wish to use both captions and auditory descriptions
concurrently as well.

In the user interface, construct a list of all available tracks from short
descriptions provided by the author (e.g., through the "title" attribute).

Allow the user to configure different
natural language preferences for different types of equivalents
(e.g., captions and auditory descriptions). Users with disabilities may need to
choose the language they are most familiar with in order to understand a
presentation for which equivalent tracks are not all available in all desired
languages. In addition, some users may prefer to hear the program audio in its
original language while reading captions in another, fulfilling the function of
subtitles or to improve foreign language comprehension. In classrooms, teachers
may wish to configure the language of various multimedia elements to achieve
specific educational goals.

Consider system level natural language preferences as the user's default
language preference. However, do not send HTTP Accept-Language request headers
([RFC2616],
section 14.4) based on the operating system preferences. First, there may be a
privacy problem as indicated in RFC 2616, section 15.1.4 "Privacy Issues
Connected to Accept Headers". Also, the operating system defines one language,
while the Accept-Language request header may include many languages in
different priorities. Setting Accept-Language to be the operating system
language may prevent a user from receiving content from a server that does not
have a match for this particular language but does for other languages
acceptable to the user.

Captions and auditory descriptions may
not make sense unless rendered synchronously with the primary content. For
instance, if someone with a hearing disability is watching a video presentation
and reading associated captions, the captions must be synchronized with the audio so that the
individual can use any residual hearing. For auditory descriptions, it is
crucial that the primary auditory track and the auditory description track be
synchronized to avoid having them both play at once, which would reduce the
clarity of the presentation.

The idea of "sensible time-coordination" of components in the definition of
synchronize centers on the idea of
simultaneity of presentation, but also encompasses strategies for handling
deviations from simultaneity resulting from a variety of causes. Consider how
deviations might be handled for captions for a
multimedia presentation such as a movie clip. Captions consist of a text
equivalent of the auditory track that is synchronized with the visual track.
Captions are essential for individuals who require an alternative way of
accessing the meaning of audio, such as individuals who are deaf. Typically, a
segment of the caption text appears visually near the video for several second
while the person reads the text. As the visual track continues, a new segment
of the caption text is presented. However, a problem arises if the caption text
is longer than can fit in the display space. This can be particularly difficult
if due to a visual disability, the font size has been enlarged, thus reducing
the amount of caption text that can be presented. The user agent must respond
sensibly to such problems, for example by ensuring that the user has the
opportunity to navigate (e.g., scroll down or page down) through the caption
segment before proceeding with the visual presentation and presenting the next
segment.

Developers of user agents must determine how they will handle
synchronization challenges, such as:

Under what circumstances will the "primary" presentation automatically
pause? Some circumstances where this might occur include:

the segment of caption text is more than can fit on the visual display

the user wishes more time to read captions or the collated text
transcript

the auditory description is of longer duration than the natural pause in
the audio.

Once the "primary" presentation has paused, then under what circumstances
will it resume (e.g., only when the user signals it to resume, or based on a
predefined pause length)?

If the user agent allows the user to jump to a location in a presentation
by clicking on a text equivalent (or some outline of it), then do all rendered
equivalents jump at the same time? Will one be able to return to one's previous
location (or undo the action)?

Developers of user agents must anticipate many of the challenges that may
arise in synchronization of diverse equivalents.

The term "synchronization cues" in checkpoint 2.4 refers to pieces of information that may
affect synchronization, such as the size and expected duration of equivalents
and their segments, the type of element and how much those elements can be sped
up or slowed down (both from technological and intelligibility standpoints),
user preferences, etc.

User agents that implement SMIL 1.0 ([SMIL]) should implement the "Accessibility Features of
SMIL"
[SMIL-ACCESS]. In particular, SMIL user agents should allow users to
configure whether they want to view captions, and this user interface switch
should be bound to the 'system-captions' test attribute. Users should be able
to indicate a preference for receiving available auditory descriptions, but
SMIL 1.0 does not include a mechanism equivalent to 'system-captions' for
auditory descriptions. The next version of SMIL is expected to include a test
attribute for auditory descriptions.

Another SMIL 1.0 test attribute, 'system-overdub-or-captions', allows users
to select between subtitles and overdubs in multilingual presentations. User
agents should not interpret a value of 'caption' for this test
attribute as meaning that the user prefers accessibility captions; that is the
purpose of the 'system-captions' test attribute. When subtitles and
accessibility captions are both available, users who are deaf may prefer to
view captions, as they generally contain information not in subtitles:
information on music, sound effects, who is speaking, etc.

User agents that play QuickTime movies should allow the user to turn on and
off the different tracks embedded in the movie. Authors may use these alternate
tracks to provide equivalent alternatives. The Apple QuickTime player currently
provides this feature through the menu item "Enable Tracks."

User agents that play Microsoft Windows Media Object presentations should
provide support for Synchronized Accessible Media Interchange (SAMI [SAMI], a protocol for creating
and displaying captions) and should allow users to configure how captions are
viewed. In addition, user agents which play Microsoft Windows Media Object
presentations should enable people to turn on and off other equivalent
alternatives, including auditory description and alternate visual tracks.

For other formats, at a minimum, users must be able to turn on and off
auditory descriptions and captions.

User agents should render nothing in this case because the author may
specify a null text equivalent for content that has no function in the page
other than as decoration. In this case, the user agent should not render
generic labels such as "[INLINE]" or "[GRAPHIC]".

Allow the user to toggle the rendering of null text equivalents: between
nothing and an indicator of a null equivalent (e.g., an icon with the text
equivalent "EMPTY TEXT EQUIVALENT").

A user agent should treat the
natural language of content as part of context information. When the
language changes, the user agent should either render the content in the
supported natural language or notify the user of the language change, if
configured for notification. For instance, a user agent that doesn't support
Korean might allow configuration to announce the language change with the
message "Korean text - unable to read". The user should also be able to choose
no notification of language changes. Rendering could involve speaking in the
designated natural language in the case of a voice browser or screen reader. If
the natural language is not supported, the language change notification could
be spoken in the default language by a screen reader or voice browser.

Switching natural languages for blocks of content may be more helpful than
switching for short phrases. In some language combinations (e.g., Japanese
being the primary and English being the secondary or quoted language), short
foreign language phrases are often well-integrated in the primary language.
Dynamic switching for these short phrases may make the content sound unnatural
and possibly harder to understand. User agents might allow users to choose
elements for which they want notification.

For information on language codes, refer to "Codes for the representation
of names of languages"
[ISO639].

If users do not want to see or hear blocks of content in another natural
language, allow the user to suggest hiding that content (e.g., with style
sheets).

Refer to "Character Model for the World Wide Web" [CHARMOD]. It contains basic definitions
and models, specifications to be used by other specifications or directly by
implementations, and explanatory material. In particular, this document
addresses early uniform normalization, string identity matching, string
indexing, and conventions for URIs.

Implement content negotiation so that users may specify language
preferences. Or allow the user to choose a resource when several are available
in different languages.

Use an appropriate glyph set when rendering visually and an appropriate
voice set when rendering as speech.

A user agent may not be able to render all characters in a document
meaningfully, for instance, because the user agent lacks a suitable font, a
character has a value that may not be expressed in the user agent's internal
character encoding, etc. In this case, section 5.4
of HTML 4.01[HTML4] recommends the following for undisplayable
characters:

Adopt a clearly visible (or audible), but unobtrusive mechanism to alert
the user of missing resources.

If missing characters are presented using their numeric representation, use
the hexadecimal (not decimal) form since this is the form used in character set
standards.

Implement the
'visibility' property of CSS 2 ([CSS2], section 11.2). A value of 'hidden' will cause a
blank place-holder box to be rendered in place of the video on the screen while
retaining the layout of the page. This differs from a value of 'none' for the
'display' property ([CSS2], section 9.2.5), which suppresses rendering of the video
completely and may cause the layout of the page to be changed.

Allow the user to hide a video presentation from view, even though it
continues to play in the background.

Allow the user to turn off animated or blinking text through the user agent user interface (e.g., by
pressing the Escape key to stop animations). Render a still image in
its place.

3.7 Allow the user to turn on and off support for scripts and
applets. [Priority 1] (Checkpoint 3.7)

Note: This is particularly important for scripts that
cause the screen to flicker, since people with photosensitive epilepsy can have
seizures triggered by flickering or flashing, particularly in the 4 to 59
flashes per second (Hertz) range.

3.8 Allow configuration so that author-specified "client-side
redirects" (i.e., those initiated by the user agent, not the server) do not
change content automatically. Allow the user to
access the new content on request (e.g., by following a link). [Priority 2] (Checkpoint
3.8)

Techniques:

Refer to the HTTP 1.1 specification [RFC2616] for information about redirection
mechanisms.

3.9 Allow configuration so that author-specified content
refreshes do not change content automatically. Allow
the user to access the new content on request (e.g., by activating a button).
Advise the user to refresh content according to the same schedule as the
automatic refresh, and indicate persistently that the user has not yet
refreshed content. [Priority 2] (Checkpoint
3.9)

Techniques:

Alert the users to pages that refresh automatically and allow them to
specify a refresh rate through the user agent
user interface.

Allow the user to slow content refresh to once per 10 minutes.

Allow the user to stop automatic refresh, but indicate that content needs
refreshing and allow the user to refresh the content by activating a button or
link. Or, prompt the user and ask whether to continue with forwards.

Some HTML authors create a refresh effect by using a
META element with http-equiv="refresh" and the refresh rate specified in
seconds by the "content" attribute.

The choice of optimal techniques depends in part on which markup language
is being used. For instance, HTML user agents may allow the user to change the
font size of a particular piece of text (e.g., by using CSS user style sheets)
independent of other content (e.g., images). Since the user agent can reflow
the text after resizing the font, the text will become more legible without,
for example, distorting bitmap images. On the other hand, some languages, such
as SVG, do not allow text reflow, which means that changes to font size may
cause text to overlap with other content, reducing accessibility. SVG is
designed to scale, making a zoom functionality the more natural technique for
SVG user agents satisfying this checkpoint.

Allowing the user to slow the presentation of video, animations, and audio
will benefit individuals with specific learning disabilities, cognitive
disabilities, or individuals with newly acquired sensory limitations (such as a
person who is newly blind and learning to use a screen reader). The same
feature will benefit individuals who have beginning familiarity with a natural language.

Allow the user to advance or rewind the presentation in increments. This is
particularly valuable to users with physical disabilities who may not have fine
control over advance and rewind functionalities. Allow users to configure the
size of the increments.

If buttons are used to control advance and rewind, make the advance/rewind
distances proportional to the time the user activates the button. After a
certain delay, accelerate the advance/rewind.

The user agent is expected to allow the user the same
range of positions that is available to the author according to
specification.

Techniques:

Some users need to be able to position captions, etc. so that they do not
obscure other content or are not obscured by other content. Other users (e.g.,
users with screen magnifiers or who have other visual disabilities) require
pieces of content to be in a particular relation to one another, even if this
means that some content will obscure other content.

User agents should implement the positioning features of the employed
markup or style sheet language. Even when a markup language does not explicitly
allow positioning, when a user agent can recognize distinct text transcripts, collated text
transcripts, or captions, the
user agent should allow the user to reposition them. User agents are not
required to allow repositioning when the captions, etc. cannot be separated
from other media (e.g., the captions are part of the video track).

Allow the user to choose whether captions appear at the bottom or top of
the video area or in other positions. Currently authors may place captions
overlying the video or in a separate box. Captions prevent users from being
able to view other information in the video or on other parts of the screen,
making it necessary to move the captions in order to view all content at once.
In addition, some users will find captions easier to read if they can place
them in a location best suited to their reading style.

Allow users to configure a general preference for caption position and to
be able to fine tune specific cases. For example, the user may want the
captions to be in front of and below the rest of the presentation.

Allow the user to drag and drop the captions to a place on the screen. To
ensure device-independence, allow the user to enter the screen coordinates of
one corner of the caption.

Allow the user to position all parts of a presentation rather than trying
to identify captions specifically (i.e., solving the problem generally may be
easier than for captions alone).

Do not require users to edit the source code of the presentation to achieve
the desired effect.

Use audio control mechanisms provided by the operating system. Control of
volume mix is particularly important, and the user agent should provide easy
access to those mechanisms provided by the operating system.

Allow the user to configure how current
focus changes when a new viewport opens. For instance, the user
might choose between these two options:

Do not change the focus when a viewport opens, but notify the user (e.g.,
with a beep, flash, and text message on the status bar). Allow the user to
navigate directly to the new window upon demand.

Change the focus when a window opens and use a subtle alert (e.g., a beep,
flash, and text message on the status bar) to indicate that the focus has
changed.

If a new viewport or prompt appears but
focus does not move to it, notify assistive technologies (per checkpoint 5.5) so that they may
discreetly inform the user.

When a viewport is duplicated, the focus in the new viewport should
initially be the same as the focus in the original viewport. Duplicate
viewports allow users to navigate content (e.g., in search of some information)
in one viewport while allowing the user to quickly return to the point of
regard in the duplicate viewport. There are other techniques for accomplishing
this (e.g., "registers" in emacs).

For user agents that implement CSS 2 [CSS2], the following rule will generate a message to the
user at the beginning of link text for links that are meant to open new windows
when followed:

For HTML[HTML4], allow the user to control the process of opening a document
in a new "target" frame or a viewport created by a script. For example, for
target="_blank", open the window according to the user's
preference.

For SMIL [SMIL],
allow the user to control viewports created with the "new" value of the "show"
attribute.

Note: These modules are defined in DOM
Level 2 [DOM2], chapters
1 and 2. Please refer to that specification for information about which
versions of HTML and XML are supported
and for the definition of a "read-only" DOM. This checkpoint
is an important special case of checkpoint 2.1. For content other than HTML and XML, refer to checkpoint 5.3.

Techniques:

Note that the W3C DOM is designed to be used on a server as well as a
client and does not address some user interface-specific information.

5.2 If the user can modify
HTML and XML content through the user interface, provide the same functionality
programmatically by conforming to the W3C Document Object Model (DOM) Level 2 Core and
HTML modules and exporting the interfaces they define. [Priority 1] (Checkpoint
5.2)

For example, if the user interface allows users to
complete HTML forms, this must also be possible through the
DOM
APIs. Note: These modules are defined in DOM Level
2 [DOM2], chapters 1 and
2. Please refer to DOM Level 2 [DOM2] for information about which versions of
HTML and XML are supported. This
checkpoint is an important special case of checkpoint 2.1. For markup languages other than HTML and
XML, refer to checkpoint
5.3.

Use standard operating system and programming language APIs that support accessibility by
providing a bridge between the standard user interface supported by the
operating system and alternative user interfaces developed by assistive technologies. User
agents that implement these APIs are generally more
compatible with assistive technologies and provide accessibility at no extra
cost. Some public APIs that promote accessibility include:

Sun Microsystems Java Accessibility API ([JAVAAPI]) in Java JDK. If the user agent supports
Java applets and provides a Java Virtual Machine to run them, the user agent
should support the proper loading and operation of a Java native assistive
technology. This assistive technology can provide access to the applet as
defined by Java accessibility standards.

Use standard user interface
controls. Third-party assistive technology developers are more likely able to
access standard controls than custom controls.
If you must use custom controls, review them for accessibility and
compatibility with third-party assistive technology. Ensure that they provide
accessibility information through an API as is done for the standard
controls.

Write output to and take input from standard system APIs rather than directly from hardware
controls. This will enable the I/O to be redirected from or to assistive
technology devices – for example, screen readers and Braille displays
often redirect output (or copy it) to a serial port, while many devices provide
character input, or mimic mouse functionality. The use of generic APIs makes
this feasible in a way that allows for interoperability of the assistive
technology with a range of applications.

For information about rapid access to Internet Explorer's [IE-WIN] DOM through COM,
refer to [BHO].

For example, the programmatic exchange of information
required by other checkpoints in this document must 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. The techniques for
this checkpoint explain how developers can reduce communication delays, e.g.,
to ensure that assistive technologies have timely access to the document object model and other information
needed for accessibility.

Note: This module is defined in DOM
Level 2 [DOM2], chapter
5. Please refer to that specification for information about which versions of
CSS are supported. This checkpoint is an important special
case of checkpoint
2.1.

Note: Operating system conventions that affect
accessibility are those described in this document and in platform-specific
accessibility guidelines. Some of these conventions (e.g., sticky keys, mouse
keys, show sounds, etc.) are discussed in the Techniques document [UAAG10-TECHS].
Refer also to checkpoint
10.2.

Follow operating system and application environment (e.g., Java)
conventions for loading assistive technologies. Refer to the appendix on loading assistive technologies for DOM access for
information about how an assistive technology developer can load its software
into a Java Virtual Machine.

Evaluate the standard interface controls on the target platform against any
built-in operating system accessibility functions (refer to the appendix on accessibility features of some operating
systems). Ensure that the user agent operates properly with all these
functions. Here is a sample of features to consider:

Microsoft Windows offers an accessibility function called "High Contrast".
Standard window classes and controls automatically support this setting.
However, applications created with custom classes or controls work with the
"GetSysColor" API to ensure compatibility with High Contrast.

Apple Macintosh offers an accessibility function called "Sticky Keys".
Sticky Keys operate with keys the operating system recognizes as modifier keys,
and therefore a custom control should not attempt to define a new modifier
key.

Maintain consistency in the user interface between versions of the
software. Consistency is less important than improved general accessibility and
usability, but developers should make changes conservatively to the layout of
user interface controls, the behavior of
existing functionalities, and the default keyboard configuration.

Note: For reasons of backward
compatibility, user agents should continue to implement deprecated features of
specifications. The current guidelines refer to some deprecated language
features that do not necessarily promote accessibility but are widely deployed.
Information about deprecated language features is generally part of the
language's specification.

Techniques:

The requirement of this checkpoint is to implement at least one
W3C Recommendation that is available and appropriate for a particular task. For
example, user agents would satisfy this checkpoint by implementing the Portable
Network Graphics 1.0 specification [PNG] for raster images. In addition, user agents may implement other
image formats such as JPEG, GIF, etc.

If more than one version or level of a W3C Recommendation is appropriate
for a particular task, user agents are encouraged to implement the latest
version.

Specifications that become W3C Recommendations after a user agent's
development cycles permit input are not considered "available" in time for that
version of the user agent.

Each specification defines what conformance means for that
specification.

W3C make available validation services to promote the proper usage and
implementation of specifications. Refer to the:

Note: For example, when all frames of a
frameset are displayed side-by-side, allow the user to navigate among them with
the keyboard. Or, when frames are accessed or viewed one at a time (e.g., by a
text browser or speech synthesizer), provide a list of links to other frames.
Navigating into a viewport makes it the
current viewport.

Techniques:

Refer to the frame techniques. Some
operating systems provide a means to navigate among all open windows using
multiple input devices (e.g., keyboard and mouse). This technique would suffice
for switching among user agent viewports that are separate windows. However,
user agents may also provide a mechanism to shift the user interface focus among user agent windows,
independent of the standard operating system mechanism.

For example, when users navigate "back" and "forth"
among viewports, they should return to the same position they left in the
viewport.

Techniques:

When the user returns to a page after following a link, restore content
focus to that link.

If the user agent allows the user to browse multimedia or audio presentations, when
the user leaves one presentation for another, pause the presentation. When the
user returns to a previous presentation, allow the user to restart the
presentation where it was paused (i.e., return the point of regard to the same place in
space and time). Note: This may be done for a presentation
that is available "completely" but not for a "live" stream or any part of a
presentation that continues to run in the background. Allow the user to
configure whether leaving a viewport pauses a multimedia presentation.

Refer to the HTTP 1.1 specification for information about history
mechanisms ([RFC2616], section 13.13).

Allow the user to sequentially navigate all active elements using a single
key stroke. Many user agents today allow users to navigate sequentially by
repeating a key combination -- for example, using the Tab key for
forward navigation and Shift-Tab for reverse navigation. Because the
Tab key is typically on one side of the keyboard while arrow keys
are located on the other, users should be allowed to configure the user agent
so that sequential navigation is possible with keys that are physically closer
to the arrow keys. Refer also to
checkpoint 10.4.

Provide other sequential navigation mechanisms for particular element types
or semantic units, e.g., "Find the next table" or "Find the previous form." For
more information about sequential navigation of form
controls and form submission, refer to techniques for checkpoint 9.2.

Maintain a logical element navigation order. For instance, users may use
the keyboard to navigate among elements or element groups using the arrow keys
within a group of elements. One example of a group of elements is a set of
radio buttons. Users should be able to navigate to the group of buttons, then
be able to select each button in the group. Similarly, allow users to navigate
from table to table, but also among the cells within a given table (up, down,
left, right, etc.).

The default sequential navigation order should respect the conventions of
the natural language of the
document. Thus, for most left-to-right languages, the usual navigation order is
top-to-bottom and left-to-right. For right-to-left languages, the order would
be top-to-bottom and right-to-left.

Respect author-specified information about navigation order (e.g., the
"tabindex" attribute in HTML 4 [HTML4], section 17.11.1). Allow users to
override the author-specified navigation order (e.g., by offering an
alphabetized view of links or other orderings).

Give the users the option of navigating to and activating a link,
or just moving the content
focus to the link. First-time users of a page may want access to
link text before deciding whether to follow the link (activate). More
experienced users of a page might prefer to follow the link directly, without
the intervening content focus step.

In Java, a component is part of the sequential navigation order when added
to a panel and its isFocusTraversable method returns true. A
component can be removed from the navigation order by extending the component,
overloading this method, and returning false.

This image shows how JAWS for Windows [JFW] allows users to navigate to links in a
document and activate them independently. Users may also configure the user
agent to navigate visited links, unvisited links, or both. Users may also
change the sequential navigation order, sorting links alphabetically or leaving
them in the logical tabbing order. The focus in the links view follows the
focus in the primary view.

Excessive use of sequential navigation can reduce the usability of software
for both disabled and non-disabled users.

Some useful types of direct navigation include: navigation based on
position (e.g., all links are numbered by the user agent), navigation based on
element content (e.g., the first letter of text content), direct navigation to
a table cell by its row/column position, and searching (e.g., based on form
control text, associated labels, or form control names).

Allow users to search and examine time-dependent media elements and links
in a time-independent manner. For example, present a static list of
time-dependent links.

Allow users to find all media elements active at a particular time in the
presentation.

Allow users to view a list of all media elements or links of the
presentations sorted by start or end time or alphabetically.

For frames, allow users to search for content in all frames, without having
to be in a particular frame.

It may be confusing to allow users to search for text content that is
not rendered (and thus that they have not viewed). If this type of search
is possible, notify the user of this particular search mode.

7.6 Allow the user to navigate efficiently to and among important
structural elements identified by the author.
[Priority 2] (Checkpoint 7.6)

Structured navigation of headings, tables, forms, lists, etc., is most
effective when available in conjunction with a configurable view (checkpoint 8.4 and checkpoint 8.5). Use
operating system conventions to indicate navigation progress (e.g., selection or
content focus).

Techniques:

User agents should construct the navigation view with the goal of breaking
content into sensible pieces according to the author's design. In most cases,
user agents should not break down content into individual elements for
navigation; element-by-element navigation of the document object does not meet
the goal of facilitating navigation to important pieces of content.

Instead, user agents are expected to construct the navigation view from
author-supplied markup. For those languages with known conventions for
identifying important components, user agents should construct the navigation
tree from those components, allowing users to navigate to them, skip them, or
navigate into them. In HTML, important elements including headings, tables,
forms, DIV elements (notably with a "title" attribute set), navigation
mechanisms (marked up with MAP), and lists. HTML also allows authors to specify
keyboard configurations ("accesskey", "tabindex"), which can serve as hints
about what the author considers important. Tables and forms illustrate the
utility of a recursive navigation mechanism. The user should be able to
navigate to tables, then change "scope" and navigate within the cells of that
table.

Nested tables (a table within the cell of another table) fit nicely within
this scheme. However, the headers of an nested table may provide important
context for the cells of the same row(s) or column(s) containing the nested
table.

The same ideas apply to forms: users should be able to navigate to a form,
then among the controls within that form.

In SVG, the "g" element
signifies a grouping and should be considered when constructing the navigation
view. In
SMIL, "par", "seq", and "switch" provide information that may be
useful for identifying significant components of content.

User agents should allow users to:

Navigate to a piece of content that the author has identified as important
according to the markup language specification and conventional usage. In HTML,
for example, this includes headings, forms, tables, navigation mechanisms, and
lists.

Navigate past that piece of content (i.e., avoid the details of that
component).

Navigate into that piece of content (i.e., chose to view the details of
that component).

Change the navigation view as they go, expanding and contracting portions
of content that they wish to examine or ignore. This will speed up navigation
and promote orientation at the same time.

Use the DOM [DOM2]
as the basis of structured navigation (e.g., a postorder traversal). However,
for well-known markup languages such as HTML, structured navigation should take
advantage of the structure of the source tree and what is rendered.

Allow navigation based on commonly understood document models, even if they
do not adhere strictly to a Document Type Definition (DTD). For instance, in HTML, although headings
(H1-H6) are not containers, they may be treated as such for the purpose of
navigation. Note that they should be properly nested.

Allow the user to limit navigation to the cells of a table (notably left
and right within a row and up and down within a column). Navigation techniques
include keyboard navigation from cell to cell (e.g., using the arrow keys) and
page up/down scrolling. Refer to the section on
table navigation.

Allow depth-first as well as breadth-first navigation.

Alert the user when navigation has led to the beginning or end of a
structure (e.g., end of a list, end of a form, table row or column end, etc.).
Refer also to checkpoint
1.5.

Provide context-sensitive navigation. For instance, when the user navigates
to a list or table, provide locally useful navigation mechanisms (e.g., within
a table, cell-by-cell navigation) using similar input commands.

From a given element, allow navigation to the next or previous sibling, up
to the parent, and to the end of an element.

Allow the user to navigate characters, words, sentences, paragraphs,
screenfuls, and other pieces of text content that depend on natural language. This benefits users of
speech-based user agents and has been implemented by several screen readers,
including Winvision [WINVISION], Window-Eyes [WINDOWEYES], and JAWS for Windows [JFW].

Allow users to skip author-specified navigation mechanisms such as
navigation bars. For instance, navigation bars at the top of each page at a Web
site may force users with screen readers or some physical disabilities to wade
through many links before reaching the important information on the page. User
agents may facilitate browsing for these users by allowing them to skip recognized navigation bars (e.g., through a
configuration option). Some techniques for this include:

Providing a functionality to jump to the first non-link content.

In HTML, the MAP element may be used to mark up a navigation bar (even when
there is no associated image). Thus, users might ask that MAP elements not be
rendered in order to hide links inside the MAP element. User agents might allow
users to hide MAP elements selectively. For example, hide any MAP element with
a "title" attribute specified. Note: Starting in
HTML 4.01, the MAP element allows block content, not just
AREA elements.

The following is a summary of ideas provided by the National Information
Standards Organization
[NISO]:

A talking book's "Navigation Control Center" (NCC) resembles a traditional
table of contents, but it is more. It contains links to all headings at all
levels in the book, links to all pages, and links to any items that the reader
has chosen not to have read. For example, the reader may have turned off the
automatic reading of footnotes. To allow the user to retrieve that information
quickly, the reference to the footnote is placed in the NCC and the reader can
go to the reference, understand the context for the footnote, and then read the
footnote.

Once the reader is at a desired location and wishes to begin reading, the
navigation process changes. Of course, the reader may elect to read
sequentially, but often some navigation is required (e.g., frequently people
navigate forward or backward one word or character at a time). Moving from one
sentence or paragraph at a time is also needed. This type of local navigation
is different from the global navigation used to get to the location of what you
want to read. It is frequently desirable to move from one block element to the
next. For example, moving from a paragraph to the next block element which may
be a list, blockquote, or sidebar is the normally expected mechanism for local
navigation.

8.1 Make available to the user the author-specified purpose of each
table and the relationships among the table cells and headers. [Priority 1] (Checkpoint 8.1)

For example, provide information about table headers, how headers relate to
cells, table summary information, cell position information, table dimensions,
etc. Graphical user agents may satisfy this checkpoint by rendering a table as
a two dimensional grid and by ensuring that users can find headers associated
with cells. Refer also to
checkpoint 5.3. Note: This checkpoint is an important
special case of checkpoint
2.1.

Techniques:

In HTML, beyond the TR, TH, and TD elements, the table attributes
"summary", "abbr", "headers", "scope", and "axis" provide information about
relationships among cells and headers. For more information, refer to the
section on table techniques.

Allow the user to navigate to a table cell and query the cell for
metadata.

8.2 Indicate to the user whether a link has
been visited. [Priority 2] (Checkpoint
8.2)

Note: Do not use color as the only
distinguishing factor between visited and unvisited links as some users may not
perceive colors and some devices may not render them. This checkpoint is an
important special case of checkpoint
8.6.

This image shows how Opera [OPERA] allows the user to configure link rendering,
including the identification of visited links.

8.3 Indicate to the user whether a link has been marked up to
indicate that following it will involve a fee.
[Priority 2] (Checkpoint 8.3)

Note: This checkpoint is an important
special case of checkpoint 8.6.
The W3C specification "Common Markup for micropayment per-fee-links" [MICROPAYMENT]
describes how authors may mark up micropayment information in an interoperable
manner.

Techniques:

Use standard, accessible interface controls to present information about
fees and to prompt the user to confirm payment.

For a link that has content
focus, allow the user to query the link for fee information (e.g.,
by activating a menu or key stroke).

8.4 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.). [Priority 2] (Checkpoint
8.4)

This checkpoint is meant to allow the user to simplify
the view of content by hiding some content selectively. For example, for each
frame in a frameset, provide a table of contents composed of headings (e.g.,
the H1 - H6 elements in HTML) where each entry in the table of contents links
to the heading in the document. Note: This checkpoint does not
require that the outline view be navigable, but this is recommended (refer to
checkpoint 7.6).

Techniques:

Allow the user to expand or shrink portions of the outline view (configure
detail level) for faster access to important parts of content.

For documents that do not use structure properly, user agents may attempt
to create an outline based on the presentation of elements and heuristics about
what elements may indicate about document structure.

This image shows the table of contents view provided by
Amaya [AMAYA]. This
view is synchronized with the "primary" view so that users may navigate in one
viewport and the focus follows in the other. An entry in the table of contents
with a target icon means that the heading in the document has an associated
anchor.

Another approach would be to use class selectors to identify those elements
to hide or display.

End example.

8.6 To help the user decide whether to follow a link, make available
link information specified by the author and computed by the user agent. [Priority 3] (Checkpoint 8.6)

Information specified by the author includes link
content, link title, whether the link is internal, whether it involves a fee,
and hints on the content type, size, or natural language of the linked
resource. Information computed by the user agent includes whether the user has
already visited the link. Note: User agents are not required
to retrieve the resource designated by a link as part of computing information
about the link.

Techniques:

For a link that has content
focus, allow the user to query the link for information (e.g., by
activating a menu or key stroke).

If colors are used to highlight the current viewport, selection, or content
focus, allow the user to configure these colors. Do not rely on color
alone.

Provide a setting that causes a window that is the current viewport to pop
to the foreground.

Provide a setting that causes a window that is the current viewport to be
maximized automatically. For example, maximize the parent window of the browser
when launched, and maximize each child window automatically when it receives focus. Maximizing does not necessarily mean occupying
the whole screen or parent window; it means expanding the current window so
that users have to scroll horizontally or vertically as little as
possible.

If the current viewport is a frame or the user does not want windows to pop
to the foreground, use colors, reverse videos, or other graphical clues to
indicate the current viewport.

For speech or Braille output, use the frame or window title to identify the
current viewport. Announce changes in the current viewport.

Use operating system conventions, for specifying selection and content
focus (e.g., schemes in Windows).

For example, if users navigating links move to a portion
of the document outside the viewport, the viewport should scroll to include the
new location of the focus.

Techniques:

There are times when the content focus changes (e.g., link navigation) and
the viewport must be moved to track it. There are other times when the viewport
changes position (e.g., scrolling) and the content focus is moved to follow it.
In both cases, the focus (or selection) is in the viewport after the
change.

If a search causes the selection or focus to change, ensure that the found
content is not hidden by the search prompt.

When the content focus changes, register the newly focused element in the
navigation sequence; sequential navigation should start from there.

Unless viewports have been synchronized explicitly, changes to selection or
focus in one viewport should not affect the selection or focus in another
viewport.

9.2 Allow configuration so the user is
prompted to confirm any form submission not caused by explicit activation of a
form submit control. [Priority 2] (Checkpoint
9.2)

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
event occurs.

Techniques:

Allow the user to configure script-based submission (e.g., triggered by an
"onChange" event). For instance, allow these settings:

Do not allow script-based submission.

Allow script-based submission after confirmation from the user.

Allow script-based submission without prompting the user (but not by
default).

A configuration to prompt the user before any form submission would satisfy
this checkpoint.

Users who navigate a document serially may think that the submit button in
a form is the "last" control they need to complete
before submitting the form. Therefore, for forms in which additional controls
follow a submit button, if those controls have not been completed, inform the
user and ask for confirmation (or completion) before submission.

pwWebSpeak
[PWWEBSPEAK] generates an explicit form submit button when the author has
not provided one.

For example, allow the user to choose to be notified (or
not) that a script has been executed, that a new
viewport has been opened, that a pulldown menu has been opened, that
a new frame has received focus, etc.

Allow the user to specify an element type for which notification should be
disabled (e.g., TABLE, BODY, and IMG in HTML).

Allow the user to disable notification of changes to CSS properties.

Allow the user to disable notification of images that are changed (e.g.,
animations composed of a sequence of images).

9.4 When transferring content (e.g., a document, image, audio, video, etc.)
indicate what proportion of the content has been transferred and whether the
transfer has stalled. [Priority 3] (Checkpoint
9.4)

Techniques:

Indicate progress of loading and when loading has finished, for example
with a percentage indication. For images that render gradually (coarsely to
finely), it is not necessary to show percentages for each rendering pass.

Provide status information in a device-independent manner. For instance,
proportional scroll bars on graphical viewports
do not benefit users who cannot make use of the graphical information.
Complement this mechanism, for example, with text in the status bar (or in the
scroll mechanism itself) indicating the percentage viewed.

Provide this information automatically and allow users to query the
viewport for it (e.g., through a menu or keyboard shortcut).

Allow users to configure when to render status information so that
assistive technologies may announce changes in status at appropriate times. For
instance, allow the user to hide the status bar in order to hide a text
rendering.

Number of elements of a particular type (e.g., tables, forms, and
headings);

Whether the viewport is at the beginning or end of the document;

Size of document in bytes;

The number of controls in a form and controls in a form control group
(e.g., FIELDSET in HTML).

9.5 Indicate the relative position of the viewport in
rendered content (e.g., the percentage of an audio or video clip
that has been played, the percentage of a Web page that has been viewed, etc.).
[Priority 3] (Checkpoint
9.5)

Note: The user agent may calculate the
percentage according to content focus position, selection position, or viewport
position, depending on how the user has been browsing.

Indicate the size of the document, so that users may decide whether to
download for offline viewing. For example, the playing time of an audio file
could be stated in terms of hours, minutes, and seconds. The size of a
primarily text-based Web page might be stated in both kilobytes and screens,
where a screen of information is calculated based on the current dimensions of
the viewport.

Indicate the number of screens of information, based on the current
dimensions of the viewport (e.g., "screen 4 of 10").

Use a variable pitch audio signal to indicate the viewport's different
positions.

Provide standard markers for specific percentages through the
document.

Provide markers for positions relative to some position – a user
selected point, the bottom, the H1, etc.

Put a marker on the scrollbar, or a highlight at the bottom of the page
while scrolling (so you can see what was the bottom before you started
scrolling.

In particular, default configurations should not
interfere with operating conventions for keyboard accessibility. Information
about operating system accessibility conventions is available in the Techniques
document
[UAAG10-TECHS]. Refer also to
checkpoint 5.8.

Techniques:

The default configuration should not include
"Alt-F4",
"Control-Alt-Delete", or other combinations
that have reserved meanings on a given operating system.

Clearly document any default configurations that depart from system
conventions.

For voice-activated browsers, allow the user to modify
which voice commands activate functionalities. Similarly, allow the user to
modify the graphical user agent user
interface for quick access to commonly used functionalities (e.g.,
through buttons). Refer also to checkpoint 10.5 and checkpoint 10.9.

Techniques:

Allow users to restore easily the default input configuration.

When using a physical keyboard, some users require single-key access (refer
to checkpoint 10.5), others
require that keys activated in combination be physically close together, while
others require that they be spaced physically far apart.

Allow users to select from among pre-packaged configurations, to override
some of the chosen configuration, and to save it as a
profile. Not only will the user save time configuring the user
agent, but this will reduce questions to technical support personnel.

Do not allow the user to override important user agent or operating system
configurations (e.g., to quit the user agent or reconfigure it). Refer to input configuration techniques.

Allow users to create macros and bind them to key strokes or other input
methods.

10.5 Allow the user to configure the user agent so that the
user's preferred one-step operations may be activated with a single input
command (e.g., key stroke, voice command, etc.).
[Priority 2] (Checkpoint
10.5)

Note: User agents are not required to provide single
command activation of all user agent functionalities at once, only some of
them. Furthermore, in some modes of interaction (e.g., when the user is
entering text), the number of single commands available will be significantly
reduced. This checkpoint is an important special case of checkpoint 10.4.

Opera [OPERA]
includes a mode in which users can access important user agent functionalities
with single strokes from the numeric keypad.

Mouse Keys (available on some operating systems)
allow users to simulate the mouse through the keyboard. They provide a usable
command structure without interfering with the user interface for users who do
not require keyboard-only and single-key access.

For example, on some operating systems, developers may specify which
command sequence will activate a functionality so that the standard user
interface components display that binding. For example, if a functionality is
available from a menu, the letter of the activating key will be underlined in
the menu. Note: This checkpoint is an important special case
of checkpoint 5.8.

Techniques:

Use system conventions to indicate the current configuration (e.g., in
menus, indicate what key strokes will activate the functionality, underline
single keys that will work in conjunction with a trigger key such as
Alt, etc.) These are conventions used by the Sun Java Foundations Classes
[JAVA-TUT] and
Microsoft Foundations Classes for Windows.

Ensure that information about changes to the input configuration is
available in a device-independent manner (e.g., through visual and audio cues,
and through text).

If the currently active configuration changes locally (e.g., a search
prompt opens, changing the keyboard mapping for the duration of the prompt),
alert the user.

Named configurations are easier to remember. This is especially important
for people with certain types of cognitive disabilities. For example, if the
invocation of a search prompt changes the input configuration, the user may
remember more easily which key strokes are active in search mode if alerted
that there is a "Search Mode". Context-sensitive help (if available) should
reflect the change in mode, and a list of keybindings for the current mode
should be readily available to the user.

10.7 For the configuration requirements of this document, allow the
user to save user preferences in a profile. [Priority 2] (Checkpoint 10.7)

Note: This includes user preferences
for styles, presentation rates, input configurations, navigation, viewports, and
notification. Users must be able to select from among available profiles or no
profile (i.e., the user agent default settings).

For people using one hand, a few fingers, or a headwand pointer, access to
important functionalities must be available through one or at most two key
strokes.

Consider distance between keys and key alignment (e.g., "9/I/K", which
align almost vertically on many keyboards) in the default configuration. For
instance, if Enter is used to active links, put other link
navigation commands near it (e.g., page up/down, arrow keys, etc. on many
keyboards). In configurations for users with reduced mobility, pair related
functionalities on the keyboard (e.g., left and right arrows for forward and
back navigation).

Allow users to accomplish tasks through repeated key strokes (e.g.,
sequential navigation) since this means less physical repositioning for all
users. However, repeated key strokes may not be efficient for some tasks. For
instance, do not require the user to position the pointing device by pressing
the "down arrow" key repeatedly.

So that users do not mistakenly activate certain functionalities, make
certain combinations "more difficult" to invoke (e.g., users are not likely to
press Control-Alt-Delete accidentally).

Avoid deeply nested graphical menus.

Input configurations should allow quick and direct navigation that does not
rely on graphical output. Do not
require the user to navigate through a graphical user interface as the only way
to activate a functionality.

Offer a mode that makes the input configuration compatible with other
versions of the software (or with other software).

For instance, allow users to configure which of available controls appear
on a graphical tool bar. Note: This checkpoint is an important
special case of checkpoint
10.4.

Techniques:

Allow multiple icon sizes (big, small, other sizes).

Allow the user to choose icons and/or text.

Allow the user to change the grouping of icons.

Allow the user to show and hide controls. This benefits users with
cognitive disabilities and users who navigate user interface controls
sequentially.

Allow the user to change the position of control bars, icons, etc. Do not
rely solely on drag-and-drop for reordering tool bar. Allow the user to
configure the user agent user
interface in a device-independent manner (e.g., through a text-based
profile).

User agents may provide documentation in many formats,
but at least one must conform to the Web Content Accessibility Guidelines 1.0
[WCAG10].

Techniques:

Distribute accessible documentation over the Web, on CD-ROM, or by
telephone. Alternative hardcopy formats may also benefit some users.

Documentation includes information bundled with a product when it is
released as well as information made available subsequently (e.g., bug fixes,
etc.).

Web-based support and/or documentation that is produced or maintained by
the manufacturer of a user agent or by a sub-contractor of the user agent's
developer must conform to the Web Content Accessibility Guidelines 1.0 [WCAG10]. In particular:

Provide a text equivalent for audio
user agent tutorials. Tutorials that use speech to guide a user through the
operation of the user agent should also be available at the same time as graphical representations.

Use clear and consistent navigation and search mechanisms;

Use the NOFRAMES element when the support/documentation is presented in a
FRAMESET;

Describe the user interface with device-independent terms. For example, use
"select" instead of "click on".

Provide documentation in small chunks (for rapid downloads) and also as a
single source (for easy download and/or printing). A single source might be a
single HTML file or a compressed archive of several
HTML documents and included images.

Ensure that run-time help and any Web-based help or support information is
accessible and may be operated with a single, well-documented, input command
(e.g., key stroke). Use operating system conventions for input configurations
related to run-time help.

Provide documentation in alternative formats such as Braille (refer to
"Braille Formats: Principles of Print to Braille Transcription 1997"
[BRAILLEFORMATS]), large print, or audio tape. Agencies such as Recording
for the Blind and Dyslexic
[RFBD] and the National Braille Press [NBP] can create alternative formats.

Provide accessible documentation for all audiences: end users, developers,
etc. For instance, developers with disabilities may wish to add accessibility
features to the user agent, and so require information on available APIs and other
implementation details.

Ensure that product identification codes are accessible to users so they
may install their software. Codes printed on product cases will not be
accessible to people with visual disabilities.

Provide a sensible index to accessibility features. For instance, users
should be able to find "How to turn off blinking text" in the documentation
(and the user interface). The user agent may implement this feature by turning
off scripts, but users should not have to guess (or know) that turning off
scripts will turn off blinking text.

Document configurable features in addition to defaults for those
features.

Document the features implemented to conform with these guidelines.

Include references to accessibility features in both the table of contents
and index of the documentation.

The following table shows how one might document keyboard bindings. It shows
the default keyboard configuration for versions of Netscape Navigator [NAVIGATOR] running on
the Macintosh, Unix, and Windows operating systems. If a function exists in the
browser but does not have a shortcut, its corresponding cell is marked with an
asterisk. If the function does not exist, it is left blank.
Note: This table lists some, but not all, functionalities and keyboard
shortcuts of Navigator. It is meant to illustrate, not serve as definitive
documentation for Netscape Navigator.

Some entries contain links to special notes. The number in parentheses
following the link is the number of the relevant note.

In Windows, this works for any button,
since any button can gain the user interface
focus using keyboard commands. In Unix and Macintosh, this only
applies to the "Submit" button following a text entry.

In Unix, the menus cannot be opened with
shortcut keys. However, once a menu is opened it stays opened until it is
explicitly closed, which means that the menus can still be used with shortcut
keys to some extent. Sometimes left and right arrows move between menus and up
and down arrows move within menus, but this does not seem to work consistently,
even within a single session.

In Macintosh, you cannot explicitly view
the bookmarks menu. However, if you choose "Edit Bookmarks", which does have a
keyboard shortcut, you can then navigate through the bookmarks and open
bookmarked documents in the current window.

To delete a bookmark you must first
choose "Edit Bookmarks" and then move the focus to the
bookmark you want to delete.

In Windows, when you open a link from
the history menu using Enter, the document opens in a new
window.

All three systems have menu items (and
corresponding shortcut keys) meant to allow the user to change the font size.
However, the menu items are consistently inactive in both Macintosh and Unix.
The user seems to be able to actually change the font sizes only in
Windows.

It is important to allow users to set
their own Cascading Style Sheets. Although Navigator does currently allow the
user to override the author's choice of foreground color, background color,
font, and font size, it does not allow some of the advanced capabilities that
make CSS so powerful. For example, a blind user may want to
save a series of style sheets which show only headings, only links, etc., and
then view the same page using some or all of these style sheets in order to
orient himself to the organization of the page before reading the page.

Integrate information about accessibility features throughout the
documentation. The dedicated section on accessibility should provide access to
the documentation as a whole rather than standing alone as an independent
section. For instance, in a hypertext-based help system, the section on
accessibility may link to pertinent topics elsewhere in the documentation.

User agents must ensure that users have access to
content, either
rendered through the user interface or made available to assistive
technologies through an
API. While providing serial access to a stream of content would
satisfy this requirement, this would be analogous to offering recorded music on
a cassette: other technologies exist (e.g., CD-ROMs) that allow direct access
to music. It is just as important for user agents to allow users to access Web
content efficiently, whether the content is being rendered as a two-dimensional
graphical layout, an audio stream, or a
line-by-line Braille stream. Providing efficient access to content
involves:

Preserving structure when rendering

Allowing the user to select specific content and query its structure or
context

When used properly, markup languages structure content in ways that allow
user agents to communicate that structure across different renderings. A table
describes relationships among cells and headers. Graphically, user agents
generally render tables as a two-dimensional grid. However, serial renderings
(e.g., speech and Braille) must also make those relationships apparent,
otherwise users will not understand the purpose of the table and the
relationships among its cells (refer to the section on table techniques). User agents must render content in
ways that allow users to understand the underlying document structure, which
may consist of headings, lists, tables, synchronized multimedia, link
relationships, etc. Providing alternative renderings (e.g., an outline view)
will also help users understand document structure.

Note: Even though the structure of a language like HTML is
defined by a Document Type Definition (DTD), user agents may
convey structure according to a "more intelligent" document model when that
model is well-known. For instance, in the HTML DTD, heading
elements (H1 - H6) do not nest, but presenting the document as nested headings
may convey the document's structure more effectively than as a flat list of
headers.

The guidelines emphasize the importance of navigation as a way to provide
efficient access to content. Navigation allows users to access content more
quickly and when used in conjunction with
selection and focus mechanisms, allows users
to query content for metadata. For instance, blind users often navigate a
document by skipping from link to link, deciding whether to follow each link
based on metadata about the link. User agents can help them decide whether to
follow a link by allowing them to query each focused link for the link text,
title information, information about whether the link has been visited, whether
the link involves a fee, etc. While much of this information may be rendered,
the information must also be available to assistive technologies.

For example, the Amaya browser/editor [AMAYA] makes available all
attributes and their values to the user through a context menu. The
user selects an element (e.g., with the mouse)
and opens an attribute menu that shows which attributes are available for the
element and which are set. The user may read or write values to attributes
(since Amaya is an editor). Information about attributes is also available
through Amaya's structured view, which renders the document tree as structured
text.

The selection may be widened (moved to the nearest node one level up the
document tree) by pressing the Escape key; this is a form of
structured navigation based on the underlying document
object model.

Users may want to select content based on structure alone (as offered by
Amaya) but also based on how the content has been rendered. For instance, most
user agents allow users to select ranges of text content that may cross
"element boundaries".

Authors provide equivalent
alternatives to content so that users may understand the function of
a page or part of a page even though they may not be able to make use of a
particular content type. For example, authors must provide text equivalents for
non-text content (e.g., images, video, auditory presentations, etc.) because text may be
rendered as speech or Braille and may be used by users with visual or hearing
or both disabilities. User agents must ensure that these alternatives are
available to users, either through the user interface or through an API.

How authors specify equivalent
alternatives depends on the markup language used. For information
about equivalent alternatives for SMIL [SMIL] content, refer to "Accessibility Features of SMIL"
[SMIL-ACCESS]. In HTML 4.01 [HTML4], authors specify equivalent alternatives
for content as follows:

Do not render the long description, but allow the user to query whether an
element has an associated long description (e.g., with a context-sensitive
menu) and provide access to it.

Use an icon (with a text equivalent) to indicate the presence of a long
description.

Use an audio cue to indicate the presence of a long description when the
user navigates to the element.

For an object (e.g., an image) with an author-specified geometry that the
user agent does not render, allow the user to configure how the equivalent
alternative should be rendered. For example, within the specified geometry, by
ignoring the specified geometry altogether, etc.

For multimedia presentations with several alternative tracks, ensure access
to all tracks and allow the user to select individual tracks. The Quicktime
player
[QUICKTIME] allows users to turn on and off any number of tracks
separately.

For multimedia presentations with several alternative tracks, allow users
to select tracks based on natural
language preferences. SMIL 1.0 [SMIL] allows users to specify
captions in different natural languages. By setting language
preferences in the SMIL player (e.g., the G2 player [G2]), users may access captions (or audio) in
different languages. Allow users to specify different languages for different
content types (e.g., English audio and Spanish captions).

Authors and user agents provide context to users through content, structure,
navigation mechanisms, and query mechanisms. Titles, dimensions, dates,
relationships, the number of elements, and other metadata all help orient the
user, particularly when available as text. For instance, user agents can help
orient users by allowing them to request that document headings and lists be
numbered. Refer also to the section on table
techniques, which explains how users agents can offer table navigation and
the ability to query a table cell for information about the cell's row and
column position, associated header information, etc.

For information about elements and attributes that convey metadata in HTML,
refer to the index of elements and attributes in "Techniques for Web Content
Accessibility Guidelines 1.0" [WCAG10-TECHS].

For information about elements and attributes that convey metadata in SMIL,
refer to the index of attributes in the W3C Note "Accessibility Features of
SMIL"
[SMIL-ACCESS].

Describe a selected element's position within larger structures (e.g.,
numerical or relative position in a document, table, list, etc.). For example:
tenth link of fifty links; document heading 3.4; list one of two, item 4.5;
third table, three rows and four columns; current cell in third row, fourth
column; etc. Allow users to get this information on demand (e.g., through a
keyboard shortcut). Provide this information on the status line on demand from
the user.

To ensure accessibility, users must be able to configure the style of rendered content and the user
interface. Author-specified styles, while important, may make content
inaccessible to some users. User agents must allow users to increase the size
of text (e.g., with a zoom mechanism or font size control), to change colors
and color combinations, to slow down multimedia presentations, etc.

To give authors design flexibility and allow users to control important
aspects of content style, user agents should implement CSS ([CSS1], [CSS2]) and allow users to create and apply user style sheets. CSS includes mechanisms for
tailoring rendering for a particular output medium, including audio, Braille,
screen, and print.

CSS-enabled user agents should consider as part of the cascade the markup
used for style, giving it a lower weight than actual style sheets. This allows
authors to specify style through markup for older user agents and to use more
powerful style sheets for CSS-enabled user agents. Refer to the section on the
precedence of non-CSS presentational hints in CSS 2 ([CSS2], section 6.4.4).

To hide the CSS syntax from the user, user agents may implement user style
sheets through the user agent user
interface. User agents can generate a user style sheet from user
preferences or behave as though it did. Amaya [AMAYA] provides a GUI-based interface to create and apply internal style
sheets. The same technique may be used to control a user style sheet.

For animations rendered natively, allow users to control the rate of
animation, to pause and play animations, to step through the animation, and to
play it at the specified rate.

Allow the user to pause a video presentation, to move, resize, and position
tracks that appear on the screen (including captions, subtitles and signed
translations) and to apply CSS stylesheets to text-based presentation.

In the user interface:

Allow the user to select large or small buttons and controls. Ensure that
these values are applied consistently across the user interface.

Allow the user to regroup buttons and controls, and reorder menus.

Use standard operating system controls for allowing configuration of font
sizes, speech rates, and other style parameters.

Provide a link view that lists all links in the document. Allow the user to
configure how the links are sorted (e.g., by document order, sequential
navigation order, alphabetical order, visited or unvisited or both, internal or
external or both, etc.).

Help the user remember links by including metadata in the link view. For
example, identify a selected link as "Link X of Y", where "Y" is the total
number of links. Lynx
[LYNX] numbers each link and provides information about the relative
position in the document. Position is relative to the current page and the
number of the current page out of all pages. Each page usually has 24
lines.

Allow the user to configure how much information about a link to present in
the content view (when a link receives focus). For
instance, allow the user to choose between "Display links using hyperlink text"
or "Display links by title (if present)", with an option to toggle between the
two views. For a link without a title, use the link text.

For links with non-text content such as images, make available a text equivalent as follows:

If the author has specified a non-empty text equivalent for the image
(e.g., "alt" in HTML), use that as the link text;

Otherwise, use the link title if available;

Otherwise, use title information of the designated resource (e.g., the
TITLE element of HTML for links to HTML documents).

Otherwise, render part of the filename or URI of the designated
resource.

Otherwise, insert a generic placeholder (e.g., [LINK]) in place of the
image.

For an image in link content, ensure that the user has access to the link
and any long description associated with the
image.

Ensure that all information about a link is available in a
device-independent manner. For example, do not rely solely on fonts or colors
to alert the user whether or not the link has previously been followed. Allow
the user to configure how information will be presented (colors, sounds, status
bar messages, some combination, etc.).

If the user activates a broken link, leave the viewport where it is and
alert the user (e.g., in the status bar and with a
graphical or audio alert). Moving the viewport suggests that a link
is not broken, which may disorient the user.

User agents can make lists accessible by ensuring that list structure
– and in particular, embedded list structure – is available through
navigation and rendering.

Allow users to turn on "contextual" rendering of lists (even for unordered
"bullet" lists). Use compound numbers (or letters, numbers, etc.) to introduce
each list item (e.g., "1, 1.1, 1.2, 1.2.1, 1.3, 2, 2.1"). This provides more
context and does not rely on the information conveyed by a graphical rendering,
as in:

The following CSS 2 style sheet (taken from CSS 2,
section 12.5) shows how to specify compound numbers for nested lists
created with either UL or OL elements. Items are numbered as "1", "1.1",
"1.1.1", etc.

The HTML TABLE element was designed represent
relationships among data ("data" tables). Even when authored well and used
according to specification, tables may pose problems for users with
disabilities for a number of reasons:

Users who access a table serially (e.g., as speech or Braille) may have
difficulty grasping the relationships among cells, especially for large and
complex tables.

Users who with cognitive disabilities may have trouble grasping or
remembering relationships between cells and headers, especially for large and
complex tables.

Users of screen magnifiers or with physical disabilities may have
difficulties navigating to the desired cells of a table.

For these situations, user agents may assist these users by providing table
navigation mechanisms and supplying context that is present in a
two-dimensional rendering (e.g., the cells surrounding a given cell).

To complicate matters, many authors use tables to lay out Web content
("layout" tables). Not only are table structures used to lay out objects on the
screen, table elements such as TH (table header) in HTML are used to font
styling rather than to indicate a true table header. These practices make it
difficult for assistive technologies to rely on markup to convey document
structure. Consequently, assistive technologies often must resort to
interpreting the rendered
content, even though the rendered content has "lost" information
encoded in the markup. For instance, when an assistive technology "reads" a
table from its graphical rendering, the contents of multiline cells may become
intermingled. For example, consider the following table:

This is the top left cell This is the top right cell
of the table. of the table.
This is the bottom left This is the bottom right
cell of the table. cell of the table.

Screen readers that read rendered content line by line would read the table
cells incorrectly as "This is the top left cell This is the top right cell". So
that assistive technologies are not required to gather incomplete information
from renderings, these guidelines require that user agents provide access to
document source through an
API (refer to
checkpoint 5.3).

The following sections discuss techniques for providing improved access to
tables.

Users of screen readers or other serial access devices cannot gather
information "at a glance" about a two-dimensional table. User agents can make
tables more accessible by providing the user with table metadata such as the
following:

The table caption (the CAPTION element in HTML) or summary information (the
"summary" attribute in HTML).

The number of column groups and columns. Note that the number of columns
may change according to the row. Also, some parts of a table may have two
dimensions, others three, others four, etc. Project dimensionality higher than
two onto two when rendering information.

The number of row groups and rows, in particular information about table
headers and footers.

Which rows contain header information (whether at the top or bottom of the
table).

Which columns contain header information (whether at the left or right of
the table).

Whether there are subheads.

How many rows or columns a header spans.

When navigating, quick access to table metadata will allow users to decide
whether to navigate within the table or skip over it. Other techniques:

Allow users to query table summary information from inside a cell.

Allow the user to choose different levels of detail for the summary (e.g.,
brief table summary and a more detailed summary).

Allow the user to configure navigation so that table metadata is not
(re-)rendered each time the user enters the table.

A linear rendering of tables -- cells presented one at a time, row by row or
column by column -- may be useful, but generally only for simple tables. For
more complex tables, user agents need to convey more information about
relationships among cells and their headers.

Provide access to one row at a time, beginning with any column header. If a
header is associated with more than one row, offer that header for each row
concerned.

Render cells with their associated headers. Allow the user to configure how
often headers are rendered (e.g., by implementing the 'speak-header'
property in CSS 2
[CSS2], section 17.7.1). Note also that
the "abbr" attribute in HTML 4.01 specifies abbreviated
headers for speech and other rendering ([HTML4], section 11.2.6). Refer also to information about
cell headers later in this section.

The most important aspect of rendering a table cell is that the cell's
contents be rendered faithfully and be identifiable as the contents of a single
cell. However, user agents may provide additional information to help orient
the user:

Render the row and column position of the cell in the table.

Indicate how many rows and columns a cell spans.

Since the contents of a cell in a data table may only be comprehensible in
context (i.e., with associated header information, row/column position,
neighboring cell information etc.), allow users to navigate to cells and query
them for this information.

Properly constructed data tables distinguish header cells from data cells.
How headers are associated with table cells depends on the markup language. The
following algorithm is based on the
HTML 4.01 algorithm to calculate header information ([HTML4], section 11.4.3). For the sake of
brevity, it assumes a left-to-right ordering, but will work for right-to-left
tables as well (refer to the
"dir" attribute of HTML 4.01 [HTML4], section 8.2). For a given cell:

Search left from the cell's position to find row header (TH) cells. Then
search upwards from the cell's position to find column header cells. The search
in a given direction stops when the edge of the table is reached or when a data
cell is found after a header cell. If no headers are found in either direction
(left or up), search in the other directions (right or down).

Allow the user to configure where the header text comes from. For example,
in HTML 4, either the header cell's text content or the value of the
"abbr" attribute value ([HTML4], section 11.2.6).

Insert row headers into the list in the (left-to-right) order they appear
in the table. Include values implicitly resulting from header cells in prior
rows with rowspan="R", sufficient to extend into the current
row.

Insert column headers after row headers, in the (top-to-bottom) order they
appear in the table. Include values implicitly resulting from header cells in
other columns with colspan="C", sufficient to extend into the
current column containing the TD cell.

If a header cell has a value for the "headers" attribute, then insert it
into the list and stop the search for the current direction.

Treat cells with a value for the "axis" attribute as header cells.

Be sure to take into account header cells that span several rows or
columns.

Not all data tables include proper header markup, which the user agent may
be able to detect. Some repair strategies for finding header information
include the following:

Consider that the top or bottom row contains header information.

Consider that the leftmost or rightmost column in a column group contains
header information.

If cells in an edge row or column span more than one row or column,
consider the following row or column to contain header information as
well.

When trying to guess table structure, present several solutions to the
user.

Other repair issues to consider:

TH cells on both the left and right of the table need to be
considered.

For TH cells with "rowspan" set: the content of those TH cells must be
considered for each of the N-1 rows below the one containing that TH
content.

An internal TH surrounded by TDs makes it difficult to know whether the
header applies to cells to its left or right in the same row (or in both
directions) or cells above or below it in the same column (or in both
directions).

Finding column header cells assumes they are all above the TD cell to which
they apply.

A TH with "colspan" set needs to be included in the list of THs for the N-1
columns to its right.

To permit efficient access to tables, user agents should allow users to
navigate to tables and within tables, to select individual cells, and to query
them for information about the cell and the table as a whole.

Allow users to navigate to a table, down to one of its cells, and back up
to the table level. This should work recursively for nested tables.

Allow users to navigate to a cell by its row and column position.

Allow users to navigate to all cells under a given header.

Allow users to navigate row by row or column by column.

Allow users to navigate to the cells around the current cell.

Allow users to navigate to the first or last cell of a row, column, or the
table.

Allow users to navigate from a cell directly to its related headers (if
it's possible to navigate to the headers).

Allow the user to search for text content within a table (i.e., without
searching outside of the table). Allow the user to search for text content
within specific rows or columns, row groups or column groups, or limited by
associated headers.

Notify the user when the navigation reaches a table edge and when a cell
contains another table.

One way to make an image map accessible is to render the links it contains
as text links. This allows assistive technologies to render the links a speech
or Braille, and benefits users with slow access to the Web and users of small
Web devices that do not support images but can support hypertext. User agents
may allow users to toggle back and forth between a graphical mode for image
maps and a text mode.

Allow users to suppress, shrink, and expand text versions of image maps so
that they may quickly navigate to an image map (which may be, for example, a
navigation tool bar) and decide whether to "expand" it and follow the links of
the map. The metadata listed above will allow users to decide whether to expand
the map. Ensure that the user can expand and shrink the map and navigate its
links using the keyboard and other input devices.

Frames were originally designed so that authors could divide up graphic real
estate and allow the pieces to change independently (e.g., selecting an entry
in a table of contents in one frame changes the contents of a second frame).
While frames are not inherently inaccessible, they raise some accessibility
issues:

Alternatives to frame content. Some users cannot make use of frames because
they cannot grasp the (spatial or logical) relationships conveyed by frame
layout. Others cannot use them because their user agents or assistive
technology does not support them or makes access difficult (e.g., users with
screen readers or screen magnifiers).

Navigation. Users must be able to navigate from frame to frame in a device
independent manner.

Orientation. Users need to know what frame they are in (thus, frames must
be titled), what other frames are available, and how the frames of a frameset
are organized.

Dynamic changes. Users need to know how the changes they cause in one frame
affect other frames.

To name a frame in HTML, use the following algorithm:

Use the "title" attribute on FRAME, or if not present,

Use the "name" attribute on FRAME, or if not present,

Use title information of the referenced frame source (e.g., the TITLE
element of the source HTML document), or

Use title information of the referenced long description (e.g., what
"longdesc" refers to in HTML), or

Use frame context (e.g., "Frame 2.1.3" to indicate the path to this frame
in nested framesets).

Here is a technique for the case of a frameset that does not contain a
NOFRAMES equivalent but the individual frames have associated long descriptions
("longdesc"):

For each frameset, render the frameset title as an H1 heading.

For each frame, render the frame title in an H2 heading, followed by the
content of the associated long description.

Create a navigable table of contents according to the (possibly nested)
frameset structure. Each entry in the table of contents should link to a
frameset or frame. The end of the content used for each frame should include a
link back to this table of contents.

Notify the user when the viewport contains a frameset.

Render a frameset as a list of links to named frames so the user can
identify the number of frames. The list of links may be nested if framesets are
nested.

Provide information about the number of frames in the frameset.

Highlight the current frameset (e.g., with a thick border, by displaying
the name of the current frameset in the status bar, etc.)

Allow the user to query the current frame for metadata about the frame.
Make available the frame title for speech synthesizers and Braille displays.
Users may also use information about the number of images and words in the
frame to guess the purpose of the frame. For example, few images and few words
is probably a title, more words is probably an index, many words is probably
text area.

Allow navigation between frames (forward and backward through the nested
structure, return to global list of links to frames). Note:
Recall that the user must be able to navigate frames through all supported
input devices.

Allow navigation to frame equivalents.

Allow the user to bookmark the current frame.

Notify the user when an action in one frame causes the content of another
frame to change. Allow the user to navigate quickly to the frame(s) that
changed.

Authors can suppress scrolling of frames with scrolling="no".
In this case, the user agent must make available content that is not in the
viewport.

The user agent may ignore some attributes of the
FRAME element of HTML 4.01 ([HTML4], section 16.2.2): "noresize",
"scrolling", and "frameborder".

User agents may also indicate the number of frames in a document and which
frame is the current frame via the menu bar or popup menus. Users can configure
the user agent to include a FRAMES menu item in their menu bar. The menu bar
makes the information highly visible to all users and is very accessible to
assistive technologies.

To make forms accessible, user agents need to ensure that users may interact
with them in a device-independent manner, that users can navigate to the
various form controls, and that information about the form and its controls is
available on demand.

Allow users to navigate to forms and to all controls within a form (refer
also to table navigation techniques). Opera [OPERA] and Navigator [NAVIGATOR]
provide such functionality in a non-interactive manner, a "form navigation"
keyboard commands. When invoked, these "form navigation" commands move the user
agent's current focus to the first
form control (if any) in the document.

If there are no forms in a document and the user attempts to navigate to a
form, alert the user.

Provide a navigable, structured view of form controls (e.g., those grouped
by LEGEND or OPTGROUP in HTML) along with their labels.

For labels explicitly associated with form controls (e.g., "for" attribute
on LABEL in HTML), make available label information when the user navigates
among the form controls.

As the user navigates to a form control, provide information about whether
the control must be activated before form submission.

Allow the user to navigate away from a menu without selecting any option
(e.g., by pressing the Escape key).

As the user navigates to a form control, provide information (e.g., through
context-sensitive help) about how the user can activate the control. Provide
information about what is required for each form control. Lynx [LYNX] conveys this information
by providing information about the currently selected form control via a status
line message:

Radio Button: Use right-arrow or Return to toggle

Checkbox Field: Use right-arrow or Return to toggle

Option List: Press return and use arrow keys and return to select
option

Text Entry Field: Enter Text. Use Up or Down arrows
or Tab to move off

Textarea: Enter text. Up or Down arrows or
Tab to move off (^Ve for editor) Note: The ^Ve (caret-V,
e) command, included in the TEXTAREA status line message, enables the user to
invoke an external editor defined in the local Lynx configuration file
(lynx.cfg).

The percentage of a form that has already been filled out. This will help
users with serial access to form controls know whether they have completed the
form. Otherwise, users who encounter a submit button that is not the last
control of the form might inadvertently submit the incomplete form.

Provide the following information about the controls in a form on demand
(e.g., for the control with focus):

Indicate the number of controls in the form.

Indicate the number of controls that have not yet been completed.

Provide a list of controls that must be activated before form
submission.

Provide information about the order of form controls (e.g., as specified by
"tabindex" in HTML). This is important since:

Most forms are visually oriented, employing changes in font size and
color.

Users who access forms serially need to know they have supplied all the
necessary information before submitting the form.

Provide information about which control has focus (e.g., "control X of Y
for the form named "MyForm"). The form name is very important for documents
that contain more than one form. This will help users with serial access to
form controls know whether they have completed the form.

Allow the user to query a form control for information about title, value,
grouping, type, status, and position.

When a group of radio buttons receives
content focus, identify the radio button with content focus as
"Radio Button X of Y", where "Y" represents the total number of radio buttons
in the group. HTML 4.01 specifies the
FIELDSET element ([HTML4], section 17.10), which allows authors to group thematically
related controls and labels. The
LEGEND element ([HTML4], section 17.10) assigns a caption to a FIELDSET. For
example, the LEGEND element might identify a FIELDSET of radio buttons as
"Connection Rate". Each button could have a
LABEL element ([HTML4], section 17.9.1) stating a rate. When it receives content
focus, identify the radio button as "Connection Rate: Radio button X of Y:
28.8kpbs", where "Y" represents the total number of radio buttons in the
grouping and "28.8kbps" is the information contained in the LABEL.

Allow the user to invoke an external editor instead of editing directly in
a TEXTAREA control. This allows users to use all the features of the external
editor: macros, spell-checkers, validators, known input configurations, backups
and local copies, etc.

Provide an option for transforming menus into checkboxes or radio buttons.
In the transformation, retain the accessibility information specified by the
author for the original form controls. Preserve the labels provided for the
OPTGROUP and each individual OPTION, and re-associate them with the generated
checkboxes. The LABEL defined for the OPTGROUP should be converted into a
LEGEND for the result FIELDSET, and each checkbox should retain the LABEL
defined for the corresponding OPTION. Lynx [LYNX] does this for HTML SELECT elements that have the
"multiple" attribute specified.

Allow the user to request confirmation before any form submission not initiated by the
user. This should be the default setting. Allow the user to suppress
future prompts or to change the setting to "always/never/prompt".

Be aware that users may inadvertently pressing the Return or
Enter key and accidentally submit a form.

To hide content, use the CSS
'display' or
'visibility' properties ([CSS2], sections 9.2.5 and 11.2, respectively). The 'display'
property suppresses rendering of an entire subtree. The 'visibility' property
causes the user agent to generate a rendering structure, but display it
invisibly (which means it takes up space, but cannot be seen).

The following XSLT style sheet (excerpted from the XSLT Recommendation [XSLT], Section 7.7) shows
how to one might number H4 elements in HTML with a
three-part label.

User agents must make dynamic content accessible to users who may be
disoriented by changes in content, who may have a physical disability that
prevents them from interacting with a document within a time interval specified
by the author, or whose user agent does not support scripts or applets. Not
only must user agents make available equivalent alternatives to dynamic content, they must
allow users to turn off scripts, to stop animations, adjust timing parameters,
etc.

Certain elements of a markup language may have associated event handlers
that are triggered when certain events occur. User agents must be able to
identify those elements with event handlers statically associated (i.e.,
associated in the document source, not in a script). In HTML
4.01 ([HTML4], section
18.2.3),
intrinsic events are specified by the attributes beginning with the prefix
"on": "onblur", "onchange", "onclick", "ondblclick", "onkeydown", "onkeypress",
"onkeyup", "onload", "onmousedown", "onmousemove", "onmouseout", "onmouseover",
"onmouseup", "onreset", "onselect", "onsubmit", and "onunload".

Techniques for providing access to scripts include the following:

Allow the user to configure the user agent so that mouseover/mouseout
events may be triggered by (and trigger) focus/blur events. Similarly, allow
the user to use a key command, such as "enter" and "Shift-enter" to
trigger "onclick" and "ondblclick" events.

Implement DOM 2
[DOM2] events with a single activation event and provide a method for
triggering that event from each supported input device or input API. These
should be the same as the click events and mappings provided above (but note
that a user agent which is also an editor may wish to use single click events
for moving a system caret, and want to provide a different behavior to activate
using the mouse). For example, Amaya [AMAYA] uses a "doAction" command for activating links and
form controls, which can be triggered either by the mouse (and it is possible
to set it for single-click or double-click) or by the keyboard (it is possible
to set it for any key using Amaya's keyboard configuration)

Allow the user to stop and start the flow of changes made by scripts.
Prompt the user for confirmation of a pending change. Note:
Some user agents allow users to turn off scripts for security reasons.

Document the effects of known important scripts to give users an idea in
advance of what they do. Make script source available to users so that those
familiar with the scripting language may be able to understand their
effects.

When a user agent loads an applet, it should support the Java system
conventions for loading an assistive technology (refer to the appendix on loading assistive technologies for DOM access).
If the user is accessing the applet through an assistive technology, the
assistive technology should notify the user when the applet receives content focus as this will likely result in the
launch of an associated plug-in or browser-specific Java Virtual Machine. The
user agent then needs to turn control of the applet over to the assistive
technology. User agents must make available equivalent alternatives to the assistive
technology. Applets generally include an application frame that provides title
information.

User agents that allow users to modify default input configurations must
account for configuration information from several sources: user agent
defaults, user preferences, author-specified configurations, and operating
system conventions. In HTML, the author may specify keyboard bindings with the
"accesskey" attribute ([HTML4], section 17.11.2). Users generally specify their preferences
through the user interface but may also do so programmatically or through a profile. The user agent may also consider user
preferences set at the operating system level.

To the user, the most important information is the final configuration once
all sources have been cascaded (combined) and all conflicts resolved. Knowing
the default configuration is also important; checkpoint 11.3 requires that
the default configuration be documented. The user may also want to know how the
current configuration differs from the default configuration and what
configuration in the current viewport comes from the author. This information
may also be useful to technical support personnel who may be assisting
users.

The user interfaces for viewing and editing the input configuration may be
combined, but need not be. When a single interface is available to the user,
allow the user to apply filters to the list of bindings (e.g., author-specified
only, user agent default, user preference, final configuration, etc.).

The user interfaces for viewing and editing the input configuration must be
accessible: do not rely on color alone to convey information, use standard
controls, allow device-independent input and output, etc.

In the user interface, associate with each binding a short text description
of the function to be activated. For example, if "Control-P" maps to
a print functionality, a short description might be "Print" or "Print setup".
For author-specified configurations, use available information (e.g., "title")
or use generic descriptions of what action will be triggered (e.g., "Follow the
link with this link text").

In general, user preferences should override other configurations, however
this may not always be desirable. For example, users should be prevented from
configuring the user agent in a way that would interfere with important
functionalities such as quitting the user agent or reconfiguring it.

Some possible options user agents may make available to the user to resolve
conflicts include:

Allow author configurations to override other configurations and alert the
user when this happens.

Do not allow author configurations to override other configurations. Alert
the user when an author-specified binding has been overridden and provide
access to the author-specified control through other means (e.g., an unused
binding, a menu, in a list of all author-specified bindings, etc.)

Author-specified keyboard bindings in combination with the user agent's
trigger mechanism may conflict with system conventions. For example, Internet
Explorer [IE-WIN] in
Windows uses the Alt key as the trigger key for author-specified
bindings. If the author has specified a configuration with the characters "h"
or "f", this will interfere with the system conventions for accessing help and
the file menu. In addition to the previous two options for handling conflicts,
the user agent may allow the user to choose another trigger key (either
globally or on a per-document basis when conflicts are detected).

Users may want to use a keyboard or voice binding to shift focus without
actually triggering the associated functionality (refer to parallel behavior
described for navigation of active elements in the section on sequential navigation techniques). First-time users may want
to access additional information before deciding whether to activate a control.
More experienced users or those familiar with a page may want to select and
activate in one step. Therefore, the user agent may provide the user with the
following options:

On invocation of the input binding, move focus to the associated active
element, but do not activate it.

On invocation of the input binding, move focus to the associated active
element and prompt the user with information that will allow the user to decide
whether to activate the element (e.g., link title or text). Allow the user to
suppress future prompts for this particular input binding.

On invocation of the input binding, move focus to the associated active
element and activate it.

User agents that provide accessible solutions for images should, by
default, provide no information about images for which the author has
provided no text equivalent, otherwise
information may clutter the user's view of the content and cause confusion. The
user should be able to turn off this option.

User agents may recognize different natural languages and be able
to render content according to language markup defined for a certain part of
the document. For instance, a screen reader might change the pronunciation of
spoken text according to the language definition. This is usually desired and
done according to the capabilities of the tool. Some specialized tools might
give some finer user control for the pronunciation as well.
Note: A user agent may not support all languages.

The following techniques for speaking data tables are adapted from the
"Tape Recording Manual" produced by the National Braille Association [NBA]:

Describe the structure of the table. Include the number of columns, the
headers of each column and any associated sub-columns, reading from left to
right. The subhead is not considered a column. If column heads have footnotes,
read them following each header.

Explain whether the table will be read by rows (horizontally) or by columns
(vertically). The horizontal reading is usual but, in some cases, the vertical
reading better conveys the content. On rare occasions it is necessary to read a
table both ways.

Repeat the column headers with the figures under them for the first two
rows. If the table is long, repeat the headers every fifth row. Always repeat
them during the reading of the last row.

Several mainstream operating systems now include built-in accessibility
features designed to assist individuals with varying abilities. Despite
operating systems differences, the built-in accessibility features use a
similar naming convention and offer similar functionalities, within the limits
imposed by each operating system (or particular hardware platform). The
following is a list of built-in accessibility features from several
platforms:

StickyKeys

StickyKeys allows users who have difficulties with pressing several keys
simultaneously to press and release sequentially each key of the
configuration.

These allow users to move the mouse cursor and activate the mouse button(s)
from the keyboard.

RepeatKeys

RepeatKeys allows users to set how fast a key repeats ("repeat rate") when
the key is held pressed. It also allows users to control how quickly the key
starts to repeat after the key has been pressed ("delay until repeat"). Users
can also turn off key repeating.

SlowKeys

SlowKeys instructs the computer not to accept a key as pressed until it has
been pressed and held down for more than a user-configurable length of
time.

BounceKeys

BounceKeys prevents extra characters from being typed if the user bounces
(e.g., due to a tremor) on the same key when pressing or releasing it.

ToggleKeys

ToggleKeys provides an audible indication for the status of keys that have
a toggled state (keys that maintain status after being released). The most
common toggling keys include Caps Lock, Num Lock, and Scroll Lock.

SoundSentry monitors the operating system and applications for sounds in
order to provide a graphical indication when a
sound is being played. Older versions of SoundSentry may have flashed the
entire display screen for example, while newer versions of SoundSentry provide
the user with a selection of options, such as flashing the active window or
flashing the active window caption bar.

The next three built-in accessibility features are not as commonly available
as the above group of features, but are included here for definition,
completeness, and future compatibility.

ShowSounds

ShowSounds are user settings or software switches that cause audio to be
presented using both audio and graphics. Applications may use these switches as
the basis of user preferences.

HighContrast

HighContrast sets fonts and colors designed to make the screen easier to
read.

TimeOut

TimeOut turns off built-in accessibility features automatically if the
computer remains idle for a user-configurable length of time. This is useful
for computers in public settings such as a library. TimeOut might also be
referred to as "reset" or "automatic reset".

The next accessibility feature listed here is not considered to be a
built-in accessibility feature (since it only provides an alternate input
channel) and is presented here only for definition, completeness, and future
compatibility.

SerialKeys allows a user to perform all keyboard and mouse functions from
an external assistive device (such as communication aid) communicating with the
computer via a serial character stream (e.g., serial port, infra-red port,
etc.) rather than or in conjunction with, the keyboard, mouse, and other
standard input devices/methods.

To find out about built-in accessibility features on Windows platforms, ask
the system via the "SystemParametersInfo" function. Please refer to "Software
accessibility guidelines for Windows applications" [MS-ENABLE] for more information.

The following accessibility features can be adjusted from the Accessibility
Options Control Panel:

StickyKeys: modifier keys include Shift, Control, and
Alt.

FilterKeys: grouping term for SlowKeys, RepeatKeys, and BounceKeys.

MouseKeys

ToggleKeys

SoundSentry

ShowSounds

Automatic reset: term used for TimeOut

High Contrast

SerialKeys

Additional accessibility features available in Windows 98:

Magnifier

Magnifier is a windowed, screen enlargement and enhancement program used by
people with low vision to magnify an area of the
graphical display (e.g., by tracking the text cursor, current focus, etc.). Magnifier can also invert
the colors used by the system within the magnification window.

Accessibility Wizard

The Accessibility Wizard is a setup tool to assist users with the
configuration of system accessibility features.

The following accessibility features can be adjusted from the Easy Access
Control panel. Note: The Apple naming convention for accessibility features is to put spaces between the
terms (e.g., "Sticky Keys" instead of "StickyKeys").

The following accessibility features can be adjusted from the Keyboard
Control Panel.

Key Repeat Rate (part of RepeatKeys)

Delay Unit Repeat (part of RepeatKeys)

The following accessibility feature can be adjusted from the Sound or
Monitors and Sound Control Panel (depending on system version).

Adjusting the volume to off or mute causes the Macintosh to flash the title
bar whenever the operating system detects a sound (e.g., SoundSentry)

Additional accessibility features available for the Macintosh OS:

CloseView

CloseView is a full screen, screen enlargement and enhancement program used
by people with low vision to magnify the information on the graphical display,
and it can also change the colors used by the system.

SerialKeys

SerialKeys is available as freeware from Apple and several other Web
sites.

The following accessibility features can be adjusted from the AccessX
graphical user interface X client on some DEC, SUN, and SGI operating systems.
Other systems supporting XKB may require the user to manipulate the features
via a command line parameter(s).

StickyKeys: modifier keys are platform-dependent, but usually include the
Shift, Control, and Meta keys.

RepeatKeys

SlowKeys

BounceKeys

MouseKeys

ToggleKeys

Note: AccessX became a supported part of the X Window
System X Server with the release of the X Keyboard Extension in version
X11R6.1

The following accessibility features are available from a freeware program
called AccessDOS, which is available from several Internet Web sites including
IBM, Microsoft, and the Trace Center, for either PC-DOS or MS-DOS versions 3.3
or higher.

StickyKeys: modifier keys include the Shift, Control,
and Alt keys.

Keyboard Response Group: grouping term for SlowKeys, RepeatKeys, and
BounceKeys

Many of the checkpoints in the guidelines require a "host" user agent to
communicate information about content and the user interface to assistive
technologies. This appendix explains how developers can ensure the timely
exchange of this information (refer to checkpoint 5.6). The techniques described here include:

The first two techniques are similar, differing in the amount of, or
capability of, the assistive technology loaded in the same process or address
space as the host user agent. These techniques are likely to provide faster
access to the document object model since
they will not be subject to inter-process communication overhead.

First, the host user agent needs to know which assistive technology to load.
One technique for this is to store a reference to an assistive technology in a
system registry file or, in the case of Java, a properties file. Registry files
are common among many operating system platforms:

Windows: use the system registry file

IBM OS/2: use the system.ini

On client/server systems: use a system registry server that an application
running on the network client computer can query.

In Sun Java 2, use the "accessibility.properties" file, which causes the
system event queue to examine the file for assistive technologies required for
loading. If the file contains a property called "assistive_technologies", it
will load all registered assistive technologies and start them on their own
thread in the Java Virtual Machine that is a single process.

Here is an example entry for Java:

assistive_technologies=com.ibm.sns.svk.AccessEngine

In Microsoft Windows, a similar technique could be followed by storing the
name of a Dynamic Link Library (DLL) for an assistive
technology in a designated assistive technology key name/assistive technology
pair.

Once the assistive technology has been registered, any other user agent can
determine whether it needs to be loaded and then load it. Once loaded, the
assistive technology can monitor the document
object model as needed.

On a non-Java platform, a technique to do this would be to create a separate
thread with a reference to the document object model using a
DLL. This new thread will load the DLL and call a
specified DLL entry name with a pointer to the document object model interface.
The assistive technology process will then run as long as required.

The assistive technology has the option to either:

communicate with a main assistive technology of its own and process the
document object model as a caching mechanism for the main assistive technology,
or

act as a bridge to the document object model for the main assistive
technology.

In the future, it will be necessary to provide a more comprehensive
reference to the application that not only provides direct navigation to its
client area document object model, but also multiple document object models
that it is processing and an event model for monitoring them.

Java can facilitate timely access to accessibility components. In this
example, an assistive technology running on a separate thread monitors user
interface events such as focus changes. When focus
changes, the assistive technology is notified of which component object has
focus. The assistive technology can communicate directly with all components in
the application by walking the parent/child hierarchy and connecting to each
component's methods and monitor events directly. In this case, an assistive
technology has direct access to component specific methods as well as those
provided for by the Java Accessibility API. There is no
reason that a document object model interface to user agent components could
not be provided via Java.

In Java 1.1.x, Sun's Java access utilities load an assistive by monitoring
the Java awt.properties file for the presence of assistive
technologies and loads them as shown in the following code example:

In the above code example, the function
Class.forName(atName).newInstance() creates a new instance of the
assistive technology. The constructor for the assistive technology will then be
responsible for monitoring application component objects by monitoring system
events.

In the following code example, the constructor for the assistive technology,
AccessEngine, adds a focus change
listener using Java accessibility utilities. When the assistive technology is
notified of an objects gaining focus, it has direct access to that object. If
the Object, o, has implemented a document object model interface,
the assistive technology will have direct access to the document object model
in the same process space as the application.

In this example, the assistive technology has the option of running
stand-alone or acting as a cache for a bridge that communicates with a main
assistive technology running outside the Java virtual machine.

In order to attach to a running instance of Internet Explorer 4.0, you can
use a Browser Helper Object ([BHO]), which is a DLL that will attach itself to every
new instance of Internet Explorer 4.0 [IE-WIN] (only if you explicitly run iexplore.exe). You
can use this feature to gain access to the object model of Internet Explorer
and to monitor events. This can be tremendously helpful when many method calls
need to be made to IE, as each call will be executed much more quickly than the
out of process case.

There are some requirements when creating a Browser Helper Object:

The application that you create must be an in-proc server (that is,
DLL).

This DLL must implement IObjectWithSite.

The IObjectWithSite::SetSite() method must be implemented. It
is through this method that your application receives a pointer to Internet
Explorer's IUnknown. Internet Explorer actually passes a pointer
to IWebBrowser2 but the implementation of SetSite()
receives a pointer to IUnknown. You can use this
IUnknown pointer to automate Internet Explorer or to sink events from
Internet Explorer.

To provide native Microsoft Windows assistive technologies access to Java
applications without creating a Java native solution, Sun Microsystems provides
the "Java Access Bridge." This bridge is loaded as an assistive technology as
described in the section on loading assistive
technologies for direct navigation of the document object model. The bridge
uses a Java Native Invocation (JNI) to Dynamic Link Library
(DLL) communication and caching mechanism that allows a
native assistive technology to gather and monitor accessibility information in
the Java environment. In this environment, the assistive technology determines
that a Java application or applet is running and communicates with the Java
Access Bridge DLL to process accessibility information about
the application/applet running in the Java Virtual Machine.

Access to application specific data across process boundaries or address
space might be costly in terms of performance. However, there are other reasons
to consider when accessing the document
object model that might lead a developer to wish to access it from
their own process or memory address space. One obvious protection this method
provides is that, if the user agent fails, it does not disable the user's
assistive technology as well. Another consideration would be legacy systems,
where the user relies on their assistive technology for access to software
other than the user agent, and thus would have their application loaded all the
time.

There are several ways to gain access to the user agent's document object model. Most user agents support some
kind of external interface, or act as a mini-server to other applications
running on the desktop. Internet Explorer [IE-WIN] is a good example of this, as IE can behave as a
component object model (COM) server to other applications.
Mozilla [MOZILLA],
the open source release of Navigator also supports cross platform COM
(XPCOM).

The following example illustrates the use of COM to access the IE object
model. This is an example of how to use COM to get a pointer to the
WebBrowser2 module, which in turn enables access to an interface/pointer
to the document object, or IE document object model for the content.

An active element is an element with behaviors that may be
activated (or "triggered") either
through the user interface or through an API (e.g., by using scripts). Which elements are
active depends on the document language and whether the features are supported
by the user agent. In HTML 4.01 [HTML4] documents, for example, active elements
include links, image maps, form controls, element instances with a value for
the "longdesc" attribute, and element instances with scripts (event handlers)
explicitly associated with them (e.g., through the various "on" attributes).
Most systems use the content focus to navigate active elements and identify
which is to be activated. An active element's behavior may be triggered through
any number of mechanisms, including the mouse, keyboard, an API, etc. The effect of activation
depends on the element. For instance, when a link is activated, the user agent
generally retrieves the linked resource. When a form control is activated, it
may change state (e.g., check boxes) or may take user input (e.g., a text
field). Refer also to the definition of event
handler.

In the context of this document, an assistive technology
is a user agent that:

relies on services (such as retrieving resources, parsing markup, etc.)
provided by one or more other "host" user agents. Assistive technologies
communicate data and messages with host user agents by using and monitoring APIs.

provides services beyond those offered by the host user agents to meet the
requirements of a users with disabilities. Additional services include
alternative renderings (e.g., as synthesized speech or magnified content),
alternative input methods (e.g., voice), additional navigation or orientation
mechanisms, content transformations (e.g., to make tables more accessible),
etc.

For example, screen reader software is an assistive technology because it
relies on browsers or other software to enable Web access, particularly for
people with visual and learning disabilities.

Examples of assistive technologies that are important in the context of this
document include the following:

screen magnifiers, which are used by people with visual disabilities to
enlarge and change colors on the screen to improve the visual readability of
text and images.

screen readers, which are used by people who are blind or have reading
disabilities to read textual information through synthesized speech or Braille
displays.

speech recognition software, which may be used by people who have some
physical disabilities.

alternative keyboards, which are used by people with certain physical
disabilities to simulate the keyboard.

alternative pointing devices, which are used by people with certain
physical disabilities to simulate mouse pointing and button activations.

Beyond this document, assistive technologies consist of
software or hardware that has been specifically designed to assist people with
disabilities in carrying out daily activities, e.g., wheelchairs, reading
machines, devices for grasping, text telephones, vibrating pagers, etc.

An auditory presentation is a stand-alone audio track. Examples of audio
presentations include a musical performance, a radio-style news broadcast, and
a book reading. When an auditory presentation includes natural language, one
can create a text equivalent for it (e.g., a text transcript).

An auditory description is either a prerecorded human
voice or a synthesized voice (recorded or generated dynamically) describing the
key visual elements of a movie or animation. The auditory description is
synchronized with the auditory track of the presentation, usually during
natural pauses in the auditory track. Auditory descriptions include information
about actions, body language, graphics, and scene changes.

Captions (or sometimes "closed captions") are text transcripts that are synchronized
with other auditory or visual tracks. Captions convey information about spoken
words and non-spoken sounds such as sound effects. They benefit people who are
deaf or hard-of-hearing, and anyone who cannot hear the audio (e.g., someone in
a noisy environment). Captions are generally rendered
graphically above, below, or superimposed over video.
Note: Other terms that include the word "caption" may have different
meanings in this document. For instance, a "table caption" is a title for the
table, often positioned graphically above or below the table. In this document,
the intended meaning of "caption" will be clear from context.

A collated text transcript is a text equivalent of a movie or animation. More
specifically, it is the combination of the
text transcript of the auditory track and the text equivalent of the
visual track. For example, a collated text transcript typically includes
segments of spoken dialogue interspersed with text descriptions of the key
visual elements of a presentation (actions, body language, graphics, and scene
changes). Refer also to the definitions of
text transcript and auditory description. Collated text transcripts are
essential for individuals who are deaf-blind.

In the context of this document, both the terms "control"
and "configure" share in common the idea of governance such as a user may
exercise over interface layout, user agent behavior, rendering style, and other
parameters required by this document. Generally, the difference in the terms
centers on the idea of persistence. When a user makes a change by
"controlling" a setting, that change usually does not persist beyond that user
session. On the other hand, when a user "configures" a setting, that setting
typically persists into later user sessions. Furthermore, the term "control"
typically means that the change can be made easily (such as through a keyboard
shortcut) and that the results of the change occur immediately, whereas the
term "configure" typically means that making the change requires more time and
effort (such as making the change via a series of menus leading to a dialog
box, via style sheets or scripts, etc.) and that the results of the change may
not take effect immediately (e.g., due to time spent reinitializing the system,
initiating a new session, rebooting the system). Configuration settings may be
stored in a profile. The range and
granularity of the changes that can be controlled or configured by the user may
depend on system or hardware limitations.

The noun "control" may also refer to a "user interface component" or "form
component".

Content refers to the document
object as a whole or in parts. Phrases such as "content type", "text
content", and "language of content" refer to this usage. When used in this
sense, the term content encompasses
equivalent alternatives. Refer also to the definition of rendered content. and other accessibility
information.

Content refers to the content of an HTML or XML element, in the sense
employed by the XML 1.0 specification ([XML], section 3.1): "The text between the start-tag and
end-tag is called the element's content." Context should indicate that the term
content is being used in this sense.

Device-independence refers to the ability to make use of
software with any supported input or output device. User agents should follow
operating system conventions and use standard system APIs for input and output.

The document object is the user agent's representation of data (e.g., a
document). This data generally comes from the document source, but may also be generated (from
style sheets, scripts, transformations, etc.) or produced as a result of
preferences set within the user agent. Some data that is part of the document
object is routinely rendered
(e.g., in HTML, what appears between the start and end tags of elements and the
values of attributes such as "alt", "title", and "summary"). Other parts of the
document object are generally processed invisibly by the user agent, such as
DTD-defined names of
element types and attributes, and other attribute values such as "href", "id",
etc. These guidelines require that users have access to both types of data
through the user interface.

A document object model is the abstraction that governs the construction of
the user agent's document object. The document object model employed by
different user agents will vary in implementation and sometimes in scope.
Nevertheless, this document calls for developers of user agents to adhere the
W3C Document Object Model
(DOM), which specifies a standard interface
for accessing HTML and XML content. This standard interface allows authors to
access and modify the document with a scripting language (e.g., JavaScript) in
a consistent manner across different scripting languages. As a standard
interface, use of a W3C DOM makes it easier not just for authors but for
assistive technology developers to extract information and render it in ways
most suited to the needs of particular users. The relevant W3C DOM
Recommendations are listed in the references. In this
specification, the acronym "DOM" refers to the W3C DOM.

In this document, the term document source refers to the
data that the user agent receives as the direct result of a request for a
resource on the Web. A document source view represents all or part of a
document in a way that exposes the markup language(s) used to build the
resource. A source view often presents textual representations of content.
Refer also to the definition of content.

This document uses the term "element" both in the XML
sense (an element is a syntactic construct as described in the XML 1.0
specification [XML],
section 3) and more generally to mean a type of content (such as video or
sound) or a logical construct (such as a header or list).

Since content in some
forms is not always accessible to users with disabilities, authors must provide
equivalent alternatives for inaccessible content. In the context of this
document, the equivalent must fulfill essentially the same function for the
person with a disability (at least insofar as is feasible, given the nature of
the disability and the state of technology), as the "primary" content does for
the person without any disability. For example, the text "The Full Moon" might
convey the same information as an image of a full moon when presented to users.
Note that equivalent information focuses on fulfilling the same function. If
the image is part of a link and understanding the image is crucial to guessing
the link target, an equivalent must also give users an idea of the link
target.

Equivalent alternatives of content include text equivalents (long and short,
synchronized and unsynchronized) and non-text equivalents (e.g., an auditory description, or a
visual track that shows a sign language translation of a written text, etc.).
Please also consult the Web Content Accessibility Guidelines 1.0 [WCAG10] and its associated
Techniques document [WCAG10-TECHS].

Each markup language defines its own mechanisms for
specifying equivalent alternatives. For instance, in HTML 4.01 [HTML4] or SMIL 1.0 [SMIL], the "alt" attribute
specifies alternative text for many elements. In HTML 4.01, authors may provide
alternatives in attribute values (e.g., the "summary" attribute for the TABLE
element), in element content (e.g., OBJECT for external content it specifies,
NOFRAMES for frame alternatives, and NOSCRIPT for script alternatives), and in
prose.

User agents often perform a task when a certain event
occurs, caused by user interaction (e.g., mouse motion or a key press), a
request from the operating system, etc. Some markup languages allow authors to
specify that a script, called an event
handler, be executed when a specific event occurs, such as
document loading and unloading, mouse press or hover events, keyboard events,
and other user interface events. Note: The combination of
HTML, style sheets, the Document Object Model (DOM), and
scripting is commonly referred to as "Dynamic HTML" or DHTML. However, as there
is no W3C specification that formally defines DHTML, this document only refers
to event handlers and scripts.

The notion of focus refers to two identifying mechanisms
of user agents:

The "content focus" designates an
active element in a document. A viewport has at most one content
focus.

The "user interface focus" designates a control of the user interface that
will respond to user input (e.g., a radio button, text box, menu, etc.).

The term "focus" encompasses both types of focus. Where one is meant
specifically in this document, it is identified.

When several viewports coexist, each may have a content
and user interface focus. At all times, only one content focus
or one user interface focus is active, called the current focus. The
current focus responds to user input and may be toggled between content focus
and user interface focus through the keyboard, pointing device, etc. Both the
content and user interface focus may be
highlighted. Refer also to the
definition of point of regard.

An input configuration is the mapping of user agent
functionalities to some user
interface trigger mechanisms (e.g., menus, buttons, keyboard keys,
voice commands, etc.). The default input configuration is the mapping the user
finds after installation of the software; it must be included in the user agent
documentation.

For the purposes of this document, a multimedia
presentation is a presentation that synchronizes both auditory and visual
information. This includes, for example, any movie that has sound as well as
animations that present audio. A multimedia presentation has a visual track and
an auditory track.

A user agent supports a feature natively if it does not
require another piece of software (e.g., plug-in or external program) for
support. Operating system features adopted by the user agent to meet the
requirements of this document are considered part of native support. User
agents may, but are not required to, provide access to adopted operating system
features through the user agent's user interface or programmatic means. For
example, if the user agent relies on the operating system's audio control
features to meet some requirements of this document, the user agent is not
required to include those controls in its native user interface. If an adopted
operating system feature is not accessible through the operating system's user
interface, then the user agent must provide an alternative accessible
solution.

The point of regard of a
viewport is its position in
rendered content. What is meant precisely by "the point of regard"
may vary since users may be viewing rendered content with browsers that render
in various ways (graphically, as speech, as
Braille, etc.). Depending on the user agent and browsing context, it may refer
to a two dimensional area (e.g., for graphical rendering) or a single point
(e.g., for aural rendering or voice browsing). The point of regard may also
refer to a particular moment in time for content that changes over time (e.g.,
an auditory
presentation). User agents may use the
focus, selection, or other means to
designate the point of regard. A user agent should not change the point of
regard unexpectedly as this may disorient the user.

A profile is a named and persistent representation of user preferences that
may be used to configure a user agent. Preferences include input
configurations, style preferences, etc. On systems with distinct user accounts,
profiles enable users to reconfigure software quickly when they log on, and
they may be shared by several users. Platform-independent profiles are useful
for those who use the same user agent on different platforms.

A user agent renders a document by applying formatting
algorithms and style information to the document's elements. Formatting depends
on a number of factors, including where the document is rendered: on screen, on
paper, through speakers, on a Braille display, on a mobile device, etc. Style
information (e.g., fonts, colors, voice inflection, etc.) may come from the
elements themselves (e.g., certain font and phrase elements in HTML), from
style sheets, or from user agent settings. For the purposes of these
guidelines, each formatting or style option is governed by a property and each
property may take one value from a set of legal values. Generally in this
document, the term "property" has
the meaning defined in CSS 2 ([CSS2], section 3). A reference to "styles" in this document means a
set of style-related properties.

The value given to a property by a user agent when it is
installed is called the property's default
value.

A user agent is said to recognize markup, content types,
or rendering effects when it can identify the information. Recognition may
occur through built-in mechanisms, Document Type Definitions (DTDs) style sheets, HTTP headers, and
other means. An example of failure of recognition is that
HTML 3.2 user agents may not recognize the new elements or attributes
of HTML 4.01 [HTML4].
While a user agent may recognize blinking content specified by elements or
attributes, it may not recognize blinking in an applet. The Techniques document
[UAAG10-TECHS] lists some markup known to affect accessibility that should
be recognized by user agents.

The selection generally identifies a range of content
(e.g., text, images, etc.) in a document. The
selection may be structured (based on the document tree) or
unstructured (e.g., text-based). Content may be selected through user
interaction, scripts, etc. The selection may be used for a variety of purposes:
for cut and paste operations, to designate a specific element in a document, to
identify what a screen reader should read, etc.

The selection may be set by the user (e.g., by a pointing
device or the keyboard) or through an application programming interface (API).
A viewport has at most one selection (though the selection may be rendered graphically as discontinuous text fragments).
When several viewports coexist, each may have a selection, but only one is
active, called the current selection.

On the screen, the selection may be highlighted using colors, fonts, graphics,
magnification, etc. The selection may also be rendered as inflected speech, for
example.

Operating systems are designed to be used by default with
devices such as pointing devices, keyboards, voice input, etc. The operating
system (or windowing system) provides "standard APIs" for these devices. On desktop computers
today, the standard input APIs are for the mouse and keyboard. For touch screen
devices or mobile devices, standard input APIs may include stylus, buttons,
voice, etc. The graphical display and sound card are considered standard ouput
devices for a graphical desktop computer environment, and each has a standard
API.

The time-coordination of two or more presentation components (e.g., in a
multimedia presentation, an audio presentation with its captions, etc.). For
Web content developers, the requirement to synchronize means to provide the
data that will permit sensible time-coordinated rendering by a user agent. For
example, Web content developer can ensure that the segments of caption text are
neither too long nor too short, and that they map to segments of the visual
track that are appropriate in length. For user agent developers, the
requirement to synchronize means to present the content in a sensible
time-coordinated fashion under a wide range of circumstances including
technology constraints (e.g., small text-only displays), user limitations (slow
reading speeds, large font sizes, high need for review or repeat functions),
and content that is sub-optimal in terms of accessibility.

The coordination of user interface changes (e.g., focus changes) among two
or more viewports.

A text transcript is a text equivalent of audio
information (e.g., an auditory
presentation or the auditory track of a movie or animation). It
provides text for both spoken words and non-spoken sounds such as sound
effects. Text transcripts make audio information accessible to people who have
hearing disabilities and to people who cannot play the audio. Text transcripts
are usually pre-written but may be generated on the fly (e.g., by
speech-to-text converters). Refer also to the definitions of captions and collated text transcripts.

A user agent is software that retrieves and renders Web
content, including text, graphics, sounds, video, images, and other content
types. A user agent may require additional user agents that handle some types
of content. For instance, a browser may run a separate program or plug-in to
render sound or video. User agents include graphical desktop browsers,
multimedia players, text browsers, voice browsers, and assistive technologies such
as screen readers, screen magnifiers, speech synthesizers, onscreen keyboards,
and voice input software.

User agent default styles are style property
values applied in the absence of any author or user styles. Some
markup languages specify a default rendering for documents in that markup
language. Other specifications may not specify default styles. For example,
XML 1.0
[XML] does not specify default styles for XML documents.
HTML 4
[HTML4] does not specify default styles for HTML documents, but the CSS 2
[CSS2] specification
suggests a
sample default style sheet for HTML 4 based on current practice.

An action initiated by the user is one that results from
user operation of the user interface. An action initiated by the user agent is
one that results from the execution of a script (e.g., an event handler bound to an event not triggered
through the user interface), from operating system conditions, or from built-in
user agent behavior.

A visual object is content that, when rendered, is
perceived through sight. Visual objects may be static (e.g., and image) or
dynamic (e.g., video). The media type of some objects (e.g., images, video)
suggests strongly that they are meant to be rendered graphically. Objects of
other media types may be rendered graphically or in other modes. For instance,
text may rendered graphically and statically, graphically and dynamically
(e.g., by blinking, scrolling, or other animation), as sound, or as
braille.

User agents may handle different types of content: markup language, sound, video, etc. The user
views rendered content
through a viewport, which may be a
window, a frame, a piece of paper, a speaker, a virtual magnifying glass, etc.
A viewport may contain another viewport (e.g., nested frames). Viewports do not
include user interface controls such as prompts, menus, alerts, etc.

The viewport that contains both the current focus and the current selection is called
the current viewport. The
current viewport is generally highlighted
when several viewports coexist. A user agent should provide mechanisms for
accessing all content that can be presented by each viewport (e.g., scrolling
mechanisms, advance and rewind, etc.).

User agents may render the same content in a variety of
ways; each rendering is called a view.
For instance, a user agent may allow users to view an entire document or just a
list of the document's headers. These are two different views of the
document.

Note:W3C does not guarantee the stability of any of
the following references outside of its control. These references are included
for convenience. References to products are not endorsements of those
products.

"What is Accessible
Software", James W. Thatcher, Ph.D., IBM, 1997. This paper gives a short
example-based introduction to the difference between software that is
accessible, and software that can be used by some assistive technologies.

Information on accessibility guidelines
for Unix and X Window applications. The
Open Group has various guides that explain the Motif and Common Desktop
Environment (CDE) with topics like how users interact with
Motif/CDE applications and how to customize these environments.
Note: In X, the terms client and server are used differently from
their use when discussing the Web.