Web Posted on: February 24, 1998
Multimedia: Making it Accessible to Blind Users
Madeleine Rothberg
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
tom_wlodkowski@wgbh.org
Web: http://www.wgbh.org/ncam
1. Introduction
The CD-ROM Access Project focuses on making multimedia software accessible to blind and visually impaired users. The goal of this three year project, funded by the National Science Foundation, is to develop and disseminate guidelines that allow software publishers to create truly accessible products. Although the main goal of our project is improving the accessibility of math and science multimedia, the majority of the guidelines will apply to all multimedia titles, especially for navigation and for making content such as video and still images accessible.
This project is divided into three components. First, we analyzed the usability of some of the more widely used science and math CD-ROMs with a variety of screen readers and magnifiers. Now, in the prototype phase, we're working on incorporating various access solutions into select elements of specific products. In the final phase, we will develop design guidelines and disseminate them to mainstream software developers.
To understand how existing multimedia performs with a variety of access software we tested sixteen of the most widely used science and math CD-ROMs. We developed a survey tool to ensure consistency and used it to test each piece of software with three screen readers (JAWS for Windows 95 version 2.0, Screen Power for Windows 95 version 3.0 revision C, and outSPOKEN for Macintosh version 1.7.5) and two screen magnifiers (LP Windows version 6.1, and inLARGE version 2.1).
Below we will explore in greater detail some of our findings and outline some proposed solutions to make multimedia more user-friendly to blind and visually impaired users. One important idea is that users should be able to set preferences to inform programs that they need non-visual information. A simple checkbox in the program's preferences or options should control this. By expanding the number of preferences they provide, programs can customize their delivery for users with a variety of needs, including deaf users as well as blind and visually impaired users.
2. Navigation and Controls
Nonstandard design is one of the major factors contributing to the inaccessibility of the majority of the multimedia products on the market today. Nonstandard menu bars, custom designed on-screen controls, and lack of a keyboard interface make navigating through a piece of software virtually impossible for many blind people. In many cases, users of screen readers are lucky if they can get beyond the opening screen of a product without seeking sighted assistance. Users of screen magnifiers usually enjoy more success with a piece of software but nonstandard design and lack of keyboard access still impact the usability of the software.
There are several steps product developers can take to improve navigation. Implementing a keyboard interface is crucial. Keyboard equivalents for all essential controls (such as a keystroke to start and stop a movie clip or a simulation) and for navigation through forms (such as use of the tab key to move from an edit box to a search button) reduces the need for the user to hunt for controls. Use of a standard menu bar is also important.
With a keyboard interface in place, the user still must be able to identify objects on the screen. A readily available method to achieve this goal on the Windows 95 platform is Microsoft's Active Accessibility (MSAA). MSAA allows "applications to actively cooperate with accessibility aids, providing information about what they are doing and the contents of the screen." [1] In order for MSAA to be helpful, the user must have an MSAA-capable screen reader or magnifier. Similar work is underway at both Microsoft and Sun to improve access to Java-based applications.
3. Multimedia
For a multimedia program, such as an encyclopedia or a science lesson, all of the navigation issues described above apply, but content-specific multimedia solutions are needed also. Additional description to enhance an interactive program can be added in audio or in text. Developers could include an additional set of audio files with more detailed information for visually impaired users. This information should also be provided in text for people using Braille displays. If audio files take too much disk space, text only can be provided.
A variety of techniques can be used to provide descriptive audio or text. QuickTime, a multimedia format developed by Apple, allows multiple text and audio tracks to be synchronized with a video or audio clip. Synchronized Accessible Media Interchange, called SAMI, provides a similar solution for Microsoft's video format. And efforts at the World Wide Web Consortium have led to the specification of Synchronized Multimedia Integration Language (SMIL). All of these formats provide features that developers need for effective multimedia presentations, and also provide tools for making both CD-ROM and Web-based multimedia accessible. An important feature of these formats is the ability for users to turn on and off the different components. This provides "closed" captions and descriptions, shown only to users who want them.
At WGBH, Descriptive Video Service(R) provides descriptions for television and movies. Working with them, we will develop a style for describing still images as well. Description text can be made available to a screen reader user by displaying it on screen or by sending it directly to the screen reader. Displaying descriptive text on screen also has the advantage of making it accessible to magnifier users who don't use synthetic speech. One drawback, however, is that it may obscure other parts of the interface that the user may need to access.
4. Problems and Solutions
A. Screen Readers
Our analyses have highlighted several problems specific to science and math software. These problems include the following:
A.1. Equations
Conventional screen readers cannot consistently interpret mathematical expressions. Math formulas are often read without the math symbols, including minus signs, parentheses, and superscripts. This is especially problematic for higher level math products (Algebra and beyond).
Although there are no readily available solutions for all platforms at the moment, there is ongoing work to improve access to equations. One tool is AsTeR, the Audio System for Technical Reading developed by T. V. Raman. AsTeR converts LaTeX documents into speech, including complicated equations. [2] Another possibility is to enable the user to enter and edit equations aurally. A model for this concept exists in MathTalk, an application based on the MathType equation editor, which allows a user to voice an equation, then reads the entry back in synthetic speech. [3] Regardless of what equation voicing solutions are used, one essential ingredient for improving access to equations is for publishers of math software to create and adhere to a standard for exposing equations. During this project we will follow projects like AsTeR and MathTalk and advocate for standards with software publishers.
A.2. Graphs
A related problem is the need for a blind user to be able to examine a graph of an equation included in the software or generated by the user. Once again, there are no readily available solutions. Currently, a publisher can contract with a provider of Braille services to generate tactile versions of all graphs included in the product, but this doesn't help with newly created graphs. One possible solution is a tool like DotsPlus, now under development by John Gardner at Oregon State University. DotsPlus is a specially designed font set for printing technical information in Braille by incorporating "Braille and graphics in an integrated fashion." [4] The user would need a specially equipped Braille embosser to print DotsPlus. There may also be ways of presenting graphs via audio which we will explore.
A.3. Tables
The use of tables with a screen reader is extremely difficult. In many cases, the screen reader cannot locate the text entry cursor which leads to inaccurate data entry. The inability of the user to quickly find column headings and obtain exact cell locations makes determining the relationship between certain pieces of data inefficient and hence the intended value of the table is lost.
Access to tables could be vastly improved if software publishers developed standards for table design. Simple modifications such as exposing the text entry cursor and implementing a "Go to" command enabling a user to go directly to a particular cell would make a significant impact. In addition, if the structure of a table is exposed to a screen reader, in a format like HTML 4.0 table markup, [5] the screen reader could then provide information about each cell's headers along with the data content of a cell. This would require screen readers to add additional functionality, but could greatly improve the usability of tables for blind users.
A.4. Simulations
Simulations, such as lab experiments, present the screen reader user with many challenges. In some cases on-screen controls are inaccessible. Navigation through the simulation sometimes causes unintended interactions as the user tries to use basic screen reader navigation keystrokes. Finally, most simulations are entirely visual and even if the user can navigate and access the controls, the information being conveyed is still lost.
These barriers can be lowered by improvements in product design. Implementation of MSAA, for example, could make simulation controls available to the screen reader. Enhanced keyboard access would allow the user to freely navigate within the simulation without relying on the screen reader. Descriptive text, enhanced audio feedback and audio description are some of the methods we'll explore to make the content of a simulation accessible.
B. Screen Magnifiers
Users of screen magnifiers, in addition to struggling with some of the issues above, have unique problems which are described here.
B.1. Contrast
Most software overrides system settings for text and background color to present its own vision of the interface. For visually impaired users this can create problems, since some people have trouble seeing certain colors. For example, blue text on a gray background may be fine for some users but invisible for others because the contrast is not strong enough. The inversion features of some screen magnifiers can compensate, but the inverted colors may be equally low in contrast. A related problem is caused by text shown over a patterned background. The background rarely conveys much information, but it can make reading more difficult.
Software designers can solve these problems in two ways. One is to evaluate the color contrast of all screens so that only legible color combinations are used. This can be difficult because of the range of problems users may have and because designers like to use a variety of colors to make an attractive product. More likely to be successful is a program that accepts the user's own color preferences or the "High Contrast" setting, for example, as defined in Windows 95. Programs can also offer a preference within the software for users to choose text colors. By drawing all product text in the user's colors, when specified, software can show mainstream users the original design while low vision users get more appropriate colors. In addition, software should allow users to remove distracting background graphics and present text and important graphical information against a plain background.
B.2. Text Quality
Text can be displayed in two ways. Title screens, buttons, and sometimes entire products can be presented as "bit mapped text," which means that the program loads a graphic in which the text has already been drawn. This text cannot be read by screen readers and often does not magnify clearly - the edges of lines are often blurred when enlarged. The other method is for text to be presented in a font so that screen magnifiers can effectively enlarge them for visually impaired users. Software can draw text in decorative fonts and colors to give the product a unique look. If this text is then modified to the user's choice of font and color both mainstream and visually impaired users can read it.
B.3. Focus Tracking
Effectively moving through a piece of software when it is enlarged requires following the focus of the program. Magnification software generally tries to follow the focus as the user works. When an action in one part of the screen causes changes in another part of the screen, the user may not be aware of it if the focus doesn't move to the new information. On the other hand, some software moves the focus to an unneeded part of the screen every time it is changed, such as focusing on a status bar every time the cursor position is changed and the status bar updates.
These problems require a balanced solution. The cursor or other focus indicator should always move to the most relevant part of the screen. Software that makes the standard system cursor invisible and draws a cursor of its own should always drag the system cursor along to provide focus. But when the focus moves too much, a preference to disable the distracting screen updates may help. For example, a status bar can be turned off when it is not needed, or "tool tip" text that pops up when the user places the mouse on an object can be optional. (The text of the tool tip should still be exposed by MSAA or similar means so that the assistive technology can present it to the user.)
5. Conclusion
Recent advances in screen reader technology have made graphical user interfaces somewhat accessible to blind and visually impaired users. With ongoing research, more gains are expected for the future. Making math and science materials accessible to all users is crucial; we hope to report further solutions in the remaining two years of the CD-ROM Access Project.
6. References
(1) Microsoft Corporation. Active Accessibility for Software Developers. December 8, 1997. Online. Available: http://www.microsoft.com/enable/universal/dev/msaa.htm
(2) Raman, T.V. Mathematics for Computer Generated Spoken Documents. August 10, 1994. Online. Available: http://simon.cs.cornell.edu/Info/People/raman/aster/aster-toplevel.html
(3) MathTalk(TM) - The Voice Activated Math Program. March 27, 1997. Online. Available: http://www.metroplexvoice.com/math.htm
(4) Gardner, John A. DotsPlus - Better than Braille? September 23, 1997. Online. Available: http://dots.physics.orst.edu/publications/csun93.html
(5) Vanderheiden, Gregg, Wendy Chisholm, and Ian Jacobs, Editors. WAI Accessibility Guidelines: Page Authoring, W3C Working Draft 03-Feb-1998. February 3, 1998. Online. World Wide Web Consortium. Latest version available: http://www.w3.org/TR/WD-WAI-PAGEAUTH