2001 Conference Proceedings

Go to previous article 
Go to next article 
Return to 2001 Table of Contents


W3C User Agent Accessibility Guidelines

Jon Gunderson, Ph.D.
Chair, W3C User Agent Working Group
University of Illinois at Urbana/Champaign
College of Applied Life Students
Rehabilitation Education Center
1207 S.Oak Street, Champaign, IL 61820

Abstract

The W3C User Agent Accessibility Guidelines [UAAG] are part of the W3C Web Accessibility Imitative [WAI]. UAAG is designed to provide information to developers of web based user agents (browsers) on requirements for designing products designed to render WWW resources to be more directly accessible to people with disabilities and compatible with assistive technologies used by people with disabilities. UAAG is developed through the consensus-based process of the W3C [W3C], which includes participants from developers, researchers, service providers, disability organizations, and people with disabilities. The guidelines are important in defining a set of minimum requirements for developers to claim that their product is accessible to people with disabilities directly or through assistive technologies.

Introduction

A conference was held in November of 1997 at IBM in Austin Texas. Representatives of industry, disability researchers, assistive technology experts, disability organizations and people with disabilities met to discuss how to improve the accessibility of the WWW by people with disabilities. Three working groups were chartered at that meeting: Web Content Accessibility Guidelines [WCAG], Authoring Tools Accessibility Guidelines [ATAG] and User Agent Accessibility Guidelines [UAAG]. Collectively these groups were the initial working groups of the Web Accessibility Initiative [WAI] of the W3C. The User Agent group was given the responsibility to develop a set of guidelines that would help developers of technologies that render WWW based resources to be more accessible to people with disabilities. The working group has been working hard since the initial meeting to develop a comprehensive set of guidelines that can be used to improve the accessibility of user agent technology based on the needs of people with disabilities and to provide examples of how to solve these problems through proven techniques available in various products. The working group includes participation of developers of mainstream user agent technologies, assistive technology developers, people with disabilities, disability researchers and experts in the use of assistive technologies.

Process of Creating the Guidelines

As the guideline document currently includes 10 major sections that representing an important accessibility topic. Each topic has a set of checkpoints that describe specific requirement to support the accessibility topic of the guideline. Each checkpoint has an associated priority that indicates the importance of implementing the checkpoint for people with disabilities to access content. The W3C process is based on consensus. The group is required to reach a consensus on the purpose and requirements of each guideline and checkpoint included in the document. The document is also required to be periodically be reviewed by the public and from W3C member companies through the last call and proposed recommendation process [W3C]. Comments received during these periods must be considered by the working group for possible changes to the document. While most working groups with in the W3C are member private and therefore confidential the User Agent working group is open for non-W3C members to participate as invited experts. Participation includes helping to develop guideline and techniques through attending working group meetings, and exchange of comments and proposals on the e-mail list. The process of consensus does not require unanimity within the working group, but for most of the issues the group reached this level of consensus. In the small number of issues where consensus could not be reached, the chair made a decision to resolve the issue and working group members who disagreed with the chairs decision could register a minority opinion. Minority opinions are part of the information that is carried with the document through last call and proposed recommendation periods for review and consideration by the W3C director, public reviewrs and W3C member companies in submitting their comments to the working group. The process is very public and the working group has tried very hard to solicit comments from disability groups and developers.

Major Principles

There are 10 major guidelines included in UAAG. Each of the 10 guidelines is designed to provide developers with a general concept that is important for accessibility. Each guideline has a set of checkpoints that highlights a particular accessibility issue associated with that guideline. Please visit the user agent working group web site to find the latest information on the guidelines and techniques document (http://www.w3.org/wai/ua).

Guideline 1: Support input and output device-independence
Device independence is important to enable people with disabilities to use a wide variety of input and output technologies to access and interact with web content. Many mainstream user agent technologies provide only one way to access functionality, typically some type of pointer action (mouse) in GUI based operating systems. This makes it impossible or very difficult for users who cannot use pointer technology to access all the functionalities the user agent provides. To help insure that the user agent is accessible to a wider range of people, UAAG requires that all functionalities be available through all supported input devices. In GUI operating system, this means that functionality available through a pointing device must also be available through keyboard commands. The only exception is character entry, which is only required through the keyboard. UAAG does specifically require support for the keyboard API, since the keyboard API is currently the primary way some types of assistive technologies can map user agent functionalities to alternative input devices.

Guideline 2: Ensure user access to all content
This guideline requires that people with disabilities have access to all the information included in a WWW resource . One of the major requirements in this section is for users to have access to all the alternatives available for a particular element. Examples of equivalents include text descriptions of images or captioning information in videos. It is also important as WWW resources become more dynamic that users have access to content in a time independent manner. Multimedia presentations often dynamically generate links to other types of content that require users need to respond in a certain period of time. People with many types of disabilities may not be able to respond during the author's defined period of time. Users need the capability to extend the response time based on their capabilities. Users with advanced knowledge of web markup languages may also need to view the actual source markup of a WWW resource to access the information contained in a resources that do not conform to accessibility standards.

Guideline 3: Allow the user to configure the user agent not to render some content that may reduce accessibility
Some types of web content may be confusing, disorient or increase the likely hood of a seizure for people with disabilities. The user needs to be able control the rendering of elements that can lead to these types of problems, and this includes elements used for rendering images, animations, blinking text, videos, visual affects due to scripting, and other automatic content changes specified by the author. Basic control allows the user to turn on and off the rendering of content, but often the user can benefit from more extensive control. For example, users may be confused if they see all the images in a resource at the same time, but if they can individually control the rendering of each individual image in the resource they can minimize or eliminate the confusion associated with the visual overload of having all the images available after the resource is loaded.

Guideline 4: Ensure user control of styles
When the web was young (1994) users had a lot of control over the style of how information was rendered to them and was also one of the original premises of the web. The web is designed to be a place for people to exchange information from a wide range of computer systems and software, and therefore authors could not predict the resources of a particular system for rendering their content. Early versions of HTML did not provide authors much control over how their information was rendered to other people. As the use of the web increased and the variety of web technologies available to render web content narrowed to a few major technologies, developers provided and authors demanded more control over the style of how information is rendered. Developers began supporting markup to allow authors to control the color, font size, font type, font style and the positioning of information rendered. The W3C responded by extending HTML and developing CSS to try to standardize the way an author added style to their documents and specify expected behaviors of user agent technology. During these changes users began to loose control over how information was rendered to them. This guideline is designed to make sure that the user has the final say over the style of rendering, including rendering colors, font size and families used to render text on a graphical display.

Guideline 5: Observe system conventions and standard interfaces
The guidelines require that the user agent provide accessible renderings of information in the input and output mediums they directly support for their user interface. For many mainstream programs this typically is a keyboard, mouse and graphical display. For people with disabilities that cannot either use these input devices or cannot see the graphical display the user agent is required to support APIs that allow assistive technologies to emulate input commands and capture information sent to the graphical display. UAAG goes a step beyond traditional accessibility guidelines by also requiring that author supplied information also be available through the W3C Document Object Module [DOM]. The DOM preserves information about the relationships between different types of elements in a resource. This information allows alternative renderings in speech or Braille to be highly optimized to the needs of the user, since full information about the web resource is available to the assistive technology developer.

Guideline 6: Implement specifications that promote accessibility
Many specifications contain features that support or can be used to improve accessibility. This is one of the reasons the ALT and LONGDESC attribute were added to the HTML IMG element. This requirement states to developers to use technologies that support accessibility in their products and in general support technologies that are based on open standards and interoperability. Interoperability and open standards will more likely support accessibility, since users typically have more options for rendering information and rendering technologies are available on a larger number of operating systems. Open standards typically allow for public participation in the development of the specification, including accessibility issues.

Guideline 7: Provide navigation mechanisms
Navigation is one of the most difficult areas of the working group to develop checkpoints. There is unanimity within the UA working group that navigation and orientation are critical factors for a user to efficiently move through the content of a web resource. In the end the group reached consensus on more general navigational checkpoints that are based on access to active elements of a document (links, form controls and event handles for scripts) and access to important elements of the document. The important elements of a particular resource ideally are identified by the author through the proper use of structural elements with in the markup language. For example, authors can use the HTML header elements (H1-H6) to indicate section titles within a document. In real life many authors do not correctly markup the structure of their document. In this case the user agent can try to identify the important elements by using style information or other algorithms that they determine provide a useful navigational map of the resource to the user.

Guideline 8: Orient the user
Orientation is very important for users to understand the relationships and the purpose of certain types of content. The orientation section specifies that users have access to information about table cell relationships, the identification and characteristics of links, and access to information related to selection, focus and highlighting of elements. The orientation section also includes two checkpoints on creating and configuring outline views of a resource. Outline views allow users to quickly summarize the important topics of a resource. The outline view when combined with the structured navigation specified in guideline 7 can be a very powerful tool to users with disabilities for traversing web resources efficiently.

Guideline 8 also specifies that users need to be able to view the results of navigation commands in the current viewport (graphical window) and be able to determine the current position of the information they are viewing with in the resource. For example in a graphical user interface the user may page down several pages to read information in a resource. The user then activates a command to move the focus to the next active element and the next active element (i.e. a link or form control) is not in their current window. The window must then scroll to show the active element that now has received focus. This allows the user to stay oriented to the results of their commands. Another issue addressed in this section is user notification and confirmation of automatic form submissions. Many authors design web resources to trigger form submissions automatically without an explicit user command and this can be disorienting to many users with disabilities. The user needs to be able to configure the user agent to alert them to confirm any form submission before the sent to the server.

Guideline 9: Allow configuration and customization
Users with disabilities can often benefit from being able to customize the user interface through remapping of keyboard commands. Keys to activate commands can be moved closer together on the keyboard for people with limited ranges of motion and keyboard conflicts with assistive technologies can be resolved. A checkpoint in this guideline allows the user to assign frequently used commands to a single keystroke and another checkpoint allows the user to rearrange the graphical position and number of controls on toolbars. Users also benefit from being able to easily save and load their configuration information. The portability of configurations between computer systems is very important, especially as computer systems become more a part of public services. For example, in an educational setting a user with a disability may need to use computer systems in many different computer labs, it makes it much easier for the user to load their preferences from a disk or other resource, than to constantly reconfigure computer system through the user interface.

Guideline 10: Provide accessible product documentation and help
Documentation is very important for highlighting the accessibility features of a user agent and guaranteeing that at least one form of the documentation be provided in an accessible form. UAAG requires that at least one form of the documentation comply with WCAG 1.0 {WCAG] at the double-A level and the features that support accessibility be included in the documentation. Accessibility information should have its own section in the document to make it easier for users with disabilities to understand what features are available to improve the usability of the tool to them.

Conforming to the Guidelines

The conformance section of the guidelines was one of the most difficult areas of the document for the working group to resolve. There are three levels of conformance a developer can claim to the guidelines: single A, double A and triple A. These are the same levels as defined for the WAI web content [WCAG] and authoring tools [ATAG] guidelines. The single, double and triple A levels of conformance correspond to satisfying all the priority 1, priority 2 and priority 3 level checkpoints. Priority 1 checkpoints are defined as features that are needed for accessibility or it will be impossible for some users with disabilities to use the product. Priority 2 checkpoint features are need or it will be difficult for some users to access content and priority 3 checkpoints are features that will make it easier for users with disabilities to access content. As each checkpoint was developed the group needed to reach consensus on the priority of the checkpoint.

The second issue is minimum requirements. During the spring of 2000 the group submitted the guidelines as a proposed recommendation (the last stage before the document becomes a recommendation) and many developers commented on the document. One of the main comments was how does a developer know that they have satisfied the requirements of a checkpoint. Many of the checkpoints identified problems that had a wide range of potential solutions and these were outlined in the companion techniques document [TECH]. To address the minimum requirement issue the group chose to clarify the minimum requirements for each checkpoint identified by the group as having vague requirements for conformance. The group spent most of the summer and fall of 2000 defining the minimum requirements. These are being reviewed in a second last call and proposed recommendation period in the fall and winter of 2000.

The third component for conformance was applicability. Some of the checkpoints dealt with technologies or features that a particular user agent did not support. In this case the developer making a conformance claim must document which of checkpoints they felt did not apply to their product. To assist developers and consumers in simplifying these claims the working group choose to make up predetermined sub groups of checkpoints for particular media types like text, graphical, video, audio and speech. In this case developers can use a label instead of specific checkpoints to indicate the groups of checkpoints that apply to their product. The labels will make it easier for consumers to understand what types of media the user agent is claiming conformance for accessibility.

More Information

The user agent working groups activities are all public. The current working drafts of the guidelines and techniques documents, minutes from meetings, working group participant information and the e-mail list archives can all be accessed through the working group's home page at http://www.w3.org/wai/ua 

Acknowledgments

I would like to acknowledge the support of the user agent working Ian Jacobs (W3C staff contact and editor), group members, other W3C WAI staff, W3C member companies, disability organizations, and the United States and other governments that support the W3C Web Accessibility Initiative for their support in developing and implementing the UAAG.

References

[ATAG] Authoring Tool Accessibility Guidelines 1.0 http://www.w3.org/TR/2000/REC-ATAG10-20000203/

[DOM] Document Object Model (DOM) Level 1 Specification http://www.w3.org/TR/REC-DOM-Level-1/

[TECH] Techniques for User Agent Accessibility Guidelines 1.0 http://www.w3.org/WAI/UA/WD-UAAG10-TECHS-20000929/

[UAAG] User Agent Accessibility Guidelines Working Group http://www.w3.org/WAI/UA/

[W3C] World Wide Web Consortium Process Document http://www.w3.org/Consortium/Process/Process-19991101/

[WCAG] Web Content Accessibility Guidelines 1.0 http://www.w3.org/TR/WCAG10/

[WAI] Web Accessibility Initiative (WAI) http://www.w3.org/WAI/


Go to previous article 
Go to next article 
Return to 2001 Table of Contents 
Return to Table of Proceedings


Reprinted with author(s) permission. Author(s) retain copyright.