User Agent Accessibility Guidelines 1.0

28 July 2002

1. Introduction

This document specifies requirements that, if satisfied by user agent developers, will lower barriers to accessibility. This document includes:

A separate document, entitled "Techniques for User Agent Accessibility Guidelines 1.0" (the "Techniques document" from here on) [UAAG10-TECHS], provides suggestions and examples of how each checkpoint might be satisfied. It also includes references to other accessibility resources (such as platform-specific software accessibility guidelines) that provide additional information on how a user agent may satisfy each checkpoint. The techniques in the Techniques document are informative examples only, and other strategies may be used or required to satisfy the checkpoints. The Techniques document is expected to be updated more frequently than the current guidelines. Developers, W3C Working Groups, users, and others are encouraged to contribute techniques.

1.1 Relation to WAI accessibility guidelines

"User Agent Accessibility Guidelines 1.0" (UAAG 1.0) is part of a series of accessibility guidelines published by the Web Accessibility Initiative (WAI). The documents in this series reflect an accessibility model in which Web content authors, format designers, and software developers have roles in ensuring that users with disabilities have access to the Web. The accessibility-related interests of these stakeholders intersect and complement each other as follows:

The requirements of this document interact with those of the "Web Content Accessibility Guidelines 1.0" [WCAG10] in a number of ways:

Some requirements of this document take into account limitations of formats, authors, and designers. Formats generally do not enable authors to encode all of their knowledge in a way that a user agent can recognize 100%. A format may lack features required for accessibility. An author may not make use of the accessibility features of a format or may misuse a format (which can cause problems for user agents). A user agent designer may not implement a format specification correctly or completely.

Some of these limitations are taken into account as follows:

The Web Accessibility Initiative provides other resources and educational materials to promote Web accessibility. Resources include information about accessibility policies, links to translations of WAI materials into languages other than English, information about specialized user agents and other tools, accessibility training resources, and more.

1.2 Target user agents

This document was designed specifically to improve the accessibility of user agents with multimedia capabilities running in the following type of environment (typically that of a desktop computer):

This document is not designed so that user agents on other types of platforms (e.g., handheld devices, kiosks, etc.) will readily conform. This document does not forbid conformance by any user agent, but some requirements (e.g., implementation of certain application programming interfaces, or APIs) are not likely to be satisfied on environments other than the target environment. Future work by the UAWG may address the accessibility of user agents running on handheld devices, etc.

The target user agent is one designed for the general public to handle general-purpose content in ordinary operating conditions. Furthermore, it is expected that a conforming user agent will consist of more than one component that, together, satisfy the requirements of the document. For example, these components might include a Web browser, one or more media players, and documentation distributed with the software or available on the Web. These components may run on the user's computer or on a server. A conforming user agent may also include assistive technologies and applications provided by the operating environment.

This does not mean that every single component that makes up a conforming user agent has to satisfy every single requirement; some requirements may not be relevant for a particular component. For instance, if a component does not have a user interface, it would not be required to satisfy the user interface requirements. On the other hand, if a component used to satisfy the requirements of this document has a user interface, that user interface would be subject to the requirements of this document. Conformance addresses the composite user agent as a whole.

This document was designed to improve the accessibility of target user agents for users with one or more disabilities (including visual, hearing, physical, and cognitive) in two ways:

  1. through its own user interface, and
  2. through other internal facilities, including its ability to communicate with other technologies (especially assistive technologies).

Technologies not addressed directly by this document (e.g., those for braille rendering) will be essential to ensuring Web access for some users with disabilities. Note that the ability of conforming user agents to communicate well with assistive technologies will depend in part on the willingness of assistive technology developers to follow the same standards and conventions for communication.

This document allows a certain amount of flexibility in the features a user agent must support in order to conform. For example, some user agents may conform even though they do not support certain content types (such as video or audio) or input modalities (such as mouse or voice). See the section on conformance profiles for more information.

1.3 Known limitations of this document

People with (or without) disabilities access the Web with widely varying sets of capabilities, software, and hardware. Some users with disabilities:

This document does not include requirements to meet all known accessibility needs. Some known limitations of this document include the following:

Input modalities
This document only includes requirements for keyboard, pointing device, and voice input modalities. This document includes several checkpoints related to voice input as part of general input requirements (e.g., the checkpoints of guideline 7 and guideline 11) but does not otherwise address voice-based navigation or control.
Note: The UAWG intends to coordinate further work on the topics of voice input and synthesized speech rendering with groups in W3C's Voice Browser Activity.
Output modalities
This document does not include requirements for braille rendering. Some requirements are specific to graphical rendering and others specific to audio output or synthesized speech output. Speech rendering requirements are made by checkpoint 4.9 to checkpoint 4.13. Many of the requirements of this document are generic enough to apply to any output modalities, such as braille. User agents conform to this document by supporting some combination of graphical and audio/speech rendering output; see the section on Content type labels for more information.
Size and color of non-text content
This document includes some checkpoints to ensure that the user is able to control the size and color of visually rendered text content (checkpoints 4.1 and 4.3). This document does not in general address control of the size and color of visually rendered non-text content.
Note: Resizing capabilities may be required for conformance to other specifications (e.g., Scalable Vector Graphics [SVG]).
Background image interference
The requirement of checkpoint 3.1 to allow the user to turn off rendering of background images does not extend to multi-layered rendering.
User control of every user interface component
This document distinguishes user interface features that are part of the user agent user interface and those that are part of content. Some checkpoints (e.g., those in guideline 5) require user control or configuration of rendering or behavior that is driven by content. The document does not always make the same rendering or behavior requirements for the user agent user interface, even when those requirements make sense. User agents are required to follow software usability guidelines (see checkpoint 7.3), which are also expected to include requirements for user control over user interface behavior.
Note: It is more difficult for users to distinguish content from user interface when both are rendered as sound in one temporal dimension, than it is when both are rendered visually in two spatial dimensions. Developers of audio output or synthesized speech output user agents are therefore strongly encouraged to apply the requirements of this document to both content and user agent components.
Time parameters
This document includes requirements for control of some time parameters (including checkpoint 2.4, checkpoint 4.4, checkpoint 4.5, and checkpoint 4.9). The requirements are for time parameters that the user agent recognizes and controls. This document does not include requirements for control of time parameters managed on the server.
Intellectual property
This document does not address intellectual property issues that may arise as a result of these requirements.

Note: The User Agent Accessibility Guidelines Working Group may address these topics in a future version of the User Agent Accessibility Guidelines. Even though UAAG 1.0 does not address these topics, user agent developers are encouraged to consider them in their designs.

1.4 Relation to general software design guidelines and other specifications

Considerable effort has been made to ensure that the requirements of this document are compatible with other good software design practices. However, this document does not purport to be a complete guide to good software design. For instance, the general topic of user interface design for computer software exceeds the scope of this document, though some user interface requirements have been included because of their importance to accessibility. The Techniques document [UAAG10-TECHS] includes some references to general software design guidelines and platform-specific accessibility guidelines (see checkpoint 7.3). Involving people with disabilities in the design and testing of software will generally improve the accessibility of the software.

This document promotes conformance to other specifications as part of accessible design. Conformance to specifications makes it easier to design assistive technologies, and helps ensure that built-in accessibility functions are implemented.

This document also includes some requirements to implement an accessibility feature that may only be optional in another specification.

In rare cases, a requirement in UAAG 1.0 may conflict with a requirement in another specification. UAAG 1.0 does not include requirements for resolving this conflict, but the authors of this document anticipate that developers will consider accessibility implications when determining how to resolve the conflict.


Installation is an important aspect of both accessibility and general software usability. On platforms where a user can install a user agent, the installation (and update) procedures need to be accessible. Furthermore, the installation procedure should provide and install all components necessary to satisfy the requirements of this document, as the risk of failure increases with the number of components (e.g., plug-ins) to be installed.

This document does not include a checkpoint requiring that installation procedures be accessible. Since this document considers installation to be part of software usage, the different aspects of installation (user interface, documentation, operating environment conventions, etc.) are already covered by the complete set of checkpoints.

1.5 User control

This document emphasizes the goal of ensuring that users, including users with some disabilities, have control over their environment for accessing the Web. Key methods for achieving that goal include: optional self-pacing, configurability, device-independence, interoperability, direct support for both graphical and auditory output, and adherence to published conventions. Chapter 2 addresses these issues in detail.

This document also acknowledges the importance of author preferences and the proper implementation of specifications. However, this document includes requirements to override certain author preferences when the user would not otherwise be able to access that content.

Control of automatic behavior

Many of the requirements in this document give the user additional control over behavior that would otherwise occur automatically. For instance, there is a requirement to allow configuration to not open a viewport automatically ([#limit-viewports]) and one that requires user confirmation before submitting a form (checkpoint 5.5). This type of manual configuration option may be essential for some users with disabilities, since automatic behavior may be disorienting or interfere with navigation.


This document includes requirements for users with a variety of disabilities, in part because some users may have more than one disability. In some cases, it may appear that two requirements contradict each other. For instance, a user with a physical disability may prefer that the user agent offer more automatic behavior (to reduce demand for physical effort) than a user with a cognitive disorder (for whom automatic behavior may cause confusion). Many of the requirements in this document involve configuration as one way to ensure that a functionality designed to improve accessibility for one user does not interfere with accessibility for another. Also, since a default user agent setting may be useful for one user but interfere with accessibility for another, this document prefers configuration requirements over default setting requirements. Finally, there may be some cases where, for some content, a feature required by this document is ineffective or causes content to be less accessible, making it imperative that the user be able to turn off the feature.

To avoid the risk that users are overwhelmed by an abundance of configuration options, this document includes requirements that promote ease of configuration and documentation of accessibility features (see guideline 12).

Device independence, spatial independence, and temporal independence

Many requirements in this document promote independence on a variety of axes:

Additional benefits of accessible user agent design

In meeting the goals of users with disabilities, user agent developers will also to improve access to the Web for users in general. For example, users without disabilities:

Software that satisfies the requirements of this document is expected to be more flexible, manageable, extensible, and beneficial to all users. For example, a user agent architecture that allows programmatic access to content and the user interface will encourage software modularity and reuse, and will enable operation by scripting tools and automated test engines in addition to assistive technologies.