CD-ROMS for Math and Science
INTRODUCTION: THE PROBLEM
A rich array of software to support the teaching of math and science is now available. Unfortunately, most of this software is not usable by students who are blind or visually impaired. As students and teachers increasingly have access to multimedia computers in their classrooms, the chances that a student who is blind or visually impaired will be left out of a math or science lesson because of inaccessible software increases. Software that motivates with audio, allows interactive control of simulations, or provides a working math notebook complete with calculations, could be tools for students with impaired vision - if only the students could use it.
Visually impaired students use computers with a screen reader or a screen magnifier. Screen readers are computer programs that enable people to have printed text that appears on the computer monitor read aloud by synthesized speech. Traditionally, screen readers worked best with MS-DOS text-only products. But, since the graphical user interface (GUI) has taken hold, screen reader developers have designed their software to work reasonably well with mainstream Windows or Macintosh-based applications such as word processor, database management and spreadsheet programs. However, most commercially available multimedia software today have photos, videos, and graphical controls that cannot be interpreted by screen readers. In addition, with a large range of software available, it isn't cost-effect ive or feasible for screen reader vendors to customize their products to be compatible with all commercially available software.
Screen magnifiers enlarge the print and images that appear on the monitor screen, and in most cases, work well with interactive software.
The CD-ROM Access Project, at the CPB/WGBH National Center for Accessible Media, focuses on making multimedia science, math, engineering, and technology software accessible to people who are blind or visually impaired. A goal of this project is to develop and disseminate guidelines that will allow software publishers to create truly accessible products in two ways, first by standardizing methods of making information available to a screen reader and second, by building access directly into a mainstream piece of software.
The project began with an analysis of current CD-ROM software, parts of which are presented below. These case studies show the range of problems with current multimedia software and provide some idea of features to look for when evaluating products for your own use.
In order to use the capabilities of a range of screen readers and magnifiers, each piece of software was tested with three screen readers (JAWS for Windows 95 version 2.0, Screen Power for Windows 95 version 3.0 revision C, outSPOKEN for Macintosh version 1.7.5) and two screen enlargers (LP Windows version 6.1, and inLARGE version 2.1 for Macintosh). While we tried to use each program as fully as possible, we may not have used all possible features. Our comments should not be understood to compare the access technologies to each other.
Each product mentioned was the most current version available when our testing began. We tested both Macintosh and Windows versions and noted any major differences. Multimedia software often changes substantially from version to version and our comments are therefore only applicable to the version listed. New releases may be more or less accessible. We hope that a long-term outcome of this research will be more accessible software, but because products are designed long before they are released it may take some time before improvements are evident.
Note that none of the programs reviewed here have special descriptive features for visually impaired users to improve their understanding of visual images. These products do not include video description for their multimedia clips or descriptive text for photographs.
PART I: CASE STUDIES
1. HOW THE WEST WAS ONE + THREE X FOUR
How The West Was One + Three x Four from Sunburst is a board game with a Wild West motif designed to encourage early elementary students to explore order of operations by making mathematical equations. The player is given three numbers. He then creates an equation, paying attention to the order of operations to create an answer that gives him a good move. If the answer is correct, the player's game piece (a stagecoach or a locomotive) moves along the number line. Shortcuts and "safe towns" add some complexity and make it useful to find strategies to make an equation with a certain number for the answer.
SCREEN MAGNIFICATION
This product performs reasonably well under magnification on both the Windows and Macintosh platforms. There is a standard menu bar. On-screen text is clear and readable. Tracking game pieces as they move along the number line is difficult, although inLARGE users are able to slowly track the game's progress by moving the mouse pointer. Difficulty with tracking is a substantial drawback because it takes away some of the reward element of the game since students won't see the animated stagecoach and locomotive.
SCREEN READER ACCESS
The workarounds that can permit a screen reader user to enjoy playing "West" are too complex for the target age range for this product. The opening screen contains four buttons for selecting the type of game to be played. The buttons are not announced and can't be identified. The only way to access these buttons is by building macros, or by memorizing relative screen position, which is not a good solution for young users. The command buttons on the opening screen ("quit," "load saved game," etc.) can be accessed however. The game board is not usable for a couple of reasons. First, the number line and game pieces can't be identified. Second, the numbers generated by the computer in order to create an equation are presented as graphics that need to be labeled. The screen layout is scattered. The existing product audio is fun as it sets the Wild West atmosphere, but it really doesn't provide any useful information such as the position of players' game pieces, numbers to be played, etc. Text in the product help is partially accessible, but in all cases, sample equations are not accessible. We believe this is a result of the product's use of bitmapped text for selected parts of the help screens.
RECOMMENDATIONS FOR IMPROVEMENT
ENHANCED DIGITIZED AUDIO: This product has a great deal of fun audio already included, but the existing audio really doesn't provide any useful information. Description of the game board and creative play-by-play description of the game piece movement would enable players to track the progress of the game and help them strategize their next moves. The numbers to be played and the resulting equation also need to be voiced. Enhanced audio may also benefit other students as well, especially those with learning disabilities.
IMPROVED CONTRAST: Currently users of screen magnifiers experience difficulty tracking the game pieces as they move along the number line. At times the user loses the game piece in the background of the decorative images along the number line. Better contrast would help. One way to make this easier would be to provide a preference to customize color choice. Another option is to add a feature to enable the product to display information in the system colors defined by the user. It would also be useful if users could choose to remove the decorative images all together so that the game pieces and number line are clearly visible against the background.
ENHANCED KEYBOARD ACCESS FOR NAVIGATION: Currently this product implements the standard keyboard interface to invoked menus. Additional keyboard commands are essential for effective use by blind students. Helpful keyboard commands would include a command to enter the equation edit box from anywhere on the game board and a command to select one of the four game options on the opening screen. These key commands should be documented in the product manual and in the product help as well as in appropriate menus.
CONSISTENT PRESENTATION OF TEXT: Portions of the on-screen text throughout the product are bitmapped and inaccessible to screen reader users. Exposing textual information (numbers to be played, directions in product help, etc.) in the standard manner would vastly improve usability.
2. CELL BIOLOGY AND GENETICS
This product provides 17 interactive Explorations. Each is a simulation of a biological concept accompanied by additional graphics, videos, and a set of reading materials. Students change the values of variables and observe their effect on the simulation's outcomes.
SCREEN MAGNIFICATION
This product performs quite well under magnification. The text is readable and program graphics such as icons on the toolbar are usable, though a cleaner background would make viewing the screen much easier. The background looks stippled, small lines everywhere give it a parchment appearance when not magnified.
The graphical experiments that make up most of this program stand up well under magnification. The introductions to experiments as well as experiment help are presented as narration, which is a useful. The opening screen is a splash screen with graphical buttons to select a specific area of the product. Once an area has been selected, a traditional menu bar appears along with a toolbar. The menu bar is usable under magnification on both platforms. Video sequences and animations seem to perform better on the Macintosh than on Windows under magnification. This could be a result of processing speed on the machines used for this analysis. For example, when animations are turned on while LPWindows is running, the image does not move. However, if one switches to unmagnified and then back to magnified mode, the images move, but at a very slow rate. Likewise videos run fine when magnification is turned off. Even though the Macintosh and Windows versions of Cell Biology and Genetics are usable with a magnifier, it still will take the low vision user a good deal more time to learn to manipulate the interactions and to observe results, largely because the entire screen can't be viewed at a glance.
SCREEN READER ACCESS
Independent use of this product with a screen reader is virtually impossible. Vital controls to operate the experiments cannot be accessed with a screen reader, and any potential workarounds would be too complex to make using the program worthwhile. ScreenPower and JAWS cannot read any on-screen text, but some of the text in the explorations is readable with outSPOKEN on the Macintosh. This indicates on-screen text was implemented in a slightly different fashion on each platform. Once past the opening splash screen (described earlier) a standard menu bar is available on both platforms but this does not improve usability. The toolbar on both platforms is equally inaccessible. Implementation of audio introductions to each simulation and audio help on the specific operation of each simulation is helpful, but enhanced descriptive language would improve the product further.
RECOMMENDATIONS FOR IMPROVEMENT
ENHANCED KEYBOARD ACCESS: A keyboard interface is essential in order for a blind student to freely navigate through simulations and to invoke essential controls. Currently the simulations require the ability to adjust sliders and click buttons, tasks which are easily performed with a mouse. Screen readers provide the capability to perform mouse clicks and navigate, but these features often become unreliable inside simulations and can cause unintended interactions.
EXPOSE ALL ON-SCREEN CONTROLS: Equally as important as an implementation of a keyboard interface is the need for the blind user to be able to identify all the available controls. Currently, none of the simulation controls in this product can be identified by a screen reader. There are some readily available solutions such as Microsoft Active Accessibility (MSAA). Additional work in this area is underway. See "Possible Solutions" (Part II of this paper) for a detailed explanation of how MSAA and other methods under development can be used to expose on-screen controls.
ENHANCE AUDIO TO IMPROVE ACCESSIBILITY OF CONTENT: Most simulations are entirely visual and even if the user can navigate and access all of the necessary controls, much of the educational information conveyed through the simulation is lost. One way to make this information more meaningful is to improve upon the product's use of audio. Cell Biology and Genetics already provides audio help and audio introductions for each experiment. Audio feedback and descriptive narration of essential elements of a simulation while the interaction is in progress would significantly improve accessibility.
EXPOSE ON-SCREEN TEXT: In addition to simulations, this product also contains a large amount of reading material to accompany the simulations. Implementing standard methods of exposing on-screen text would enable a blind student to take advantage of this reading material.
3. STUDYWORKS FOR SCHOOLS
StudyWorks for Schools, from MathSoft, is a tool for writing math and science. It is aimed at high school students and also includes a resource center with information and equations for many topics. Students can find examples in the library that match the problem they are trying to solve and replace the variables with their own numbers to find a solution. They can also write new equations, create graphs, and format lab reports.
SCREEN MAGNIFICATION
StudyWorks can be used effectively with a screen magnifier. The text quality is good and the user can set the font size. Graphics magnify adequately, although the lines are somewhat light and broken at higher magnifications. The presence of keyboard commands for entering and moving through text is helpful. A list of those commands is easily located using the index to the on-screen help. While the cursor is tracked appropriately when entering text and numbers from the keyboard, using the button palettes causes the focus to shift and the user must return it to the equation being entered. Tooltips on the palettes also cause some trouble because they pull focus off the button when they appear, making it difficult to choose a button. An option to disable or delay the tooltips would be useful.
SCREEN READING
Use of StudyWorks with a screen reader is difficult for two reasons: the math equations, which are the most important content, cannot be read, and navigation within the product is difficult. Reading equations with a screen reader is not yet possible in mainstream graphical software. Graphs and tables are similarly difficult to use. A solution to this will require the creation of standards for math, table, and graph presentation which allow screen readers to access the underlying data and present it in an effective way.
Navigation problems seem to result from the use of overlapping windows of different types. The Resource Center window has no menu bar and is therefore lacking an easily accessible set of controls. Switching between the document window and the resource window is only possible with mouse commands. In addition, some windows appear to be lacking title bars, making them difficult to identify when navigating through the objects on the screen. A great deal of customization might resolve part of this problem, but better identified windows would be easier to work with.
RECOMMENDATIONS FOR IMPROVEMENT
SIMPLER NAVIGATION: As with most programs that use multiple windows to hold different types of material, StudyWorks could simplify navigation by offering keyboard or menu commands for switching windows. Additionally, ensuring that each window has an appropriate title will improve access for users of screen readers that read that information.
IMPROVED HELP TEXT: Another common problem seen here is the use of graphics of the keyboard keys in the Help files that list the keyboard commands. Help information on keyboard commands should include the name of each key and not just a graphic of the key. This would allow screen reader users to learn about these important keyboard commands.
OPTIONAL TOOLTIPS: The many button palettes give quick access to features for those who can use them, and tooltips that explain what each button does are useful. However, when tooltips appear they move the focus from the button to the tooltip. This moves the user's view away from the tooltip, if high magnification is in use, and makes it difficult to actually click the button. Software should allow the user to delay or disable the tool-tips for the button palettes as a user preference so that users can avoid this problem.
CONSISTENT CURSOR TRACKING: Most GUI software would be improved by better tracking of custom cursors. This can be done by keeping the system cursor in the same location as the custom cursor at all times. (Note that MathSoft, developers of StudyWorks, have told us that they have corrected the cursor tracking in their underlying software engine, and that future versions of their software will correct this problem.)
ACCESSIBLE MATHEMATICS: Until the problems with tables, equations, and graphs can be solved, it will not be possible to provide access for blind students to a program like StudyWorks. This is unfortunate because a tool like this could have many benefits for blind students who need to work with equations as they study math or science. These problems are industry-wide and possible solutions are discussed below.
PART II: POSSIBLE SOLUTIONS
This is an exciting time in the field of software access, and one of waiting for improvements that could be just around the corner. Several major initiatives that allow software developers to provide improved access to their products have been announced or implemented in the past year. However, to date they have not been widely implemented and we do not yet know how broad their impact will be, or how many of the current problems they will solve.
Navigation through graphical user interfaces (GUIs) is difficult primarily because the buttons, menus, and other controls that the user must manipulate to move around and make choices, are often invisible or nameless when viewed by a screen reader. In addition, the use of custom cursors rather than the true system cursor leads to trouble. One possible solution for software built for the Windows 95 platform is Microsoft's Active Accessibility (MSAA), an applications programming interface (API) for exposing elements of the screen and their state, including exposing the focus of the screen (Microsoft, 1997a). Using MSAA, software developers can use entirely graphical custom interfaces, while still making each element known to the screen reader. Screen reader developers must then write software that can read this information and convey it to the user. MSAA has been implemented in some Microsoft products but until it is more widely used we will not know if there are some interfaces which are not well described by this method.
The growing popularity of Java as a programming language for the Internet has led to the development of the Java Accessibility API (Sun Microsystems, 1998). With some similarities to MSAA, Java Accessibility allows software developers to expose the location, names, and states of each control while still using the graphical look-and-feel of their choice. The Java Swing Set's pluggable look-and-feel holds out hope that each user could "plug in" the interface that suits them best, with visually impaired users choosing larger objects and fonts while blind users choose an audio-enabled interface, or one that works best with their screen reader.
Reading and manipulating tables is an important way of processing scientific information and is a particular problem for blind users. Using data in a table requires referring to the headings for the row and column in order to interpret the information in a single cell. Currently, when navigating the tables in StudyWorks and some other software, blind users don't even know what cell they are in at any time, let alone the column and row headers that apply. A standard way of letting screen readers know which headers apply to each cell is needed, such as that proposed as part of the HTML 4.0 specification from the World Wide Web Consortium (W3C) (1997). Once this information is available, screen readers can create appropriate navigation commands and respond with the data for each cell in context. This will permit blind users to explore a set of tabular data more efficiently.
Making math and science content accessible will require creative thinking as well as some work on underlying development systems. Adding description of still or moving images so that they can be better understood by blind or visually impaired students can be done by providing recorded human audio or through the use of text on the screen, which can be read using a screen reader. An audio track synchronized with the video soundtrack will be most effective for videos and animations, while a plain text solution might be perfectly adequate for still images, depending on the ages of the users. Two specifications, under development at Microsoft and by the World Wide Web Consortium, respectively, are SAMI (Microsoft, 1997b) and SMIL (W3C, 1998b). Both provide the means, additional audio, text, or visual objects to a multimedia presentation, offering a technique for captioning and describing multimedia for CD-ROM and Web products.
Improving access to equations and graphs are crucial pieces of making math and science accessible to visually impaired students. Currently, software that presents equations may use any number of ways to display those equations, from a standard character set with an occasional graphic mixed in, to custom fonts, to putting each equation entirely in a graphic. None of these representations can be read by a screen reader, though most can be magnified adequately. Screen readers will not be able to support mainstream math software until that software exposes all equations in a standard way that screen readers can understand. One way to make equations accessible to screen readers involves coding the mathematics using an existing standard, such as TeX, a typesetting standard used widely by mathematicians and scientists, or the emerging MathML specification from the W3C (1998). Whatever means is found for exposing math equations fully, screen reader developers will need to implement ways to interpret this information and verbalize it in a way that is useful to users.
Graphs present a slightly different problem. How can the content of a graph be conveyed to a blind user? One option is to print the graph in tactile form, and recent advances in creating graphical embossers and setting standards for tactile graphing make this possible (Tiger Project, 1997 and VISIONS Lab, 1998). Another possibility is to present an overview of the graph in audio and allow exploration to find the numerical values of important points. We hope that continuing research on both practical methods of producing tactile graphs and innovative ways to present information through audio may lead to increased use of these techniques.
CONCLUSION
Advancing technology gives us opportunities to provide blind and visually impaired students with increased access to math and science education. We hope this overview of the existing problems in math and science software, and some emerging solutions, is useful to parents, teachers, and researchers. We will continue to investigate and try out solutions and hope to have more information to share in the future.
REFERENCES
Microsoft Corporation. December 8, 1997a. _Active Accessibility for Software Developers_ Referenced on March 13, 1998 from the World Wide Web:
http://www.microsoft.com/enable/universal/dev/msaa.htm
Microsoft Corporation. December 8, 1997b. _Making Multimedia Accessible_ Referenced on March 13, 1998 from the World Wide Web:
http://www.microsoft.com/enable/products/multimedia.htm
Sun Microsystems. March, 1998. _Java Accessibility Utilities: Overview of Java Accessibility_ Referenced on March 13, 1998 from the World Wide Web:
http://www.javasoft.com/products/jfc/accessibility/doc/wh at.html
Tiger Project. April 4, 1997. _Tiger Project._ Referenced on March 13, 1998 from the World Wide Web:
http://dots.physics.orst.edu/tiger_project.html
VISIONS Lab. January 28, 1998. _Research Projects._ Referenced on March 13, 1998 from the World Wide Web:
http://www.chem.purdue.edu/facilities/sightlab/research.html< /a>
http://www.w3.org/TR/REC-html40/struct/tables.html
World Wide Web Consortium. January 6, 1998a. _Mathematical Markup Language W3C Working Draft._ Referenced on March 13, 1998 from the World Wide Web:
World Wide Web Consortium. February 6, 1998b. _Synchronized Multimedia Integration Language W3C working draft._ Referenced on March 13, 1998 from the World Wide Web:
http://www.w3.org/TR/WD-smil#h-2
ACKNOWLEDGMENTS
Research for this article was done by the authors and by Rick Ely of In- Vision, Northfield MA, and Brenda Loughery of Pittsburgh Vision Services. This project is funded by the National Science Foundation under Grant No. HRD-9623958. For further information about the CPB/WGBH National Center for Accessible Media or the CD-ROM Access Project, visit our web page at www.wgbh.org/ncam, write to us at ncam@wgbh.org, or call (617) 492-9258 (V/TTY).