User Agent Accessibility Guidelines 1.0

1. Introduction

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

This introduction provides context for understanding the requirements listed in section 2.
Section 2 explains 12 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. Note: Section 2 is numbered differently than the other sections; it consists of a list of guidelines. In section 2, "checkpoint 1.2" refers to the second checkpoint of the first guideline. "Section 1.2" refers to a subsection of the Introduction.
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 UAWG expects to update the Techniques document 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, and XForms) 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, and organize a Web site consistently. 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 within UAAG 1.0 to be the reference set of requirements to make Web content accessible. 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. For example, formats generally do not enable authors to encode all of their knowledge in a way that a user agent can fully recognize. 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). 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.

Note: The Web Accessibility Initiative is developing new versions of both the Web Content Accessibility Guidelines and the Authoring Tool Accessibility Guidelines. The User Agent Accessibility Guidelines Working Group expects to follow the progress of those documents. UAAG 1.0 refers only to the WCAG 1.0 and ATAG 1.0 Recommendations, which will remain available and unchanged.

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

The target user agent is one designed for the general public to handle general-purpose content in ordinary operating conditions.

This document does not forbid conformance by other types of user agents, but some requirements (e.g., implementation of certain application programming interfaces, or APIs) are not likely to be satisfied in environments (e.g., handheld devices or kiosks) other than the target environment. Future work by the UAWG may address the accessibility of user agents running on handheld devices, for example.

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.

1.2.1 Composition of conforming user agents

In general, a conforming user agent will consist of several coordinated components, such as a Web browser, a multimedia player, several plug-ins, features or applications provided by the operating environment, 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. The current document places no restrictions on the type or number of components used for conformance.

This does not mean that every component that one has chosen as part of the 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, the user interface requirements would not be relevant. On the other hand, if a component has a user interface, the user interface requirements are relevant. Conformance addresses the composite user agent as a whole.

1.2.2 Use of operating environment features

The UAWG encourages developers to satisfy the requirements of this document by adopting operating environment conventions and features that benefit accessibility. When an operating environment feature (e.g., the operating system's audio control panel, including its user interface) is adopted to satisfy the requirements of this document, it is part of the user agent.

See additional information on conformance of user agents running in multiple operating environments.

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, or speak.
May not be able to perceive, read, or process some types of information easily or at all.
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 and Multimodal Interaction 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 a variety of output modalities, including 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 (e.g., images).; Note: A user agent may implement resizing functionalities as part of 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 over rendering and behavior that is driven by content only. This document does not always explicitly require the same control over features of the user agent user interface. Nevertheless, this document (see checkpoint 7.3) does require user agents to follow software usability guidelines. The UAWG expects such usability guidelines 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. Thus, the UAWG encourages developers of user agents that include audio output or synthesized speech output to apply the requirements of this document to both content and user agent components.
Time parameters: This document includes requirements (see checkpoints 2.4, 4.4, 4.5, and 4.9) for control of some time parameters. 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.
Digital rights management: The User Agent Accessibility Guidelines Working Group recognizes that further work is necessary in the area of digital rights management as it relates to accessibility. Digital rights management refers to methods of describing and perhaps enforcing intellectual property associated with Web resources.

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

1.4 Relation to general software design guidelines and other specifications

One the goals of the authors of this document is to ensure that the requirements 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 (in particular, 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 the implementation of built-in accessibility functions.

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 define a process for resolving such conflicts. The authors of this document anticipate that developers will consider accessibility implications in determining how to resolve them.

1.4.1 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, since the risk of installation 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 (e.g., user interface, documentation, and operating environment conventions) are already covered by the complete set of checkpoints.

1.5 Security considerations

Some of the requirements of this document may have security implications, such as communication through APIs, and allowing programmatic read and write access to content and user interface control. This document assumes that features required by this document will be built on top of an underlying security architecture. Consequently, unless permitted explicitly in a checkpoint (as in checkpoint 6.5), this document grants no conformance exemptions based on security issues.

Developers should design user agents that enable communication with trusted assistive technologies. Sensitive information that the user agent can access through the user agent's user interface should also be available to assistive technologies through secure means. For instance, if the user types a password in the user agent user interface, do not communicate substitute characters (such as asterisks) through an API, but rather the real password, properly encrypted.

Note also that appropriate user agent behavior with respect to security may depend on the user's context. For instance, hiding typed passwords with asterisks is much less important for someone alone in a room than for someone in a crowded room. Similarly, while unencrypted passwords rendered as synthesized speech should not be broadcast in a crowded room, they may pose no security risk if the user is wearing an earphone.

For information related to security, refer to "XML-Signature Syntax and Processing" [XMLDSIG] and "XML Encryption Syntax and Processing" [XMLENC].

1.6 User control

This document emphasizes the goal of ensuring that users, including users with 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.

1.6.1 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 (checkpoint 5.3) 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.

1.6.2 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 disability (for whom automatic behavior may cause confusion). Thus, 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 to requirements for default settings. 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 overwhelming users with an abundance of configuration options, this document includes requirements that promote ease of configuration and documentation of accessibility features (see guideline 12).

1.6.3 Device independence, spatial independence, and temporal independence

Many requirements in this document promote different kinds of independence:

Input and output device independence. This document includes some requirements to promote device-independence natively, as well as 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.

1.6.4 Additional benefits of accessible user agent design

In meeting the goals of users with disabilities, user agent developers will also 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 or working in a noisy environment). 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.

The UAWG expects that software which satisfies the requirements of this document will 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.