- From: Jon Gunderson <jongund@ux1.cso.uiuc.edu>
- Date: Tue, 04 Jan 2000 10:55:36 -0600
- To: ij@w3.org
- Cc: w3c-wai-ua@w3.org
My comments are listed under <delete>, <add>, <comment>:
User Agent Responsibilities
28 December 1999
This version:
http://www.w3.org/WAI/UA/1999/12/ua-resp-19991228
Editor
Ian Jacobs, W3C
Copyright © 1999 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C
liability, trademark, document use and software licensing rules
apply.
Abstract
<delete>
This document examines User Agent Guidelines Working Group
rationale for establishing which user agent
functionalities must be supported natively by general purpose user
agents and which are expected to be supported
by assistive technologies.
</delete>
<add>
This document examines User Agent Guidelines Working Group rationale for
establishing the native accessibility features of a user agent must provide
to access to the user agents functionalities and the web content it
recognizes. It addition to the built-in accessinbility the user agent must
also support assistive technoloiges that provide alternative user
interfaces to user agent functionalities and/or alternative rednerings of
web content.
</add>
Status of this Document
This document does not represent consensus of the User Agent
Accessibility Guidelines Working Group. As of the
date at the top of the document, it only represents the musings of
Ian Jacobs, who hopes it will serve as a support
document for the User Agent Accessibility Guidelines as they
advance on the Recommendation track.
<comment>
I assume that if the group wishes to include this document or a revised
version of the document that this would be replaced with some statement of
group consensus.
</commment>
Table of Contents
Introduction
What is a User Agent?
What is an Assistive Technology?
What functionalities must be provided by a general-purpose UA?
Review of specific requirements
Introduction
The User Agent Accessibility Guidelines include two types of
requirements for general purpose user agents:
<delete> 1.Requirements for native implementation of some
functionalities (i.e., the user agent implements them without requiring
additional software other than the operating system).
</delete>
<add>
1.Requirements for native implementation of accessibility features to user
agent functionailities (i.e., the user agent implements them without
requiring additional software other than the operating system).
</add>
2.Communication through Application Programming Interfaces (APIs)
<add>for compatibility with assistive technologies that provide alternative
user interfaces to specific disabilities</add>.
The Guidelines require user agents to allow read and write access to both
content and user interface controls.
<add>
The first set of requirements states that user agent needs to support
built-in accessibility for the input and output devices it supports For
graphical user agents in GUI environment this means they need to support
the accessible rendering of web content through the graphical display and
support both the keyboard and pointing device to access the functionalities
of the user interface and with "active" web content like links, controls,
scripts, and etc... Examples of accessible rendering through a graphical
medium includes allowing the user to control the rendering colors, font
size, font face and be able to access alternative content (see guideline
for complete requirements). The user must be able to control what part of
the content is rendered in a particular view, typically one way to do this
is with standard scroll bar controls and other keyboard/pointer based
commands that change the current view of the content. A voice browser
would have similar requirements, but it must satisfy the checkpoints using
speech. In this case the voice browser must provide a means to "scroll"
through the web content and allow the user to identify elements through
speech. FOr example speaking the word "header" before the content of a
header element is spoken or the header information of a table cell before
the contents of a table cell is spoken.
The second set of requirements provides a means for an assistive technology
to provide alternative means to access the functionalities of the user
agent and alternative renderings of web content that are useful to specific
types of disabilities. For example a graphical rendering of content is not
useful to someone who is blind, but an assistive technology could offer an
alternative rendering of the information through speech or Braille.
</add>
<delete>
The second set of requirements allows assistive technologies (ATs)
to offer missing functionalities not offered
natively. Since the Guidelines require that ATs have access to
both content and UI controls, in theory,
general-purpose user agents have to implement natively few
functionalities related to accessibility since ATs can
fill in the gaps. They might even do a better job since developers
of specialized tools know their target audience
well.
</delete>
<delete>
The Working Group has decided that general-purpose user agents
must implement some important functionalities
natively rather than relying on Assistive Technologies to shoulder
the load. One important reason for this decision
is that some users do not have access to or cannot afford
specialized browsers, so general-purpose user agents
must themselves be accessible.
</delete>
The working group decided that general purpose user agents must implement
naive accessibility for the rendering mediums and input devices that the
user agent supports. They must also allow their functionalities and the
content they are rendering to be accessed by assistive technologies that
can provide alternative ways to access functionalities and renderings of
the web content.
This document explains which requirements the User Agent
Guidelines Working Group has chosen for general
purpose user agents to implement natively and why.
What is a User Agent?
A user agent is a set of modules that retrieves Web resources,
renders them, allows control of those processes,
and communicates with other software. For instance, a graphical
desktop browser might consist of:
A parser and a tree processing engine
One or more rendering engines that, given a tree and style
parameters, creates rendering structures.
A user interface for providing access to content. This includes:
Viewports
Navigation and search mechanisms, which allow the user
to access content other than sequentially.
Orientation mechanisms such as proportional scroll bars,
highlighting of viewports, selection and focus,
etc.
A user interface for configuring the browser, including
parameters of the rendering engines(s), processing
information such as natural language preferences, and the
user interface itself (e.g., position of buttons in the
GUI).
A user interface for facilitating browsing (history
mechanism, bookmark mechanism, etc.)
Other user interface features (e.g., refresh the screen,
reload the document, send to the printer, etc.)
Interpreters for scripting languages.
APIs for communication with plug-ins.
Interfaces (e.g., for HTTP, for DOM, for file i/o including
document loading and printing, communication with
the operating system, etc.)
Note that there are areas where content and user interface mingle,
including:
Form controls
Links and their styling
Keyboard and other input configurations provided by the author
Adoption of markup languages for implementation of UI
controls (as is done, e.g., by IE using HTML and as
is done by Mozilla by using XML and the DOM for UI controls).
For simplicity, I will consider for now that the UI refers to the
UA's components, not those contributed by Web
content.
What is an assistive technology?
An assistive technology is a user agent that (1) relies on another
user agent to provide some services and (2)
provides services beyond those offered by the "host user agent" to
meet the requirements of a target audience.
Additional services might include:
Read access to the document tree would allow application of
different rendering engines. (e.g., speech
output)
Write access to the document tree would allow completion of
forms through, say, voice input
Read access to the UI would allow an assistive technology to
know which viewport the user has selected,
user agent configuration settings, etc.
Write access to the UI would allow users to navigate
viewports (i.e., change the current viewport) through
speech input.
Content transformation tools
Additional navigation mechanisms
Additional orientation mechanisms
An assistive technology may not parse document source, for
example, but probably has to include tree processing
capabilities in order to offer additional functionalities.
What functionalities must be provided by a general-purpose UA?
The following sections describe some of the factors that have
affected the decision about which functionalities
should be supported natively by general purpose user agents.
Existing practice
<delete>
Some general-purpose user agents already provide useful
functionalities such as allowing users to navigate links
through the keyboard. Assistive technologies read the focus and
speak or render as braille the link text. One might
argue that links are so fundamental to browsing the Web that it
makes sense to require navigation of these links to
be a native functionality, I believe that in part the current
requirement is a perpetuation of existing practice. Lynx
offers direct access to links by number, not just sequential
access, and this has shown itself to be a useful
time-saving functionality.
</delete>
<add>
The acessibility of current general-purpose user agents is dependent on an
number of factors, including the desire of developers to try to be
compatible with different types of assistive technology. Keyboard support
is currently one factor in determining the accessibility of a user agent.
Keyboard support allows users who cannot use the pointing device to access
the functionaliites of a user agent and to interact with "active" web
content. The keyboard is currently the main means for alternative input
technologies like voice recognition, morse-code, specialized keyboards and
other input technologies not directly supported by the user agent to have a
clear way to map the user actions required by the assistive technology to
the functionalities of the user agent. This is not always the best means,
but it is currently the only on available.
The rendering of graphical content using particular operating system APIs
is also another way to allow assistive technologies to capture web content
information as it is drawn on the display. This type of technology is used
extensively by screen readers to "see" what is being displayed in a
graphical view. The main problem with this approach since this is that the
web content context is lost and related information is often broken up
because it is not completely rendered in the current graphical view. The
content of a header element is now some text with a particular font. A
table cell is some text that is maybe or maybe not surrounded by some
lines. Only part of a paragraph is "seen" by the AT since the paragrah was
not completly rendered ont he graphical view. The relationships encoded in
the orginal elements are lost to the assistive technology and therefore
cannot be provided in the alternative rendering to the person with a
disability. There are certainly techniques that have been found useful for
making the rendering of web content somewhat more accessible to assistive
technology, but the techniques are very idiosyncratic and plateform
dependent and often fail to meet the desired goal of improving the ease of
access to web content by people with disabilities.
</add>
The DOM
<delete>
The existence of a platform- and programming-language independent
way to access content means that it's more
understandable to ask AT developers to provide some
functionalities. Note, however, that the lack of a standard
for exposing the DOM may hinder adoption. Also, since assistive
technology products are usually designed to
work with other software than user agents, requiring them to
implement a UA-specific interface may be considered
burdensome. Finally, there is not yet a platform-independent API
for accessing user interface controls.
</delete>
<add>
The existence of a platform- and programming-language independent
way to access web content means that AT developers can provide an improved
alternative renderings of web content by using the information orginally
provided by the web content author. The main problem with this apporach
is the lack of a standard for exposing the DOM to external applications,
although MS Explorer does provide this capability through COM interfaces
for the MS-Windows plateform. The main concern of this approach by some AT
developers is that is requires them to do something special for web based
user agents that is significantly different from what they do to access
information for other applications they try to support. Although some other
AT developers have developed there own version of a DOM to try to provide
improved access to web content.
</add>
<delete>
No minimal functional requirement obvious
The WG attempted to identify "minimal requirements" a user agent
would have to satisfy to be considered
accessible (at times, the bar is quite high in fact). For some
functionalities, minimal requirements were difficult or
impossible to identify, and therefore the WG chose either:
To make a general requirement and leave the specifics to the
Techniques Document, or
To make no requirement and leave the job to assistive
technologies.
One example of this includes table navigation. Access to table
cells and cell context (headers, neighboring cells,
etc.) is very important to users and there is a Priority 1
requirement that such information be made available to
users. However, navigation of table cells is just one (admittedly
useful) means to achieve the goals of access to
content and orientation. Two problems present themselves, however:
Requiring navigation through N-dimensional space (up, down,
left, right) frames the functionality in terms of
the graphical artifact. For non-sighted users or users with
motor disabilities, requiring navigation through
two-dimensional space may not be an efficient way to access
the information.
Which navigation methods suffice? Sequential access alone?
For large tables (say 500x500 cells), this
would surely be tedious and therefore direct access (by
row/column position) would be more effective. In
addition, it would be useful to be able to shrink or expand
parts of the table, search on table contents, identify
all cells (possibly in N-dimensional space) under a
particular header, and all headers for a particular cell, etc.
In short, the WG recognizes the importance of navigation as a
technique for making tables accessible, but
has not been able to identify a minimal requirement for
general-purpose user agents.
</delete>
<add>
Minimal Functional Requirements for Accessibility
The WG found that the techniques for accessible rendering and navigation
of web content are very dependent on the medium of rendering (text,
graphics, speech, Braille). That functionalities that make sense for one
rendering medium do not translate well or complicate the user interface of
another medium (notabily graphical and speech). Therefore the guidelines
have checkpoints related to accessible rendering of content in the medium
the general purpose user interface supports and providing access to web
content to assistive technology for alternative rendering and navigation of
web content.
The problems were most notably found for table content rendered by
graphical user agents, which is currently a major problem for people with
visual disabilities and blindness. Proposals were made for checkpoints
requiring keyboard based navigation of table cell content in GUI user
agents. Many types of keyboard techniques were proposed to improve the
accessibility to table information and access to table header information.
Some of the problems:
1. Keyboard techniques were not provided in a context of a larger keyboard
access to all content
2. How the user agent would expose what table cell had the point-of-regaurd?
3. What if the graphical user agent could not render the entire contents of
a table cell in the view, how would the AT know?
4. Keyboard navigation of table cell information was typically handled by
scoll bars in graphical user agents and developers had concerns about
developing funcationalities that is not redundent with current functionalities
5. There would a potential for keyboard conflict with AT functionalities
6. There would still be requirements for use of AT commands to access the
content, making access less than efficient and require more user skill to
access the content.
</add>
Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Chair, W3C WAI User Agent Working Group
Division of Rehabilitation - Education Services
College of Applied Life Studies
University of Illinois at Urbana/Champaign
1207 S. Oak Street, Champaign, IL 61820
Voice: (217) 244-5870
Fax: (217) 333-0248
E-mail: jongund@uiuc.edu
WWW: http://www.staff.uiuc.edu/~jongund
WWW: http://www.w3.org/wai/ua
Received on Tuesday, 4 January 2000 11:57:47 UTC