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.