2002 Conference Proceedings

Go to previous article 
Go to next article 
Return to 2002 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

The W3C User Agent Working Group is developing guidelines to help developers of web technologies understand the needs of people with disabilities. The guidelines are based on the needs of people with disabilities to access web content and to provide examples of how to solve these problems through proven techniques as demonstrated in commercial 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. The document is currently in Candidate Recommendation stage of the W3C process. Candidtate recommendation period is a period for developers to implement the requirements of the User Agent Accessibility Guidelines [UAAG].

There are two other working groups developing accessibility guidelines in the W3C: Web Content Accessibility Guidelines [WCAG] and the Authoring Tools Accessibility Guidelines [ATAG]. The three guidelines working groups are part of the W3C Web Accessibility Initiative [WAI]. The purpose of WAI is to improve the accessibility of the web by developing accessibility guidelines, educating people on accessibility issues of the web and influencing the design of future web technologies to include accessibility features.

Process of Creating the Guidelines

As the guideline document currently includes 12 major sections that representing an important accessibility topic. Each topic has a set of checkpoints that describe specific accessibility requirement that support the accessibility topic defined by the guideline name. Each checkpoint has an associated priority that indicates the importance of implementing the checkpoint for people with disabilities to access web 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 members through the last call, candidate recommendation 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, techniques, implementation reports and test suite information 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 makes a decision to resolve the issue andthe working group members who disagreed with the chairs decision can 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 reviewers 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 12 major guidelines in the Candidate Recommendation Version of 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 a particular functionality, usually some type of pointer action (mouse) in Graphical User Interfaces (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 the keyboard. In GUI operating system, this means that functionality available through a pointing device must also be available through keyboard commands. UAAG also requires support for the standard 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 configuration 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 rendering.
In the early part of the web users had a lot of control over the style of how information was rendered to them and user control is also one of the original design premises of the web. The web was orginally 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 through a partciular medium. 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 as developers removed features which provided user control over rendering. This guideline is designed to make sure that the user has the final say over the style of rendering, including the rendering colors, font size and families used to render text on a graphical display.

Guideline 5. Ensure user control of user interface behavior
One of the biggest problems identified by the working group is the automation the author can include in a web resource that can confuse and disorient a user. Authors can include markup to automatically submit forms or open windows. For example a form maybe automatically submitted as soon as one of the form input controls is completed. In this case the user may be disoriented by the page disappearing and a new page being loaded without their explicit request through a form submit button. New windows being generated and receiving input focus is a common technique used by advertisers to attract a users attention to their product when they enter a unrelated web site. This problem is compounded for people with some types of disabilities, since they may not be provided with the orientation and command information to return to the original resource. UAAG has requirements to increase user control over how these windows are opened and focus is moved to them.

Guideline 6. Implement interoperable application programming 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 i a web environment, since full information about the web resource is available to the assistive technology developer.

Guideline 7. Observe operating environment conventions.
Some operating systems (i.e Microsoft Windows 95/98/Me/NT/2000/XP) allow the user to set global options that improve accessibility. Features typiclly include setting colors, font family and font sizes for system resources like menu bars and status lines. Other accessibility settings include system flags for turning on captioning features for people who cannot hear an audio resource. These features need to be inheirted by the user agent, when available, to reduce the the time and skill needed by the user to configure the user agent to their own accessibility needs. The user agent also needs to be compatible with built-in accessibility tools like mouse keys and sticky keys.

Guideline 8. Implementspecifications that benefit accessibility.
Many W3C 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 9. 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 handlers 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 10: 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 9 can be a very powerful tool to users with disabilities for traversing web resources efficiently. This guideline 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.

Guideline 11. 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 on a cmapus, 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 12. Provide accessible user agent 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 new requirements have been reviewed in during a second and third last call during the last half of 2000 and the first half of 2001.

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 define 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 or do not 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.

Candidate Recommendation

The UAAG is currently in the Candidate Recommendation(CR) stage of the W3C process. During CR the user agent working group is working with developers to help them implement the requirements of UAAG. To help developers understand and implement the guidelines the User Agent working group is reviewing current products for implementation experience [IMPLEMENT] and developing test suites to help developers test to see if they have meet the requirements of UAAG. Ideally at the end of the CR period each requirment in UAAG will have at least two independent implementations for each requirement. The next stage after CR is proposed recommendation which allows the W3C member companies to validate the guidelines as meeting the technical and implementation requirements of W3C recommendations.

Techniques Document

Each checkpoint in the guidelines has a list of associated techniques or examples on how to satisfy the requirements of the checkpoint. The User Agent Techniques Document [TECH] is designed to provide developers with a list of potential solutions to meet the requirements of a checkpoint. The techniques document is a separate but crossed linked document to the guidelines dcoument. The cross linking allows developers to easily move between the UAAG requirements document and ideas on who to meet the requirements.

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/

[IMPLEMENT] User Agent Evaluation Report for Candidate Recommendation http://www.w3.org/WAI/UA/implementation/report-cr2.html

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

[UAAG] User Agent Accessibility Guidelines http://www.w3.org/TR/UAAG10/

[UAWG] User Agent Working Group http://www.w3.org/WAI/UA/

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

[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 2002 Table of Contents 
Return to Table of Proceedings


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