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. 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.
Note: The Web Accessibility Initiative is developing new versions of both the Web Content Accessibility Guidelines and the Authoring Tool Accessibility Guidelines. UAAG 1.0 refers only to the WCAG 1.0 and ATAG 1.0 Recommendations, which will remain available and unchanged.
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 target user agent is one designed for the general public to handle general-purpose content in ordinary operating conditions.
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.
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.
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, it would not be required to satisfy the user interface requirements. On the other hand, if a component 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.
To satisfy the requirements of this document, developers are encouraged to adopt 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.
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.
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 (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 in 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 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 (user interface, documentation, operating environment conventions, etc.) are already covered by the complete set of checkpoints.
Some of the requirements of this document have security implications: communication through APIs, allowing programmatic read and write access to content and user interface control, etc. 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].
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.
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.
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 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).
Many requirements in this document promote different kinds of independence:
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.