Go to previous article
Go to next article
Return to 2002 Table of Contents
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
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.
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.
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.
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.
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.
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.
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.
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
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.
[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