2001 Conference Proceedings
Go to previous article
Go to next article
Return to 2001 Table of Contents
IBM's Web Access Gateway Technology IBM Working to build
Next-Generation Server-Based Web-Access Technology
Rich Schwerdtfeger, Senior Technical Staff Member
Architect
Server Based Web Solution Development
IBM Accessibility Center
Email: schwer@us.ibm.com
IBM
11501 Burnet Rd.
Austin, Texas 78758
Introduction
For over 15 years IBM has worked to deliver assistive technology
to the industry starting with the very first screen readers. In
this process we have worked to architect solutions and
accessibility frameworks with Microsoft on MSAA, Sun on Java, and
the W3C WAI.
The problem with most of the accessibility initiatives today is
that, being mostly client-centric, they are susceptible to
enormous change. The change has occurred due to a variety of
factors having to do with competition or a change in the
pervasiveness of the client user agent device. This creates
numerous problems for a user with a disability. It requires the
user to learn a new client device creating a long learning curve.
It also requires the user to wait for a solution that is also
likely to be expensive. It is unrealistic to believe that we can
continue along this path.
We believe the way to attack the problem is to go to where the
industry is creating standards and find a common ground. That
common ground is server-based web technology. IBM’s new
solution to the accessibility problem is to create the first
collection of server-based solutions designed to modify and
deliver usable Web content to disabled users on a broad range
devices. This server-based solution is called the Web
Accessibility Gateway (WAG) and its first challenge is to solve
the accessibility problems for the most misunderstood users of
the Web - our aging population.
In this presentation we will talk about the new WAG project
being developed by the IBM Accessibility Center and IBM
research.
1.0 The server-based accessibility paradigm shift Imagine that
tomorrow you are signing up for a new Internet service whether it
be for your phone, kiosk access to the Smithsonian, desktop ISP,
or set-top box ISP. As part of your normal setup to ask a
customer service representative or select from a menu you also
select presentation usability settings. These settings may be
speech output for a blind user, page simplification, high
contrast colors, larger fonts, increased white space, intelligent
alternate text generation for inaccessible pictures, enlarged
images, text summarization for large documents, etc.
Once your have made your selections accessibility features may
be activated in your device or the content you request from the
network is modified behind the scenes by an intelligent gateway,
Figure 1.0 WAG 10,000 Foot View, running between you and the
content you wish to access. The gateway acts as a proxy between
your device’s user agent (browser) and the documents you
are requesting. The gateway applies the transformations to any
page or injects solutions in any page to make the page usable for
you on your device. This has the potential of delivering access
universally.
Figure 1.0: WAG 10,000 Foot View 2.0 New architectural model To
move access technology from the client to a centrally managed,
distributed solution requires a different architectural model. At
a minimum it must:
Ensure Privacy of User data and preferences Support common
browser services Be scalable to support a growing number of users
Be able to be reprogrammed without re-booting the gateway Provide
the same functionality to users over secure as well as insecure
connections Be highly serviceable and extendable to support a
broad range of user needs Reduce the maintenance of
client-specific installed solutions Support content delivered
over secure connections Be centrally managed Figure 2.0 New
Accessibility Landscape with the Web Accessibility Gateway
This slide shows the new accessibility landscape for the WAG. On
your left is a collection of devices used to access Internet
content. The WAG acts as a proxy between the target device and
the Internet servers providing the content. Access to the WAG may
through a direct Internet connection or staged using different
communication medium such as in the case of the telephone that
may first require transmission over a Public Switching Telephone
Network to a VoiceXML servant.
2.1 Routing and authentication Requests entering the gateway
must be routed, for load balancing, using IBM's network
dispatcher. After routing has been determined, they are passed to
a designated WAG transcoding server in the WAG transcoding farm.
Each WAG transcoder is built on WebSphere Transcoding Publisher
(WTP). At the transcoding machine user information passed in the
request is authenticated using Tivoli's Policy Director based on
the user set stored. If the user is not known or invalid, the the
transcoding gateway will direct the devices user agent (browser)
to authenticate the user by prompting them for a userid and
password. This would be passed back as part of the request for
further validation.
2.2 Transcoders - use of web intermediaries The WAG transcoders
are based around WebSphere Transcoding Publisher (WTP).
Internally WTP contains a programmable HTTP request and response
processor. It receives an HTTP request from a client, such as a
web browser, and produces an HTTP response that is returned to
the client. The processing that happens in between is controlled
by the modules programmed into WTP.
Figure 2.1 transaction (request/response) flows through a series
of MEGs (monitors, editors, generators)
Figure 2.1 shows the flow through a typical WTP transaction. It
goes through three basic stages: request editors, generators, and
editors (which would be more appropriately called "document
editors"). Request Editors receive a request and have the freedom
to modify the request before passing it along. Generators receive
a request and produce a corresponding response (i.e., a
document). Editors receive a response and have the freedom to
modify the response before passing it along. When all the steps
are completed, the response is sent to the originating client. A
fourth type of element, the Monitor, can be designated to receive
a copy of the request and response but cannot otherwise modify
the data flow. The Monitor, Editor, Request Editor and Generator
modules are collectively referred to as MEGs.
2.2.1 WAG Transcoding for usability Once a user has been
validated, a master transcoder is run. This is a collection off
transcoders responsible for transcode support services such as
secure connection, and client cache control management. The
master transcoder will also will query the user database for
profile information and an XML transcoding directive. This
directive tells each AT transcoder what transformations to run in
the proper sequence. The desired document(s) are then retrieved
from an Internet server. The master transcoder will use the
transcoding directive to tell the WebSphere Transcoding publisher
what AT transformations to apply and in what order for
transmission back to the client.
The transcoding software in the WAG is designed to handle
dynamic transcoding. To do this, each WAG transcoder stores the
document retrieved in browser form for manipulation by each of
the desired transformations. As a browser it works to separate
content, data, and executable script for manipulation by WAG
transforms designed to improve the accessibility and usability by
the disabled or senior user accessing the gateway. A subset of
the transformations are shown at the bottom of Figure 2.0 and as
library functions in Figure 3.0 - Low-Vision Transcoder
Architecture. Some advantages of using the browser model is that
we can extend browser functionality without dependence on a third
party. We will also support W3C standard Java bindings such as
Document Object Model (DOM) and DOM Cascading Style Sheets (CSS).
We also perform error correction on transformations.
Figure 3.0 WA Gateway - Low-Vision Architecture Transformations
are also performed to support WAG Web applications described in
the next section. Also, since each transcoding machine acts as a
proxy we are able to monitor the where the user goes. This
information is used to write history information into into the
User database to support normal client browser services such as
history list, and previous/next browser navigation.
The final format of the transformation is based on the output
device being used.
2.3 WAG web applications The WAG will support a collection of
applications as shown in Figure 2.0 New Accessibility Landscape
with the WAG. This part of the figure is marked in grey since it
will be possible for these applications to be customized the
customer deploying this service. These applications may also run
outside the WAG on another server. Example applications are
customization of user settings, online registration, Email to
web-based mail services, and browser services to have a common
look for a given organization while still being subject to
transformations by the gateway.
It is important to note that by moving many of these browser and
Email based services to a web-based solution we will be able to
make these solutions accessible through the gateway in a device
independent fashion rather than having to create an accessible
solution for these on each platform.
As part of the application server we will also provide an
accessible mechanism for installing device specific solutions,
such as a Windows-based intelligent agent for dynamically
adjusting keyboard response based on user keyboard interaction.
We feel this will provide a vehicle for ISP's, and organizations
to deploy centrally-managed accessibility and usability solutions
to individual users.
3.0 Example: Using the WAG to correct vision and cognitive
impairments in seniors Seniors suffer from a variety of
impairments due to the effects of aging. The following result in
reduced light & contrast sensitivities,color discrimination,
and reduced acuities:
Pupil miosis - shrinking of the pupil Increased light absorption
- caused by thickening of the lens Yellowing of the lens Light
scatter The affects to the person are dimmer, lower contrast
visual world, less vivid colors, poor night vision, blurred
vision, and reading problems.
Figure 4: Reduced apparent luminance and contrast
Other vision problems result in vision blurring and the need for
magnification and page simplification:
Structural retinal destruction photoreceptor loss losses in
higher visual pathways Functional monocular blind spots
(scotomas) localization errors, metamorphopsia and crowding
binocular blind spots cognitive impairments 3.1 WAG content
transformations To correct for far-sighted low-vision impairments
the WAG will enlarge text and images, change fonts, and reduce
horizontal scrolling. To correct for the functional impairments,
it will increase change fonts, increase inter-letter and
inter-line spacing. To correct for transmissive disorders the WAG
will incorporate light management transformations such as high
contrast colors, managing background color, reduction of image
light intensity while applying these transformations with
intelligent error correction.
To help with cognitive impairments, the WAG will be configured
to halt flashing images and blinking text. It will also be
configured to remove background images.
To improve access to mail, the WAG makes use of mail to web-mail
backed application services allowing these same transformations
to be made to mail through the WAG.
4.0 WAG Demo
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.