2003 Conference Proceedings

Go to previous article 
Go to next article 
Return to 2003 Table of Contents 

Disability Simulator

Hironobu Takagi
Kentarou Fukuda
Junji Maeda
Chieko Asakawa
IBM Japan Ltd., Tokyo Research Laboratory
1623-14, Shimotsuruma
Yamato-shi, Kanagawa-ken 242-8502, Japan
Email: takagih@jp.ibm.com 
Email: kentarou@jp.ibm.com 
Email: maeda@jp.ibm.com 
Email: chie@jp.ibm.com

Sam Detweiler
IBM Accessibility Center
11400 Burnet Road, Bldg 903 Office 5B004
Austin, Texas 78758
Email: sdetweil@us.ibm.com


In this presentation, we will describe and demonstrate our prototype disability simulator that helps Web authors to experience how disabled people access their pages. We will use the simulation for blind users as an example of how the simulator works.


One of the most effective ways to learn about the Web's accessibility is for Web authors to experience how disabled people access the Web by themselves using assistive technology software such as Home Page Reader (HPR) [1], Jaws [2], or ZoomText [3]. However, it is not very easy for non-disabled authors to have experiences similar to those of persons with disabilities even if they use such assistive applications. For example, blind people's hearing abilities may become more developed than sighted people's. In addition, it would take a lot of time for sighted users to learn how to access

the Web nonvisually using applications like HPR, since it is designed for the needs and preferences of blind users. This is similar to the problems for blind users when learning to use GUI applications, since they are well designed to be used visually. Another approach would be to observe the real environments that disabled people use to access the Web with their assistive technology software. It would also be difficult for authors to have such experiences.

Therefore, we propose to develop a disability simulator for Web authors to have such experiences on their own computers at authoring time. The Disability Simulator (DS) will consist of three components: One for an assistive technology (AT) software user interface simulator to simulate each AT program while considering ease-of-use for non-disabled people, one for a virtual user simulator to observe real disabled users' behavior, and one for visualization for the accessibility conditions to visualize how accessible a target page is. In this presentation, we will describe these components of the disability simulator, using HPR as an example of AT software.


2.1 Overview
Figure 1 shows the architecture of our prototype system. It is implemented as a plug-in for a Web authoring tool, the Eclipse framework and a web authoring plug-in, to allow authors to use DS while they are preparing Web content. There will be several simulators, such as an HPR simulator, a Jaws simulator, and so on. DS users can select one of these on the preview menu of the authoring tool, since they are added to the regular menus. After the HPR simulator is selected, three selection items appear, the HPR UI simulator, the virtual HPR user simulator, and a visualization tool for the blind usability. They can experience how blind users access their pages with HPR by using these simulation functions effectively.

Architecture of Disability Simulator

2.2 HPR User Interface Simulator
Several of the most frequently used commands among the many of HPR commands are selected, such as Play, Stop, Next (previous) link, Next (previous) line, Top of a page, and Bottom of a page. These commands are shown through a control panel for sighted Web authors to input the HPR commands easily without learning complicated key assignments. When one of these commands is selected, the corresponding speech is read aloud. While it is reading aloud, the DS users can select to show or not show the corresponding visual output onscreen. The "not show" option simulates the experience of blind users. When they select the "show" option, they can select for highlighting the reading text information in the original page, for presenting the reading text information in the original page while blacking out the other original information on the page, or for presenting only the reading text information in a different window (called a "text view"). This visual presentation will help sighted users to understand which text HPR is reading and which order it is reading it in, and so on.

2.3. Virtual HPR User
Virtual user works to demonstrate an actual disabled user's behavior as if he or she was performing the Web access using the AT software, so that Web authors will be able to observe a virtual environment showing how a disabled person accesses the their pages using their AT software.

In the virtual user simulation mode, a user agent always appears to interact with the DS user and speak for real disabled users problems. In addition to simulating the disabled users' behavior, it also checks some of the WCAG check items such as missing ALT texts, skip navigation links, and so on. When it finds these errors, an agent appears to interactively instruct authors about how to fix them, by showing how the error makes the page less accessible and how it becomes accessible if they fix it using the simulating functions and visualization feature. We are aiming at as system such that Web authors will be able to learn about the actual and practical aspects of accessibility through these steps.

The virtual HPR user has a set of default tasks. Two examples will be described here:

"Read the main content in a page."
The agent starts searching for the main content area by simulating the method a blind user might use. If simulating a novice user, it will start reading the text aloud information from the top of the page until it finds the main content. For an advanced user, it will skip some information using a line-by-line jump command until the main content is found. The appropriate command is automatically issued by the agent. The actual main content position is determined based on our HTML page layout analysis method [4]. When the main content area is found, the simulator shows the time required to get to that position. If it can not find the target area within one minute, the agent will issue a message to encourage the author to modify the page, such as: "I could not find the main content in one minute. It took too much time. Please create a skip-to-main-content link or a page index for this page." It will then start a repair wizard to help the author to fix it.

"Check ALT texts."
This checks (1) if each image or image link has an ALT text, (2) if the ALT text seems appropriate, and (3) if the ALT text information is redundant. When a DS user selects this task, the system will add X marks on images and image links without ALT texts. When there is no ALT for an image link, for example, the agent appears to inform the author that "This image link has no text information and HPR only reads it as 'article/001.html'. I cannot figure out which page appears after clicking it. If you describe such a link using an ALT text as 'sports information', for example, then it would be very easy for me to follow this image link. Would you like to fix it now?" If "yes" is selected, the repair wizard appears.

For the appropriateness of an ALT text, when it finds a questionable text such as "spacer gif" the agent will say, "Do I need to hear 'spacer gif'? If it is unimportant, would you prefer to replace it with a null string? That will skip saying 'spacer gif' and save time." If the DS user wants to fix it, the repair wizard appears. In addition, the agent can also report that "Five more 'spacer.gif' ALT texts appear in this page. Do you want me to fix all of them? Or do you want to check each one now?"

In this way, other default tasks such as "find a search form and input a search string" or "find a submit button" can be performed.

2.4. Visualization for Blind Usability
In addition to the AT software user interface simulation and virtual user simulation, DS makes the accessibility conditions visible to show at a glance how accessible a target page is. Basically, it renders a text version of the target page based on the HPR engine. The engine is a core part of the AT simulator to convert HTML descriptions into output text, so Web authors can check the voice rendering without actually using voice output. It also has a colorization function, which can make problematic parts of the target page visible by colorizing the text. For example, it can colorize the lack of an ALT text, an inappropriate ALT text, or the lack of a skip-to-main content link. This function can help sighted Web authors to understand the non-visual usability at a glance.


As a first step to developing a disability simulator, we have prototyped a blind user simulator with HPR navigation commands. We plan to perform an experiment considering (1) how much time is needed for sighted users to learn the HPR user interface simulator, (2) how helpful the virtual HPR users and HPR user agents are, (3) if the authors are willing to fix the problems which the agent reports, and (4) finally, how easily they could recognize the blind usability aspects through the visualization function. After performing this experiment, we will develop other disability simulation functions, such as for low vision users, motor disabled users, and so on. Finally, a comprehensive experiment will be planned to evaluate how effective such a disability simulator approach is to improve the Web's accessibility as well as to let Web authors know the importance of accessibility toward realizing a practically available system.

[1] Home Page Reader, IBM Corporation, http://www-3.ibm.com/able/hpr.html

[2] Jaws, Freedom Scientific, http://www.freedomscientific.com/fs_products/software_jaws.asp

[3] ZoomText, Ai Squared, http://www.aisquared.com/

[4] H. Takagi, C. Asakawa, "Page-Customization Allowing Blind Users to Improve Web Accessibility by Themselves", in the Proceedings of The 1st International Conference on "Universal Access in Human - Computer Interaction (UAHCI)", Erlbaum, 2001

Go to previous article 
Go to next article 
Return to 2003 Table of Contents 
Return to Table of Proceedings

Reprinted with author(s) permission. Author(s) retain copyright.