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.