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:

• This introduction, which provides context for understanding the requirements listed in section 2.
• Section 2 explains twelve general principles of accessible design, called "guidelines". Each guideline consists of a list of requirements, called "checkpoints", which must be satisfied in order to conform to this document.
• Section 3 explains how to make claims that software components satisfy the requirements of section 2.
• An appendix offers a summary of this document's principal goals and structure [UAAG10-SUMMARY].
• A second appendix lists all the checkpoints for convenient reference (e.g., as a tool for developers to evaluate software for conformance) [UAAG10-CHECKLIST].

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:

• Designers of formats (e.g., HTML, XHTML, XML, SVG, SMIL, MathML, etc.) and protocols (e.g., HTTP) create specifications that allow communication on the Web. Format designers include features in these specifications that authors should use to create accessible content and that user agents should support through an accessible user interface. The "XML Accessibility Guidelines (XAG)" [XAG10] explains the responsibilities of XML format designers; many XAG requirements make sense for non-XML formats as well.
• Authors make use of the accessibility features of different format specifications, use markup appropriately, write in clear and simple language, organize a Web site consistently, etc. The "Web Content Accessibility Guidelines 1.0" [WCAG10] explains the responsibilities of authors in meeting the needs of users with disabilities. The "Web Content Accessibility Guidelines (WCAG) 1.0" is considered the reference for what defines accessible Web content. The "Authoring Tool Accessibility Guidelines 1.0" [ATAG10] explains the responsibilities of authoring tool developers. An accessible authoring tool facilitates the creation of accessible Web content and may be operated by users with disabilities.
• User agent developers design software that meets the needs of users with disabilities through conformance to other specifications, an accessible user interface, accessible documentation, and communication with other software (notably assistive technologies).

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

• UAAG 1.0 checkpoint 8.1 requires implementation of the accessibility features of specifications. Features are those identified as such and those that satisfy all of the requirements of WCAG 1.0 [WCAG10].
• UAAG 1.0 checkpoint 12.1 requires conformance to WCAG 1.0 for user agent documentation.
• UAAG 1.0 also incorporates some terms and concepts from WCAG 1.0, a consequence of fact that the documents were designed to complement one another.

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:

• UAAG 1.0 includes requirements to satisfy the expectations set by WCAG 1.0 "until user agent" clauses. These clauses make additional requirements of authors in order to compensate for some limitations of deployed user agents.
• UAAG 1.0 includes several repair requirements (e.g., checkpoints checkpoint 2.7 and checkpoint 2.10) for cases where content does not conform to WCAG 1.0. Furthermore, this document includes some requirements to address certain widespread authoring practices that are discouraged because they may cause accessibility or usability problems (e.g., some uses of HTML frames).
• Except for the indicated repair checkpoints, UAAG 1.0 only requires user agents to handle what may be recognized through protocols and formats. For example, user agents are not expected to recognize that the author has used "clear and simple" language to express ideas (WCAG 1.0, checkpoint 14.1). Please see the section on checkpoint applicability for more information about what the user agent is expected to recognize.

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):

• The operating environment includes a keyboard (or keyboard equivalent);
• Assistive technologies may be used in the operating environment and may communicate with the conforming user agent;

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:

• May not be able to see, hear, move, speak, or may not be able to process some types of information easily or at all.
• May have difficulty reading or perceiving some types of information.
• May not have or be able to use a keyboard or pointing device.

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

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.

Configurability

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:

• Input and output device independence. This document includes some requirements to promote device-independence natively, and requirements for interoperability with assistive technologies that provide complementary input and output functionalities.
• Spatial independence. Some users may not navigate effectively in two-dimensional visual space (e.g., users who do not use a pointing device) or may be constrained to one temporal dimension (e.g., users of audio-only output).
• Temporal independence. Some users (e.g., users with a physical or cognitive disability) may not be able to interact with content that changes over time, or interaction with content that is time-sensitive.

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:

• may have a text-only screen, a small screen, or a slow Internet connection (e.g., via a mobile phone browser). These users are likely to benefit from the same features that provide access to people with low vision or blindness.
• may be in a situation where their eyes, ears, or hands are busy or interfered with (e.g., driving to work, working in a noisy environment, etc.). These users are likely to benefit from the same features that provide access to people who cannot use a mouse or keyboard due to a visual, hearing, or physical disability.
• may not understand fluently the natural language of spoken content. These users are likely to benefit from the same visual rendering of text equivalents that make spoken language accessible to people with a hearing disability.

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.