Go to previous article
Go to next article
Return to 2004 Table of Contents
Christopher Blaire Bundy
University of Wisconsin-Madison
In the College of Engineering we have used the web as the sole means of providing lectures in a large undergraduate class for four years. This class is taught on campus, and students meet with their professors in hands-on labs each week, but they never meet in a lecture hall. Instead, students view the lectures on computers located either in campus labs or in their own dorm rooms and apartments. Lectures include video and audio of the professor giving the lecture, animated PowerPoint slides, an interactive table of contents, links to other materials on the web, and various navigational controls. We built our own software tool called eTEACH for creating and delivering these lectures.1 At the University of Wisconsin-Madison, eTEACH lectures have replaced traditional lectures in classes in such diverse departments as Computer Sciences, Nuclear Engineering, Nursing, and Business Education.2 We have been meeting the needs of deaf students for several semesters by providing closed-captioning with all our lectures. Recently we have taken on the much more challenging task of making these lectures accessible to other student populations, including screen reader users. This paper describes some of the difficulties that we faced, and the solutions we eventually found. We hope that our experiences can benefit others who may be faced with similar challenges in making or acquiring multi-media materials accessible to a diverse audience.
2 Problems and Solutions
2.1 Limitations of Standard Techniques
Students view eTEACH lectures in a web browser, so we began our work by implementing standard accessibility procedures such as providing ALT attributes for images and TITLES for frames, etc. However, when we presented our tool to a blind student, who is an expert at using the screen reader JAWS, he was unable to make much sense out of the material - without sited guidance. To comprehend a multi-media lecture, blind users must use audio for three different purposes:
We quickly learned that viewing eTEACH lectures is a much more complex task than viewing simple web pages containing static text, graphics, and links. All of the media - video, audio and images, contribute significantly to the "lecture experience" and often contain important parts of the information being presented by the lecturer. Because audio and video are time-based media and the PowerPoint slides and animations are coordinated with the audio and video, timing is a significant issue. For example, a "play/pause" button might be made accessible, but if the access method is slow and awkward, the student who wants to pause the audio to "read" the text on a PowerPoint slide may be unable to do so before the slide changes. Also, students need to be able to navigate within a lecture using a table of contents and other controls. While JAWS was able to read the table of contents, it failed to recognize that the lines it was reading were effectively links to other parts of the program. We also found that JAWS would frequently switch its focus to the control panel and start describing the buttons in the video control panel for no apparent reason.
Even after considerable coaching by sighted users, our test student was unable to make much sense of the lecture material. Our conclusion was that even though we had already met the campus web accessibility guidelines, considerable more work would be needed to make our product useable by screen reader users. However, this was the first time that the eTEACH developer had seen a screen reader in use, and he was astounded by the speed and facility with which the blind student could operate his computer. The developer became convinced that with appropriate changes, eTEACH could be made usable, and was determined to succeed.
2.2 Experiences with Home Page Reader
We decided to attempt making eTEACH accessible using both Home Page Reader (HPR) and JAWS. We quickly learned that users of different assistive technologies encounter different problems in accessing our application. We were at first surprised to learn that while HPR could read the ALT attributes associated with images like the "play/pause" button, it provided no way to generate a mouse click on those images. Likewise, while it could read the text in the table of contents, the user could not send a mouse click to the table of contents. Finally, we were dismayed to learn that while we could program Internet Explorer to respond to keystrokes, HPR captured the keystroke commands before IE could see them. We put buttons on the PowerPoint to overcome this barrier.
After completing these changes we determined that our application was accessible inasmuch as an HPR user could locate and activate all the controls that are available to sighted users. Unfortunately, serious issues with timing and usability remained. Users need to control what gets spoken when, and should be able to either hear the slide first or the audio first and switch between the two at will. We determined that moving between the slide frame and the control frame was too slow and awkward. We also realized that having the slides change automatically was a problem since they were likely to change while the student was listening to the lecturer, but before the student had directed the screen reader to speak the PowerPoint. We created a "screen reader mode" for eTEACH. In this mode audio pauses automatically at the beginning and end of each slide. We then changed our application so that it would place "play/pause", "next slide", and "previous slide" buttons right on each PowerPoint slide. This makes navigation quick and easy for blind users. We did not change the interface for sighted users as the additional buttons are hidden in a layer behind the normal PowerPoint slide.
2.3 Experiences With JAWS
We then returned our attention to JAWS, which is far more flexible in how it reads and interacts with applications, but that flexibility comes at a price. JAWS scripting is often required to access the features of a particular application. Therefore, the eTEACH developer set about learning enough JAWS scripting to program JAWS to work smoothly with eTEACH. We found that screen reader mode and providing convenient access to frequently used functions like "play/pause", "next slide", and "previous slide" which we had already developed for HPR were also very useful for JAWS users, but with JAWS we were able to implement these functions as simple keystrokes. We were also able to implement additional helpful keystrokes and prevented it from randomly reading off the names of the video controls.
2.4 Non Screen-Reader Specific Problems
We also found several problems that are not specific to any adaptive equipment. We have solutions for some, but not all of these problems. One such problem is due to the built-in volume control implemented by eTEACH. We found it necessary to defeat this function so the eTEACH and screen reader volumes would match. Another problem we found is that some of our material included slide changes in mid-sentence. This was never a problem for sighted users, and seemed appropriate in some cases, but when the program pauses at the beginning and end of each slide, it becomes both annoying and confusing. We will consider this problem when creating future materials.As with other content authoring tools, many decisions are under control of the course designer. While eTEACH supports accessibility features, it is still possible to include images without accompanying descriptions and other non-accessible items. Thus, in honesty, we can say that our application is accessible, but some content may not be.
eTEACH is not the only multi-media tool available for delivering educational lectures to a student's computer. Unfortunately, many of the applications we have seen do not even implement closed-captioning for deaf students, much less advanced accessibility techniques for the blind. We think that the changes we have implemented do provide an accessible multi-media lecture tool for both deaf and blind students. This should serve as a proof of concept for other software developers who may question whether such applications can ever be made accessible. We hope that our experiences and the techniques we have employed will shed some light on how to go about tackling such a project.
Litzkow, Julie Foertsch, John Strikwerda, November 2002, 32nd ASEE/IEEE Frontiers in Education Conference, 6-9 November 2002, Boston MA.
Go to previous article
Go to next article
Return to 2004 Table of Contents
Return to Table of Proceedings