W3C

User Agent Responsibilities

28 December 1999

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

Abstract

This document examines User Agent Guidelines Working Group rationale for establishing which user agent functionalities must be supported natively by general purpose user agents and which are expected to be supported by assistive technologies.

Status of this Document

This document does not represent consensus of the User Agent Accessibility Guidelines Working Group. As of the date at the top of the document, it only represents the musings of Ian Jacobs, who hopes it will serve as a support document for the User Agent Accessibility Guidelines as they advance on the Recommendation track.

Table of Contents


Introduction

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

  1. Requirements for native implementation of some functionalities (i.e., the user agent implements them without requiring additional software other than the operating system).
  2. Communication through Application Programming Interfaces (APIs). The Guidelines require user agents to allow read and write access to both content and user interface controls.

The second set of requirements allows assistive technologies (ATs) to offer missing functionalities not offered natively. Since the Guidelines require that ATs have access to both content and UI controls, in theory, general-purpose user agents have to implement natively few functionalities related to accessibility since ATs can fill in the gaps. They might even do a better job since developers of specialized tools know their target audience well.

The Working Group has decided that general-purpose user agents must implement some important functionalities natively rather than relying on Assistive Technologies to shoulder the load. One important reason for this decision is that some users do not have access to or cannot afford specialized browsers, so general-purpose user agents must themselves be accessible.

This document explains which requirements the User Agent Guidelines Working Group has chosen for general purpose user agents to implement natively and why.

What is a User Agent?

A user agent is a set of modules that retrieves Web resources, renders them, allows control of 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?

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 "host user agent" to meet the requirements of a target audience. Additional services might include:

An assistive technology may not parse document source, for example, but probably has to include tree processing capabilities 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

Some general-purpose user agents already provide useful functionalities such as allowing users to navigate links through the keyboard. Assistive technologies read the focus and speak or render as braille the link text. One might argue that links are so fundamental to browsing the Web that it makes sense to require navigation of these links to be a native functionality, I believe that in part the current requirement is a perpetuation of existing practice. Lynx offers direct access to links by number, not just sequential access, and this has shown itself to be a useful time-saving functionality.

The DOM

The existence of a platform- and programming-language independent way to access content means that it's more understandable to ask AT developers to provide some functionalities. Note, however, that the lack of a standard for exposing the DOM may hinder adoption. Also, since assistive technology products are usually designed to work with other software than user agents, requiring them to implement a UA-specific interface may be considered burdensome. Finally, there is not yet a platform-independent API for accessing user interface controls.

No minimal functional requirement obvious

The WG attempted to identify "minimal requirements" a user agent would have to satisfy to be considered accessible (at times, the bar is quite high in fact). For some functionalities, minimal requirements were difficult or impossible to identify, and therefore the WG chose either:

One example of this includes table navigation. Access to table cells and cell context (headers, neighboring cells, etc.) is very important to users and there is a Priority 1 requirement that such information be made available to users. However, navigation of table cells is just one (admittedly useful) means to achieve the goals of access to content and orientation. Two problems present themselves, however:

Likelihood of implementation

The requirements of the Guidelines are not 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.

Review of specific requirements

The following review is based on the 20 December 1999 UA Guidelines.

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 pertain to communication with assistive technologies and thus were designed specifically for general purpose user agents.
  4. The requirements of these checkpoints are not readily assignable to a particular class of user agent.
  5. 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 to documentation.

Requirements for content rendered natively

It makes sense for user agents to provide native support for content rendered natively.

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.

Unknown

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

Navigation checkpoints

The Working Group has generally considered navigation a technique for providing access to content and context. People would probably agree that without adequate navigation, access to content and context may be so slow as to make the content unusable. However, there has not been agreement as to what minimal navigation requirements (if any) should be made of general purpose user agents. Below, some rationale is offered.

Checkpoint 7.3 Allow the user to navigate all active elements.
Checkpoint 7.4 Allow the user to navigate just among all active elements.
This is just a special case of 7.3 and so once 7.3 is settled, this one will follow.
Checkpoint 7.5 Allow the user to search for rendered text content, including text equivalents of visual and auditory content.
Checkpoint 7.6 Allow the user to navigate according to structure.
This checkpoint has been included as an umbrella checkpointn because there are many many navigation possibilities. Rather than list all of them (per element type, by tree structure, by element content, etc.), the WG put them all into a single, Priority 2, intentionally ambiguous checkpoint.
Checkpoint 7.7 Allow the user to configure structured navigation.
This one follows 7.6

Context/orientation checkpoints

Checkpoint 8.1 Convey the author-specified purpose of each table and the relationships among the table cells and headers.
Checkpoint 8.5 Provide a "outline" view of content, built from structural elements (e.g., frames, headers, lists, forms, tables, etc.)
Checkpoint 8.6 Allow the user to configure the outline view.
This one follows 8.5.

Configuration checkpoints

These may apply to all user agents.

Checkpoint 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.).
Checkpoint 10.8 Allow the user to configure the arrangement of graphical user agent user interface controls.

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