Abstract
A user agent is a set of modules that retrieves
Web resources, renders them, allows control of those processes, and
communicates with other software. An assistive
technology is a user agent that (1) relies on another
user agent to provide some services and (2) provides services beyond
those offered by the supporting user agent to meet the
requirements of users with disabilities.
To ensure both general accessibility and interoperability with
assistive technologies, the User Agent Accessibility
Guidelines require that conforming general purpose user
agents:
- support some accessibility features natively, and
- provide content and user interface information
to assistive technologies that may offer additional functionalities,
renderings, or user interfaces.
The User Agent Guidelines Working Group has
spent considerable effort debating which requirements must be
supported natively by conforming (general purpose) user agents and
which are better handled by assistive technologies. This document
presents the Working Group's rationale for including each checkpoint
in the guidelines.
Status of this Document
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 document has been created as support material for the User
Agent Guidelines 1.0 Candidate Recommendation [ URI not yet
available]. This document is not meant to become a W3C
Recommendation.
This is a W3C Working Draft 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 W3C or the
User Agent
Guidelines Working Group.
Please send comments about this document to the public mailing
list w3c-wai-ua@w3.org
(public
archives).
This document has been produced as part of the Web Accessibility Initiative. The
goals of the User Agent Working
Group are described in the charter. A
list of the Working Group
participants is available.
A list of current W3C Recommendations and other technical documents
can be found at http://www.w3.org/TR.
Table of Contents
The User Agent Accessibility
Guidelines include two types of requirements for general purpose
user agents:
- Native implementation of some some accessibility features.
The user agent must satisfy these requirements without
requiring additional software other than the operating system
so that general purpose user agents are accessible to most
users.
- Communication of information (content and user interface)
to assistive technologies that provide alternative
user interfaces for specific disabilities. General purpose
user agents are required to allow read and write access to both
content and user interface controls.
Native support for features is required for
"applicable checkpoints" and may vary according to user agent
type. Graphical user agents, for example, are required to make both
the user interface and rendering accessible. This includes:
- Support user interaction with content and user interface
with both the keyboard and pointing device.
- Allowing the user to control colors, text size, font family,
and other style parameters
- Providing access to primary and alternative content
Voice browsers would have similar requirements, but would satisfy
some of them differently, relying on input and output techniques using
speech. This includes:
- Support user interaction with content and user interface
through voice input (in addition
to other supported input devices).
- Allowing the user to control speech rendering parameters.
- Providing access to primary and alternative content
using speech input commands (e.g., to scroll)
and providing orientation information (e.g., cell headers)
through speech.
The second requirement, communication with assistive technologies,
ensures that specialized software has access to the content and user
interface of general-purpose user agents. This allows assistive
technologies provide additional functionalities for specific user
requirements and to offer alternative renderings. For example, a
graphical desktop user agent may provide a number of functionalities
(search mechanisms, bookmarks, etc.) useful to all users. However,
since the graphical rendering is generally not meaningful to users
with blindness, assistive technologies may complement the graphical
user agent by rendering the content as speech or Braille.
The following review is based on the 20 December
1999 UA Guidelines and updates since then.
As part of providing rationale for requiring native support,
checkpoints are grouped by theme. This grouping makes it relatively
easy to understand why most of the checkpoints require native support
in general purpose user agents for the functionalities in
question. The themes are:
- The requirements of these checkpoints are
applicable to all user agents.
- The requirements of these checkpoints refer to
content rendered natively by the user agent.
- The requirements of these checkpoints refer to
control of user interface features supported natively.
- The requirements of these checkpoints pertain
to communication with assistive technologies and
thus were designed specifically for general purpose user agents.
- The Working Group established by consensus that
the requirements of these checkpoints
were essential and must
be implemented natively by general purpose user agents.
- The requirements of these checkpoints were considered
to be the responsibility of assistive
technologies by the Working Group.
All user agents should meet these requirements, although how they
are met will depend on the type of user agent. These requirements
concern device independence, the native user interface, and the
documentation.
Inherit OS features
The user agent should satisfy the following requirements
by using features provided by the operating system, when available.
- Checkpoint 4.13 Allow the user to configure how the selection is highlighted (e.g., foreground and background color).
- Checkpoint 4.14 Allow the user to configure how the content focus is highlighted (e.g., foreground and background color).
- Checkpoint 7.1 Allow the user to navigate viewports (including frames).
- Checkpoint 8.5 Provide a mechanism for highlighting and identifying (through a standard interface where available) the current viewport, selection, and content focus.
- Checkpoint 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.).
- Checkpoint 10.7 For the configuration requirements of this document, allow the user to save user preferences a profile.
Implement in user agent
The user agent should satisfy the following requirements
natively.
- Checkpoint 1.3 Ensure that the user can interact with all active elements in a device-independent manner.
- Checkpoint 2.1 Ensure that the user has access to all content, including equivalent alternatives for content.
- Checkpoint 4.16 Allow the user to configure viewports, prompts, and windows opened on user agent initiation.
- Checkpoint 5.6 Implement selection, content focus, and user interface focus mechanisms.
- Checkpoint 5.9 Follow operating system conventions and accessibility settings. In particular, follow conventions for user interface design, default keyboard configuration, product installation, and documentation.
- Checkpoint 6.1 Implement the accessibility features of supported specifications (markup languages, style sheet languages, metadata languages, graphics formats, etc.).
- Checkpoint 6.2 Conform to W3C Recommendations when they are appropriate for a task.
- Checkpoint 7.2 For user agents that offer a browsing history mechanism, when the user returns to a previous viewport, restore the point of regard in the viewport.
- Checkpoint 8.7 Provide a mechanism for highlighting and identifying active elements (through a standard interface where available).
- Checkpoint 9.4 When loading content (e.g., document, image, audio, video, etc.) indicate what portion of the content has loaded and whether loading has stalled.
- Checkpoint 10.2 Avoid default input configurations that interfere with operating system accessibility conventions.
- Checkpoint 10.6 Follow operating system conventions to indicate the input configuration.
- Checkpoint 10.8 Ensure that frequently used functionalities are easily activated in the default input configuration.
- Checkpoint 11.1 Provide a version of the product documentation that conforms to the Web Content Accessibility Guidelines 1.0 [[WCAG10]].
- Checkpoint 11.2 Document all user agent features that promote accessibility.
- Checkpoint 11.3 Document the default input configuration (e.g., default keyboard bindings).
- Checkpoint 11.4 In a dedicated section of the documentation, describe all features of the user agent that promote accessibility.
- Checkpoint 11.5 Document changes between software releases.
It makes sense for user agents to provide native support
for content rendered natively.
Inherit OS features
The user agent should satisfy the following requirements
by using features provided by the operating system, when available.
- Checkpoint 3.2 Allow the user to turn on and off rendering of background audio.
- Checkpoint 3.3 Allow the user to turn on and off rendering of video.
- Checkpoint 3.4 Allow the user to turn on and off rendering of audio.
- Checkpoint 4.1 Allow the user to configure the size of text.
- Checkpoint 4.2 Allow the user to configure font family.
- Checkpoint 4.3 Allow the user to configure foreground color.
- Checkpoint 4.4 Allow the user to configure background color.
- Checkpoint 4.5 Allow the user to slow the presentation rate of audio, video, and animations.
- Checkpoint 4.7 Allow the user to configure the position of text transcripts, collated text transcripts, and captions on graphical displays.
- Checkpoint 4.9 Allow the user to configure synthesized speech playback rate.
- Checkpoint 4.10 Allow the user to configure synthesized speech volume.
Implement in user agent
The user agent should satisfy the following requirements
natively.
- Checkpoint 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).
- Checkpoint 2.3 When the author has not supplied a text equivalent for content as required by the markup language, make available other author-supplied information about the content (e.g., object type, file name, etc.).
- Checkpoint 2.4 When a text equivalent for content is explicitly empty (i.e., an empty string), render nothing.
- Checkpoint 3.1 Allow the user to turn on and off rendering of background images.
- Checkpoint 3.5 Allow the user to turn on and off animated or blinking text.
- Checkpoint 3.6 Allow the user to turn on and off animations and blinking images.
- Checkpoint 3.7 Allow the user to turn on and off support for scripts and applets.
- Checkpoint 3.8 For automatic content changes specified by the author (e.g., redirection and content refresh), allow the user to slow the rate of change.
- Checkpoint 3.9 Allow the user to turn on and off rendering of images.
- Checkpoint 4.6 Allow the user to start, stop, pause, advance, and rewind audio, video, and animations.
- Checkpoint 4.8 Allow the user to configure the audio volume.
- Checkpoint 4.11 Allow the user to configure synthesized speech pitch, gender, and other articulation characteristics.
- Checkpoint 8.1 Make available to the user the author-specified purpose of each table and the relationships among the table cells and headers.
- Checkpoint 8.2 Indicate to the user whether a link has been visited.
- Checkpoint 8.3 Indicate to the user whether a link has been marked up to indicate that following it will involve a fee.
- Checkpoint 8.4 To help the user decide whether to follow a link, make available link information supplied by the author and computed by the user agent.
For those parts of the user interface provided natively
by the user agent, it makes sense to provide native control.
- Checkpoint 2.5 If more than one equivalent alternative is available for content, allow the user to choose from among the alternatives. This includes the choice of viewing no alternatives.
- Checkpoint 2.6 Allow the user to specify that text transcripts, collated text transcripts, captions, and auditory descriptions be rendered at the same time as the associated auditory and visual tracks. Respect author-supplied synchronization cues during rendering.
- Checkpoint 2.7 For author-identified but unsupported natural languages, allow the user to request notification of language changes in content.
- Checkpoint 4.12 Allow the user to select from available author and user style sheets or to ignore them.
- Checkpoint 4.15 Allow the user to configure how the focus changes.
- Checkpoint 7.3 Allow the user to navigate all active elements.
- Checkpoint 7.4 Allow the user to choose to navigate only active elements.
- Checkpoint 8.9 Allow the user to configure what information about links to present.
- Checkpoint 9.1 Ensure that when the selection or content focus changes, it is in a viewport after the change.
- Checkpoint 9.2 Prompt the user to confirm any form submission triggered indirectly, that is by any means other than the user activating an explicit form submit control.
- Checkpoint 9.3 Allow the user to configure notification preferences for common types of content and viewport changes.
- Checkpoint 10.1 Provide information to the user about current user preferences for input configurations (e.g., keyboard or voice bindings).
- Checkpoint 10.3 Provide information to the user about current author-specified input configurations (e.g., keyboard bindings specified in content such as by "accesskey" in HTML).
- Checkpoint 10.4 Allow the user to change the input configuration.
- Checkpoint 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 (keystroke, voice command, etc.).
- Checkpoint 10.9 Allow the user to configure the arrangement of graphical user agent user interface controls.
These requirements were designed specifically for
general purpose user agents to ensure interoperability. They
may also apply to user agents in general.
- Checkpoint 1.1 Ensure that every functionality available through the user interface is also available through every input device API supported by the user agent. Excluded from this requirement are functionalities that are part of the input device API itself (e.g., text input for the keyboard API, pointer motion for the pointer API, etc.)
- Checkpoint 1.2 Use the standard input and output device APIs of the operating system.
- Checkpoint 1.4 Ensure that every functionality available through the user interface is also available through the standard keyboard API.
- Checkpoint 1.5 Ensure every non-text message (e.g., prompt, alert, etc.) available through the user interface also has a text equivalent in the user interface.
- Checkpoint 5.1 Provide programmatic read access to HTML and XML content by conforming to the W3C Document Object Model (DOM) Level 2 Core and HTML modules and exporting the interfaces they define.
- Checkpoint 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.
- Checkpoint 5.3 For markup languages other than HTML and XML, provide programmatic access to content using standard APIs (e.g., platform-independent APIs and standard APIs for the operating system).
- Checkpoint 5.4 Provide programmatic access to Cascading Style Sheets (CSS) by conforming to the W3C Document Object Model (DOM) Level 2 CSS module and exporting the interfaces it defines.
- Checkpoint 5.5 Provide programmatic read and write access to user agent user interface controls using standard APIs (e.g., platform-independent APIs such as the W3C DOM, standard APIs for the operating system, and conventions for programming languages, plug-ins, virtual machine environments, etc.)
- Checkpoint 5.7 Provide programmatic notification of changes to content and user interface controls (including selection, content focus, and user interface focus).
- Checkpoint 5.8 Ensure that programmatic exchanges proceed in a timely manner.
Note. For information about WG resolutions for
these checkpoints, please refer to the rationale provided in the 6
January 2000 UAGL teleconference minutes.
- Checkpoint 7.5 Allow the user to search for rendered text content, including rendered text equivalents.
- Checkpoint 7.6 Allow the user to navigate according to structure.
- Checkpoint 7.7 Allow the user to configure structured navigation.
- Checkpoint 8.6 Make available to the user an "outline" view of content, built from structural elements (e.g., frames, headers, lists, forms, tables, etc.).
- Checkpoint 8.8 Allow the user to configure the outline view.
The Working Group has decided that the following requirements, once
checkpoints, belonged to assistive technologies. These requirements
are listed in the
Appendix of Assistive Technology Functionalities of the 20
December 1999 Techniques Document.
Navigation checkpoints
- Allow users to navigate up/down and among the cells of a table
(e.g., by using the focus to designate a selected table cell).
Context/Orientation checkpoints
-
Indicate the row and column dimensions of a selected table.
-
Describe a selected element's
position within larger structures (e.g., numerical or relative
position in a document, table, list, etc.).
-
Provide information about form structure
and navigation (e.g., groups of controls, control labels,
navigation order, and keyboard configuration).
- Enable announcing of information regarding title, value, grouping,
type, status and position of specific focused elements.
The following sections provide some additional discussion and
rationale for decisions by the Working Group about native support
for accessibility features.
A user agent is a set of modules that retrieves Web resources,
renders them, allows the user to control those processes, and
communicates with other software. For instance, a graphical desktop
browser might consist of:
- A parser and a tree processing engine
- One or more rendering engines that, given a tree and style parameters,
creates rendering structures.
- A user interface for providing access to content. This includes:
- Viewports
- Navigation and search mechanisms, which allow the user to access
content other than sequentially.
- Orientation mechanisms such as proportional scroll bars,
highlighting of viewports, selection and focus, etc.
- A user interface for configuring the browser, including parameters of
the rendering engines(s), processing information such as natural language
preferences, and the user interface itself (e.g., position of buttons in
the GUI).
- A user interface for facilitating browsing (history mechanism, bookmark
mechanism, etc.)
- Other user interface features (e.g., refresh the screen, reload the
document, send to the printer, etc.)
- Interpreters for scripting languages. For instance,
a Java Virtual Machine to support Java Applets.
- APIs for communication with plug-ins.
- Facilities for loading assistive technologies
- Public interfaces (e.g., for HTTP, for the Document Object
Model (DOM), for file i/o including document
loading and printing, communication with the operating system,
etc.)
-
Note that there are areas where content and user interface mingle,
including:
- Form controls
- Links and their styling
- Keyboard and other input configurations provided by the author
or overridden by the user
- Adoption of markup languages for implementation of UI controls (as is
done, e.g., by IE using HTML and as is done by Mozilla by using XML and
the DOM for UI controls).
For simplicity, we consider for now that the UI refers to the UA's
components, not those contributed by Web content.
In the context of this document, an assistive technology
(AT) is a user agent that (1) relies on another user
agent to provide some services and (2) provides services beyond those
offered by the "host user agent" to meet the requirements of a user
with a disability. Additional services might include:
- An alternative rendering to the user (e.g., speech
output) using the user agent document tree.
- An alternative mechanism to complete forms
(e.g., write access to the document source through voice input
and voice-to-text conversion).
- Aural notification of which viewport is selected through the
user agent provided access features.
- Navigation of viewports using speech input (e.g., a small
vocabulary of navigation commands).
- Content transformation tools (e.g., style sheets)
- Additional navigation mechanisms
- Additional orientation mechanisms
- User preference mechanisms (e.g., profiles)
for user interface controls, keyboard bindings,
presentation rendering choices, and possibly style sheets.
An assistive technology does not always parse document source, for
example, but may have to include tree processing capabilities (e.g.,
by implementing the W3C DOM) in order to offer additional
functionalities.
The following sections describe some of the factors
that have affected the decision about which functionalities
should be supported natively by general purpose user agents.
Existing practice
One of the most important factors affecting the accessibility of
today's general-purpose user agents is compatibility with current
assistive technology. For instance, keyboard access to user agent
functionality is essential for access today. Not only do users who
cannot use a pointing device (users with some visual and physical
disabilities) rely on the keyboard, assistive technologies such as
voice recognition software and specialized keyboards rely on the
keyboard API for access to the general purpose user agent's
functionalities.
Many current assistive technologies also gather information about
content from graphical user agents by intercepting text drawing
commands as content is rendered graphically. For example, this
technique is used extensively by screen readers to "see" what is being
displayed in a graphical view. But in relying on rendered content,
screen readers lose the original structure of the content, making it
difficult to convey structure to the user of speech or Braille. While
assistive technologies have been resourceful in using heuristics for
recovering structure, the results may be idiosyncratic and platform
dependent, often failing to improve access to Web content by people
with disabilities.
One other factor has influenced the Working Group's decisions
to require native support for some features: if a number of
general purpose user agents already provide a functionality (thus
demonstrating both its utility and feasibility), the Working Group
considers that these user agents should continue to support the
feature (e.g., navigation of active elements in a document).
The W3C Document Object Model (DOM)
The development of a platform- and programming-language independent
API for accessing Web content makes it easier for assistive technology
developers to provide specialized renderings based on the original
document structure, and not derived from a graphical rendering. Once
an assistive technology implements the DOM, the cost of extending the
software to communicate with other user agents or the same user agent
on other platforms is greatly reduced.
One reason the Working Group has hesitated to rely more heavily on
the W3C DOM for ensuring access to content has been
the lack of a standard for exposing the DOM API to other applications
(and ensuring timely access to the document structure); how user
agents expose the DOM varies from platform to platform.
Furthermore, since assistive technologies are often designed
to work with other software (e.g., word processors, spread sheet
programs, etc.) than just user agents,
some assistive technology developers have expressed concerns about
the DOM as "one more interface" to support that may differ
significantly from how they access information in other applications.
Finally, there is not yet a platform-independent API for accessing
user interface controls. In the future, the DOM might be extended to
include access to user interface controls.
No minimal functional requirement obvious
In developing the guidelines, the Working Group attempted to
identify the "minimal requirements" a user agent would have to satisfy
natively to be considered accessible. For some functionalities,
minimal requirements were difficult to identify, and therefore the
Working Group generally chose either:
- to make a general requirement and leave the specifics
to the Techniques Document, or
- to make no requirement on general purpose user agents
and require that the need be met by assistive technologies.
Requirement depends on rendering
In many cases, the Working Group identified the source of the
difficulty to be that a requirement was dependent on a particular
input or output method and did not readily translate to another. For
instance, requiring up and down navigation of graphically rendered
table cells makes sense in a graphical environment, but this type of
navigation by users of speech or Braille output may be tedious or
insufficient. While all users must have access to table content and
cell relationships, how that functionality is provided relies heavily
on how the user views the information.
In the particular case of tables, the guidelines require:
- Structured navigation.
- Access to table functionality and cell/header relationships
How navigation and access are provided will depend on the type of
user agent and to what devices they render content; the Techniques
Document suggests solutions for different types of user agent.
Likelihood of implementation
The requirements of the Guidelines are not completely independent
of considerations of implementability or cost. The Techniques Document
represents the WG's efforts at showing how each requirement may be
implemented. However, the WG may have chosen not to make certain
requirements either because it seemed "unreasonable" to ask desktop
browsers to implement the functionality or because the likelihood of
implementation and conformance seemed low.
User/Expert Experience
The Working Group has endeavored to incorporate feedback from users
with disabilities and experts in different fields related to
accessibility about important requirements for these guidelines.