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.
"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. These stakeholders intersect and complement each other as follows:
This document explains the responsibilities of user agents in meeting the needs of users with disabilities. The requirements of this document interact with those of the "Web Content Accessibility Guidelines 1.0" [WCAG10] in a number of ways:
Formats, authors, and designers all have limitations. 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 requirements of this document take these limitations into account.
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.
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 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. It is expected that a conforming user agent will consist of more than one component. 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.
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:
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 for more information.
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:
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.
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.
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. 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.
Many users without disabilities are likely to benefit from the requirements developed to benefit users with disabilities. 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.
A number of themes run through the guidelines in this document. The following in particular are worth noting before you read the guidelines.
The user must have control over the rendering and behavior of content and the user interface. For instance, many of the requirements in this document give the user manual control over behavior that would otherwise occur automatically. This document strikes a balance between honoring author preferences and ensuring that the user can create an accessible environment.
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.
Many requirements in this document promote independence on a variety of axes:
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.