1999 Conference Proceedings

Go to previous article 
Go to next article 
Return to 1999 Conference Table of Contents


ADAPTING MULTIMEDIA SOFTWARE FOR BLIND STUDENTS: CHOICES AND CHALLENGES

Madeleine Rothberg and Tom Wlodkowski
The CPB/WGBH National Center for Accessible Media
125 Western Avenue, Boston, MA 02134
Phone: (617) 492-9258 (V/TTY)
Fax: (617) 782-2155
E-mail: madeleine_rothberg@wgbh.org or
tom_wlodkowski@wgbh.org 
Web: http://www.wgbh.org/ncam

Introduction

Multimedia software, with its ability to combine video, audio, animations and text, can be a powerful tool for the classroom. A CD-ROM simulation demonstrating the factors that effect photosynthesis or a multimedia math game that teaches the order of operations are wonderful supplements to materials covered in a math or biology textbook. Unfortunately, blind and visually impaired students cannot take advantage of the increased understanding these CD-ROMs provide because they're confronted with several roadblocks. First, due to the high degree of product customization, screen readers cannot access essential on-screen controls. And assuming the controls were accessible or sighted assistance was available to operate the controls, the blind student still could not view the output of the photosynthesis simulation, or in the case of the math game, read the numbers to build equations or track their game piece as it moves along a number line. These are only two examples of the wealth of multimedia software that is inaccessible to blind students.

The CD-ROM Access Project, a three-year project funded by the National Science Foundation (NSF), is working to address these barriers by prototyping an array of possible solutions. These solutions will ultimately result in the generation and dissemination of guidelines to enable educational software developers to create truly accessible products.

Prior to the prototyping phase, the project identified barriers by testing sixteen science and math CD-ROMs designed for different age groups. Based on our analysis, we've defined two levels of accessibility. The appropriate level of access to be provided by the software producer must take into account the grade level of the product and the lessons being taught. This paper will discuss choosing appropriate solutions, highlight two prototyped accessible interfaces, discuss problems encountered during the prototype process, and point out issues yet to be resolved. Although the project's primary focus is on improving the accessibility of math and science based software, the majority of the guidelines will address barriers common to all types of multimedia.

Choosing appropriate solutions

Software accessibility solutions fall into two categories of access -- direct and indirect, defined below. To determine the most appropriate access a product can provide, several factors must be considered -- target grade level of a piece of software, technical constraints on the software's design, and the educational goals of the product.

A "directly accessible" product is designed so that a blind person can operate all on-screen controls and access the product content without relying on the aid of a screen reader or magnifier. Many vision teachers report that their younger students get limited training with assistive technologies. For this reason, built-in access is most crucial in products targeted for the elementary and middle school level. A directly accessible product should have a keyboard interface with audio output. Audio should also announce the presence and status of all on-screen controls and convey the atmosphere of the software.

An "indirectly accessible" piece of software is designed with a screen reader and magnifier in mind. This level of access assumes the user has a preferred assistive technology package installed and is relatively comfortable with it. Software that falls into this category is likely targeted at the high school level and beyond. An indirectly accessible product is designed with "hooks" to facilitate ease of use with a screen reader or magnifier. These hooks can be implemented by developers with tools like Microsoft Active Accessibility (MSAA) [1] and the Java access API from Sun [2]. Exposing the system cursor and using standard controls and fonts can also help make a product indirectly accessible.

It is important to note that not every product can be made accessible. The educational goals of a program are sometimes incompatible with providing non-visual access, especially for students who are blind. For example, many programs for young children teach visual concepts, such as counting and color pattern matching. While blind students do of course need to learn to count and to make patterns, a program that uses only visual ways of teaching these skills is a poor candidate for adaptation. In their report "Accessibility of Information in Electronic Textbooks for Students Who are Blind or Visually Impaired," the Texas Education Agency gives an example of a simulation of a piston engine [3]. This software might provide a keyboard interface for adjusting the engine and verbal descriptions and sounds to convey the motion of the parts of the engine, but it has no inherently non-visual information to provide and for that reason is not a good candidate for adaptation. A visually impaired student using that simulation might learn that "a flywheel is a left/right button," says the report, rather than learning how the parts of an engine fit together and how they work.

Low-vision students, however, may still benefit from a visual program, provided it is well designed. Software should allow fonts to be adjusted, provide clear contrast for objects that students must locate and manipulate, include keyboard commands to reduce mouse dependence, and provide a system cursor that moves with important screen events so that magnifiers can track them. With these features in place, software with a range of educational goals can be useful to students with some useful vision.

Prototypes

How the West Was One + Three x Four is a board game designed to encourage early elementary students to explore order of operations by making mathematical equations. The game has a wild west motif, and the goal is for each player to try to be the first to reach the end of a number line. We selected this product to prototype direct access for several reasons. First, in addition to providing students with valuable math skills, this product is a fun game to play. Blind and visually impaired kids don't often get to play computer games with their sighted classmates since the vast majority of software is inaccessible. Second, the product is a good example of how blind students can really excel with educational multimedia software if accessibility issues are addressed.

The original product uses audio to set the wild west atmosphere, with a locomotive that whistles and a stagecoach driver who calls "Giddyup!" But these fun sounds are not enough to make the program usable by a blind person. The original game screen is difficult to use under magnification; players can't track the game pieces as they animate and can lose sight of their piece even when it is still because of the decorative images along the number line. Screen readers cannot access the computer-generated numbers to build equations or assist the user in tracking game pieces.

To improve usability, we have built an audio/keyboard interface which is the same on both the Macintosh and Windows platforms. A screen reader or magnifier is not required for effective use of this prototype. The audio is digitized, not synthetic speech. To enhance accessibility, the program announces the status of all radio buttons encountered in dialog boxes and orients the player to the game screen by announcing player positions and strategic options that originally were conveyed only visually.

The directions on how to play the game can also be heard on request. The product's use of the keyboard has been significantly enhanced with several key commands. In order to change the status of a radio button for example, a task normally performed with a mouse or screen reader keyboard command, the user simply types the first letter of the desired choice. Pressing the tab key will change the focus in dialogs and the audio will announce the item currently in focus. Commands are also available to toggle the accessibility features on and off, to read and edit the contents of an edit box, and to obtain on-screen information about player positions and game strategy. A dialog box titled "Accessibility" has been added to the Options menu to alert teachers, parents and students to the array of available access features. Macromedia Director, a commonly used multimedia authoring tool, was used to build this prototype. During the building process we discovered limitations in addressing access with this authoring tool. First, screen readers cannot access controls implemented with this tool or navigate the custom menu bar. Our hope was to make this prototype screen reader accessible even though assistive technology is not required to play the game, but that wasn't possible. Another key concern is the ability to interrupt audio, stopping the audio in mid-stream, with a keyboard command. Although we were able to provide a designated key to use to interrupt the audio, we were not able to make it possible to interrupt one audio segment and move on to the next command simultaneously, which is an important feature for experienced users. Because of technical limitations in Director, developers would need to spend a significant amount of time and add a lot of complexity to their product's design to provide fully interruptable audio, making it likely that they would not offer this feature. In addition, the animations that are so easy to create in Director cannot be tracked by a screen magnifier, so students who are using one will still not be easily able to watch their game pieces move.

A second prototype, not yet built at the time of this writing, will be based on a simulation of photosynthesis, part of a series of biology simulations from LOGAL, Inc. Photosynthesis Explorer is a simulation in which students vary the light, temperature, humidity, and other influences on a plant and observe the resulting amounts of sugar and oxygen produced by the plant. Diagrams show where different chemicals enter and leave a leaf and also present an abstract view of the chemical pathway of photosynthesis.

Although the original presentation of the material relies largely on visual displays for both input and output, there is numeric information at the heart of the simulation. If the data about the amount of sugar produced for different levels of light intensity is available numerically, blind students can learn interactively about the factors needed for successful photosynthesis. Audio graphs can provide a blind student with the quick overview that a visual graph provides for sighted students, while an interactive table can permit an in-depth investigation of the numbers. Description of the diagrams, in audio or text, might be helpful, although they should probably be accompanied by tactile diagrams for clearest understanding. Together, these techniques can provide an appropriate adaptation to allow visually impaired students to participate in this simulation.

As for software for younger students, it may be possible and beneficial to make the program directly accessible by providing narrated audio or text-to-speech directly within the application. However, since the program is aimed at the high school level, it could be made accessible by designing it to cooperate with screen readers. This may provide consistency of operation since the student already knows how to navigate with their screen reader or is continually gaining competency in doing so. In some cases it may be less expensive to develop the software this way and it could save disk space for a large application, both of which would appeal to software companies. Screen reader accessibility is also the easiest way to provide access to Braille users, since techniques for providing direct output to Braille displays are uncommon. An additional benefit of building software that is cooperative with screen readers is that it will probably work well with other assistive technologies including alternative input devices such as scanning utilities, on-screen keyboards, and voice-recognition.

Making Photosynthesis Explorer accessible could require a combination of techniques. Access to menus, navigation, buttons, and other controls could be accomplished by passing information to a screen reader. However, descriptions of graphics, whether in narrated audio or in text, would need to be included by the software developer. Since there are currently no screen readers that provide access to graphs, that must be provided directly by the program. In the future, a standard could be established for communicating numeric information for graphs.

This would enable screen readers and other assistive devices to be programmed to create audio or tactile graphs on the fly. Tactile printers currently under development may make it possible to print out graphs from the computer individually, but until those technologies are commonly available it will be important that software companies provide tactile graphics for important graphical information by arrangement with an adaptive materials maker, for distribution with the software or to be delivered to users on request.

Conclusions

The technologies needed for creating accessible multimedia software are now available and the time has come to begin implementing them. Through our prototypes, the CD-ROM Access Project is exploring how to apply the general techniques available to some specific educational needs. As the software industry moves forward toward more use of universal design, it is important that they not only remember the needs of students who are blind or visually impaired but also that the appropriate choices are made of materials to be adapted and techniques for adapting them. With some thoughtful planning, the benefits of multimedia software can be brought to a larger audience.

References

[1] Microsoft Corporation. September, 1998. "Active Accessibility." Referenced on September 30, 1998 from the World Wide Web: http://www.microsoft.com/enable/msaaintro.htm

[2] Sun Microsystems. March, 1998. "Java Accessibility Utilities: Overview of Java Accessibility." Referenced on September 30, 1998 from the World Wide Web: http://www.javasoft.com/products/jfc/accessibility/doc/what.html

[3] Texas Education Agency. January 1997. "Accessibility of Information in Electronic Textbooks for Students Who are Blind or Visually Impaired." Referenced on September 30, 1998 from the World Wide Web: http://w


Go to previous article 
Go to next article 
Return to 1999 Conference Table of Contents 
Return to Table of Proceedings


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