W3C

User Agent Responsibilities

9 January 2000

This version:
http://www.w3.org/WAI/UA/2000/01/ua-resp-20000109
Previous version:
http://www.w3.org/WAI/UA/1999/12/ua-resp-19991228
Editor
Ian Jacobs, W3C

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:

  1. support some accessibility features natively, and
  2. 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


Introduction

The User Agent Accessibility Guidelines include two types of requirements for general purpose user agents:

  1. 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.
  2. 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:

Voice browsers would have similar requirements, but would satisfy some of them differently, relying on input and output techniques using speech. This includes:

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.

Review of specific requirements

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:

  1. The requirements of these checkpoints are applicable to all user agents.
  2. The requirements of these checkpoints refer to content rendered natively by the user agent.
  3. The requirements of these checkpoints refer to control of user interface features supported natively.
  4. The requirements of these checkpoints pertain to communication with assistive technologies and thus were designed specifically for general purpose user agents.
  5. The Working Group established by consensus that the requirements of these checkpoints were essential and must be implemented natively by general purpose user agents.
  6. The requirements of these checkpoints are not readily assignable to a particular class of user agent.
  7. The requirements of these checkpoints were considered to be the responsibility of assistive technologies by the Working Group.

Requirements applicable to all user agents

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.

Implement in user agent

The user agent should satisfy the following requirements natively.

Requirements for content rendered natively

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.

Implement in user agent

The user agent should satisfy the following requirements natively.

Requirements for control of user interface features supported natively

For those parts of the user interface provided natively by the user agent, it makes sense to provide native control.

Requirements for communication

These requirements were designed specifically for general purpose user agents to ensure interoperability. They may also apply to user agents in general.

Requirements considered essential for accessibility

Note. For information about WG resolutions for these checkpoints, please refer to the rationale provided in the 6 January 2000 UAGL teleconference minutes.

Unknown

These checkpoints cannot be readily assignable to a particular class of user agent.

Context/orientation checkpoints

Requirements for Assistive Technologies

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

Context/Orientation checkpoints

Additional rationale

The following sections provide some additional discussion and rationale for decisions by the Working Group about native support for accessibility features.

What is a User Agent?

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:

Note that there are areas where content and user interface mingle, including:

For simplicity, I will consider for now that the UI refers to the UA's components, not those contributed by Web content.

What is an assistive technology?

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

What functionalities must be provided by a general-purpose UA?

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:

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:

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.