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 document does not represent consensus of the User Agent Accessibility Guidelines Working Group.
The Working Group has reviewed this document and discussed it at their
5 January 2000
and
6 January 2000
teleconferences.
The Working Group intends to make this a support document for the
User Agent Accessibility Guidelines as the guidelines advance to
Recommendation.
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.
In order to provide rationale for requiring native support by
general purpose user agents of certain functionalities, I've grouped
them 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 are
not
readily assignable to a particular class of user agent.
- 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.
- 4.13 Allow the user to control how the selection is highlighted (e.g., foreground and background color). [Priority 1]
- 4.14 Allow the user to control how the content focus is highlighted (e.g., foreground and background color). [Priority 1]
- 7.1 Allow the user to navigate viewports (including frames). [Priority 1]
- 8.4 Provide a mechanism for highlighting and identifying (through a standard interface where available) the current viewport, selection, and content focus. [Priority 1]
- 10.6 Allow the user to configure the user agent in named profiles that may be shared on systems with distinct user accounts. [Priority 2]
- 9.6 Indicate the relative position of the viewport in 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]
Implement in user agent
The user agent should satisfy the following requirements
natively.
- 2.1 Ensure that the user has access to all content, including alternative equivalents for content. [Priority 1]
- 6.1 Implement the accessibility features of supported specifications (markup languages, style sheet languages, metadata languages, graphics formats, etc.). [Priority 1]
- 11.1 Provide a version of the product documentation that conforms to the Web Content Accessibility Guidelines. [Priority 1]
- 11.2 Document all user agent features that promote accessibility. [Priority 1]
- 11.3 Document the default input configuration (e.g., default keyboard bindings). [Priority 1]
- 5.3 Implement selection, content focus, and user interface focus mechanisms and make them available to users and through APIs. [Priority 1]
- 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. [Priority 1]
- 1.3 Ensure that the user can interact with all active elements in a device-independent manner. [Priority 1]
- 5.6 Follow operating system conventions and accessibility settings. In particular, follow conventions for user interface design, default keyboard configuration, product installation, and documentation. [Priority 2]
- 11.4 In a dedicated section, document all features of the user agent that promote accessibility. [Priority 2]
- 4.15 Allow the user to control user agent-initiated spawned viewports. [Priority 2]
- 10.4 Use operating system conventions to indicate the input configuration. [Priority 2]
- 10.5 Avoid default input configurations that interfere with operating system conventions. [Priority 2]
- 8.6 Provide a mechanism for highlighting and identifying active elements (through a standard interface where available). [Priority 2]
- 9.5 When loading content (e.g., document, video clip, audio clip, etc.) indicate what portion of the content has loaded and whether loading has stalled. [Priority 3]
- 8.9 Maintain consistent user agent behavior and default configurations between software releases. Consistency is less important than accessibility and adoption of operating system conventions. [Priority 3]
- 10.7 Provide default input configurations for frequently performed tasks. [Priority 3]
- 6.2 Conform to W3C specifications when they are appropriate for a task. [Priority 2]
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.
- 4.4 Allow the user to control font family. [Priority 2]
- 4.1 Allow the user to control the size of text. [Priority 1]
- 4.2 Allow the user to control foreground color. [Priority 1]
- 4.3 Allow the user to control background color. [Priority 1]
- 4.5 Allow the user to slow the presentation rate of audio, video, and animations. [Priority 1]
- 4.8 Allow the user to control the position of captions on graphical displays. [Priority 1]
- 4.9 Allow the user to control synthesized speech playback rate. [Priority 1]
- 4.10 Allow the user to control synthesized speech volume. [Priority 1]
- 3.2 Allow the user to turn on and off rendering of background audio. [Priority 1]
- 3.3 Allow the user to turn on and off rendering of video. [Priority 1]
- 3.4 Allow the user to turn on and off rendering of audio. [Priority 1]
Implement in user agent
The user agent should satisfy the following requirements
natively.
- 2.2 For presentations that require user interaction within a specified time interval, allow the user to control the time interval (e.g., by allowing the user to pause and restart the presentation, to slow it down, etc.). [Priority 1]
- 3.1 Allow the user to turn on and off rendering of background images. [Priority 1]
- 3.5 Allow the user to turn on and off animated or blinking text. [Priority 1]
- 3.6 Allow the user to turn on and off animations and blinking images. [Priority 1]
- 3.7 Allow the user to turn on and off support for scripts and applets. [Priority 1]
- 3.9 For automatic content changes specified by the author (e.g., content refresh and page forwards), allow the user to slow the rate of change. [Priority 3]
- 2.3 When no text equivalent has been supplied for an object, make available author-supplied information to help identify the object (e.g., object type, file name, etc.). [Priority 2]
- 4.6 Allow the user to start, stop, pause, advance, and rewind audio, video, and animations. [Priority 1]
- 4.7 Allow the user to control the audio volume. [Priority 2]
- 4.11 Allow the user to control synthesized speech pitch, gender, and other articulation characteristics. [Priority 2]
- 2.4 When a text equivalent for content is explicitly empty (i.e., an empty string), render nothing. [Priority 3]
- 3.8 Allow the user to turn on and off rendering of images. [Priority 3]
- 8.3 Provide information to help the user decide whether to follow a link. [Priority 3]
- 8.2 Indicate whether a link has been marked up to indicate that following it will involve a fee. [Priority 2]
For those parts of the user interface provided natively
by the user agent, it makes sense to provide native control.
- 7.3 Allow the user to navigate all active elements. [Priority 1]
(Refer to 6 January 2000 UAGL teleconference minutes).
- 7.4 Allow the user to limit navigation to active elements. [Priority 2]
(Refer to 6 January 2000 UAGL teleconference minutes).
- 2.5 If more than one alternative equivalent is available for content, allow the user to choose from among the alternatives. This includes the choice of viewing no alternatives. [Priority 1]
- 2.6 Allow the user to specify that captions and auditory descriptions be rendered at the same time as the associated auditory and visual tracks. [Priority 1]
- 2.7 For author-identified but unsupported natural languages, allow the user to request notification of language changes in content. [Priority 3]
- 4.12 Allow the user to select from available author and user style sheets or ignore them. [Priority 1]
- 9.3 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. [Priority 2]
- 9.1 Provide information about user agent-initiated content and viewport changes through the user interface and through APIs [Priority 1]
- 9.4 Allow the user to configure notification preferences for common types of content and viewport changes. [Priority 3]
- 9.2 Ensure that when the selection or content focus changes, it is in a viewport after the change. [Priority 2]
- 10.1 Provide information directly to the user and through APIs about current user preferences for input configurations (e.g., keyboard or voice bindings). [Priority 1]
- 10.2 Provide information directly to the user and through APIs about current author-specified input configurations (e.g., keyboard bindings specified in content such as by "accesskey" in HTML 4.0). [Priority 2]
- 8.8 Allow the user to configure what information about links to present. [Priority 3]
- 10.3 Allow the user to change and control the input configuration. Allow the user to configure the user agent so that some functionalities may be activated with a single command (e.g., single key, single voice command, etc.). [Priority 2]
- 10.8 Allow the user to configure the arrangement of graphical user agent user interface controls. [Priority 3]
These requirements were designed specifically for
general purpose user agents to ensure interoperability. They
may also apply to user agents in general.
- 1.4 Ensure that every functionality offered through the user interface is available through the standard keyboard API. [Priority 1]
- 1.1 Ensure that every functionality offered through the user interface is available through every input device API used by the user agent. User agents are not required to reimplement low-level functionalities (e.g., for character input or pointer motion) that are inherently bound to a particular API and most naturally accomplished with that API. [Priority 1]
- 1.2 Use the standard input and output device APIs of the operating system. [Priority 1]
- 1.5 Ensure that all messages to the user (e.g., informational messages, warnings, errors, etc.) are available through all output device APIs used by the user agent. Do not bypass the standard output APIs when rendering information (e.g., for reasons of speed, efficiency, etc.). [Priority 1]
- 5.1 Provide programmatic read and write access to content by conforming to W3C Document Object Model (DOM) specifications and exporting interfaces defined by those specifications. [Priority 1]
- 5.2 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.) [Priority 1]
- 5.4 Provide programmatic notification of changes to content and user interface controls (including selection, content focus, and user interface focus). [Priority 1]
- 5.5 Ensure that programmatic exchanges proceed in a timely manner. [Priority 2]
Note. For information about WG resolutions for
these checkpoints, please refer to the rationale provided in the 6
January 2000 UAGL teleconference minutes.
- 7.5 Allow the user to search for rendered text content, including text equivalents of visual and auditory content. [Priority 2]
- 7.6 Allow the user to navigate according to structure. [Priority 2]
- 7.7 Allow the user to configure structured navigation. [Priority 3]
- 8.5 Provide a "outline" view of content, built from structural elements (e.g., frames, headers, lists, forms, tables, etc.) [Priority 2]
- 8.7 Allow the user to configure the outline view. [Priority 3]
These checkpoints cannot be readily assignable to a particular
class of user agent.
Context/orientation checkpoints
- 8.1 Convey the author-specified purpose of each table and the relationships among the table cells and headers. [Priority 1]
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, I will 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.