Go to previous article
Go to next article
Return to 2004 Table of Contents
63 Chapel Street
Newton, MA 02458
Phone: (617) 964-1111
Senior Product Manager for Accessibility
4110 Birch Street
Madison, WI 53711
Phone: (608) 238-6747
This paper reviews the techniques and technologies used in implementing a series of electronic textbooks (iTexts) for middle school students built in Macromedia Flash MX. These iTexts are used in middle school classrooms throughout the country. In an effort to meet its ongoing commitment to students with disabilities, Pearson Education asked the developer, 360KID, to ensure that the electronic version of the text was accessible. After reviewing the available technologies for delivery of multimedia content, security and accessibility, 360KID suggested a Macromedia Flash based approach. The final result was a dynamic web application that relied on the use of XML to provide a flexible and engaging user interface that was interoperable with a variety of assistive technologies. This paper looks at some of the specific challenges and techniques used. In addition, this paper outlines some of the challenges for Flash based electronic textbooks to be addressed in future projects.
Controlling Reading Order
Perhaps the single greatest challenge for the developers at 360KID was handling the default reading order in Macromedia Flash MX. The default reading order of Macromedia Flash content is difficult to understand. When read using a screen reader, the content does not move in an orderly fashion from left to right and top to bottom. Instead, it jumps between different elements on the stage. Given the complexity of the content presented and its dynamic nature, using ActionScript, as is generally recommended by Macromedia, was not possible. 360KID developed a new technique that first detected for the presence of a screen reader and then placed a redundant copy of the text off stage. The off stage content was then placed in a single column of text. When the on stage content was rendered inaccessible, the content read in a predictable and orderly fashion. Given the simplicity of this technique, it allowed the developers to focus on usability issues for screen readers users without altering the use case for people who do not rely on screen readers.
At its inception, Macromedia Flash was first and foremost a tool for animation. While the uses of Flash have since become quite varied, it is still quite common for elements of a Flash movie to be animated. In developing this textbook, 360KID (hand to content ? had to develop content?) with at least three issues presented by animations in Macromedia Flash movies.
First, screen readers are not able to distinguish between changes to the screen that are initiated by the user and those that are not. A simple animation on screen can be interpreted as a continuous stream of user events. This will cause some screen readers to constantly return to the top of the page to read the entire page again. Take the simple example shown below. It shows a frame from an animation of a moon orbiting a planet. To prevent the movement on the screen from sending numerous or constant repetitive events to the screen reader, the developer had to make child objects accessible for all movie clips that contain animation inaccessible using ActionScript.
Second, animated elements that display constant motion can serve as a distraction for people with certain cognitive disabilities. Given that multimedia was often embedded in pages of text the user is expected to read, all motion on the page had to be controlled by the user.
Third, 360KID had to be careful to avoid the use of blinking elements in their Flash movies. Elements that blink within a certain range can trigger photo-sensitive epilepsy in some people. Given that the rate of blinking is difficult if not impossible to predict, it is best to avoid the use of blinking elements altogether.
This textbook relied on the video capabilities of Macromedia Flash to deliver short video in support of concepts presented in the text. This text used a captioning tool from WGBH called MAGpie to generate an XML file with a text equivalent for the audio tracks. This XML data was then streamed to the Flash movie synchronized with the video on the fly. This allowed the developers to separate out the development of the captioning effort from the design work itself. For more information on captioning in Flash, see: http://ncam.wgbh.org/webaccess/magpie/magpie2_captioner.html
Ensuring Keyboard Access
Another particularly difficult challenge in this project was ensuring keyboard access to navigation and other controls within the textbook. Given the complexity of the text and the large number of controls on screen at any given point in time, it was important to allow users to quickly move back and forth from the navigation. This allowed users to skip over navigation when they arrived at a destination page or jump back to the navigation if they needed to revisit a page elsewhere in the text.
Buttons and Forms in Macromedia Flash Player
By default, the Macromedia Flash Player makes buttons available to assistive technology. With a screen reader, the sample button below would be read as follows. First, the word 'button' is read to provide a cue to the user that there is an action associated with this element. Next, the text equivalent is read to the user-in this case, the word "home." Finally, the user may activate this button by pressing Enter on the keyboard.
As with buttons, Window-Eyes users are also notified of form fields. In the example below, the screen reader might read, "Electronic Registration. Edit Box: Name. Edit Box: Address. Button: Send."
Separating Navigation and Content
In order to separate out the navigation and content elements on the screen, these elements were placed in separated Flash movies and then in separate frames within the HTML. This allows the user to jump between these elements quickly. Yet this technique presented some particularly challenge circumstances in terms of how controls in one frame pass data to Flash movies in other frames. In addition, it required the developers to build in a set of keyboard shortcuts to further facilitate the operation of the text.
The trade off represented in building in these controls was that it inherently required the user to learn these keyboard shortcuts. Every effort was made to limit the number of new keystrokes required of the user. On the other hand, the textbook can be operated with relying on the use of keyboard shortcuts, but requires a significantly greater number of keystrokes. The balance between creating an application that follows familiar keyboard conventions and creating an application with easy access to areas of textbook is a delicate one. Given the fact that students would be using this same textbook over an extended period of time, they would initially rely on more familiar techniques initially and over time develop a familiarity with the keystrokes used in the application.
One common technique is to place text and graphics in the down state of a button in Macromedia Flash MX 2004. When the button is pressed, the text and graphics are revealed. The Macromedia Flash Player does not expose the contents of the down state, except for a single text element. Navigational cues, menu bars, and other content are not made available using this technique.
Another common technique among Macromedia Flash designers and developers is the use of invisible buttons placed over a background with text. This practice is discouraged for accessibility purposes. The Macromedia Flash Player notices only buttons that have content; thus, invisible buttons are not made available to assistive technologies.
Notes on Keyboard Shortcuts
The keyboard shortcut field on the Accessibility panel allows designers and developers to add keystrokes to individual buttons and form elements. To provide a keyboard shortcut, ActionScript must be used to detect keypresses by the user during movie playback. (For more information, see "Capturing keypresses" in Macromedia Flash Help.) Keyboard shortcut functionality also depends on the assistive technology and software used.
For keyboard shortcuts, use the following conventions:
As with complex web applications written in HTML, it is important that applications written in Flash provide some context to the user in terms of understanding the available content, controls and shortcuts used. In this case, this information is provided in the form of a link to a page that provides users with instructions on how to use the application, a list of shortcuts and a link to inquire about issues and concerns. The link is hidden away in the form of an invisible button at the top of the page and a visible link further down the screen.
Accessibility: Macromedia Flash MX Features (n.d.) Retrieved September 30, 2002 from Macromedia Accessibility Resource Center website. http://www.macromedia.com/macromedia/accessibility/features/flash/.
Heins, J. & Regan, R. (2002) Building Standards Conformant, Accessible Learning Objects with Macromedia Flash MX. Retrieved from http://download.macromedia.com/pub/solutions/downloads/accessibility/fl_learning_obj.pdf.
Regan, R. (2002) Accessibility and Macromedia Flash in Thatcher, Regan et al Constructing Accessible Web Sites. Birmingham, UK: Glasshaus.
Regan, R., Kirkpatrick, A., & Pinch, P. (2002) Think Accessibility in MacGregor, C. et al The Flash Usability Guide: Interacting with Flash MX. Birmingham, UK: Friends of Ed.
Section 508 Standards (n.d.) Retrieved September 30, 2002 from Section 508 website. http://www.section508.gov/index.cfm?FuseAction=Content&ID=12.
User Agent Accessibility Guidelines 1.0 (August, 2002) Retrieved September 30, 2002 from W3C website. http://www.w3.org/TR/UAAG10/.
Web Content Accessibility Guidelines 1.0 (May, 1999) Retrieved September 30, 2002 from W3C website. http://www.w3.org/TR/WCAG10/.
Go to previous article
Go to next article
Return to 2004 Table of Contents
Return to Table of Proceedings