More readable version of my comments related to Ian's proposal

Jon Gunderson response to Ian's proposal.  I have rewritten many of the
sections from Ian proposal based on my view of the current group consensus.

User Agent Responsibilities

4 January 2000

Response to Ian Jacobs Proposal:
http://www.w3.org/WAI/UA/1999/12/ua-resp-19991228 

Abstract
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.

Introduction

The User Agent Accessibility Guidelines include two types of requirements
for general purpose user agents:

1.Requirements for native implementation of accessibility to user agent
functionailities (i.e., the user agent implements them without requiring
additional software other than the operating system). 

2.Communication through Application Programming Interfaces (APIs) for
compatibility with
assistive technologies that provide alternative user interfaces and
rendering of content foraccess by specific disabilities. The Guidelines
require user agents to allow read and write access to both content and user
interface controls. 

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 "active" 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.

An example of 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 like a screen
reader could offer an alternative rendering of the information through
speech or Braille. The DOM provides all the inoformation needed by a screen
reader to provide an alternative rendering of the content.

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 recognize 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:

1. A parser and a tree processing engine 

2. One or more rendering engines that, given a tree and style parameters,
creates rendering structures. 

3.  A user interface for providing access to content. This includes: 

4. Viewports 

5. Navigation and search mechanisms, which allow the user to access content
other than sequentially. 

6. Orientation mechanisms such as proportional scroll bars, highlighting of
viewports, selection and focus, etc. 

7. 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). 
             
8. A user interface for facilitating browsing (history mechanism, bookmark
mechanism, etc.) 

9. Other user interface features (e.g., refresh the screen, reload the
document, send to the printer, etc.) 

10. Interpreters for scripting languages. 

11. APIs for communication with plug-ins. 

12. 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:

1. Form controls 
2. Links and their styling 
3. Keyboard and other input configurations provided by the author 
4. 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 a general
purpose user agent to provide alternative controls and/or renderings to a
general purpose user agent. Typically user agents are targeted to a
particular type of disability. Additional services might include:

1. Read access to the document tree would allow application of different
rendering engines. (e.g., speech output) 

2. Write access to the document tree would allow completion of forms
through, say, voice input or on screen keyboard 

3. Read access to the UI would allow an assistive technology to know which
viewport the user has selected, user agent configuration settings, etc. 

4.  Write access to the UI would allow users to navigate viewports (i.e.,
change the current viewport) through speech input on screen keyboard. 

5. Content transformation tools 

6. Additional navigation mechanisms that are useful in an alternative
rendering 

7. Additional orientation mechanisms that are useful in an alternative
rendering 

An assistive technology should not need to parse document source, but can
use the existing DOM of the general purpose user agent in order to offer
additional functionalities for access content.

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

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 major factor in determining the accessibility of a user
agent. Keyboard support allows users who cannot use the pointing device to
access the functionalities 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
means to map the user actions required by the assistive technology to the
functionalities of the user agent. This is probably not the best means to
do functional mapping, but it is currently the only one that is available
to most assistive technologies. 

The rendering of content using particular GUI operating system APIs is also
another way to allow assistive technologies to capture web content
information as it is drawn on a graphics 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. Other problems exist of information being incomplete, for example if
only part of a paragraph is "seen" by the AT since the paragrah was not
completly rendered in the graphical view. Therefore, the relationship and
context information lost using this method 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. 

The DOM

The existence of a platform- and programming-language independent way to
access web content means that AT developers can provide an improved
alternative renderings by using the information orginally provided by the
author. The main problem with this apporach is the lack of a standard for
exposing the DOM to external applications. The lack of a standard has not
stopped some developers  from providing external programs access, for
example 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 it requires them to do something special for web based
user agents that is significantly different from what they do to access
information in other applications they try to support. Although this
arguement is not universlly shared by all developers, at least one AT
developer has developed there own version of a DOM (non-W3C compliant) to
try to provide improved access to web content for there customers. They
would not have need to do develop their own DOM, if the checkpoints related
to DOM access in the UA guidelines were satisifed.

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 and 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. 

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. The working group spent considerable
time on proposals for checkpoints requiring keyboard based navigation of
table cell content in GUI based 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 does the user agent expose what table cell had the ATs
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 redundent with current functionalities
and not useful to sighted users.

5. There is a high 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. 


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 Wednesday, 5 January 2000 09:38:18 UTC