Like audio and video, animation is an extremely powerful design resource. Well-conceived, well-executed animations can entertain and inform. They can bring abstract material to life (that's what the term animation means, actually!) and help us understand complex processes that are difficult for most of us to observe firsthand. They can help us understand how things change over time or under certain conditions, and so on.
But animations pose major accessibility challenges, too not to mention the fact that they can create major headaches even for people who don't have disabilities. So, as you would with any other design element, think hard about what you're animating and why animation is the right thing to do. We've all seen too many animations that are more flash than substance (pun intended); make sure yours isn't one of them.
In the following sections, we offer some suggestions about how to anticipate and solve accessibility problems if you do decide to go with animation. We begin by considering the real health risks posed by some moving content and then examine the use of animated GIFs, Flash animation, and other issues.
Blinking, Flashing, and Seizures
As we examine the types of animated content you may wish to include in your Web sites, we can begin by visiting a site that permits free download of animated graphic images. The site shown in Figure 13-9 contains a dizzying array of flashing, moving animations, not one of which has ALT text of any sort. On this page, users can select from a series of horizontal bars that zip across the page. To make that choice, visitors use a mouse pointer that trails fairy dust behind it as it moves across the screen. Yikes! The first choice on the page is a series of multicolored circles that flash in different colors.
Figure 13-9. The Animated Bars and Rulers page of a free clip art site. Accessed January 9, 2002, at http://www.cityweb.co.uk/freegifs/animated/barani.htm. Used with permission.
Most Web users find this sort of blinking, flashing "stuff" annoying at best. But for some users it's much worse than that. You may recall hearing about a television animation in December 1997 that sent more than 700 Japanese children to the hospital with seizures. Without going into too much of the neurology, the fact is that images flickering at certain frequencies can trigger an epilepsy-like response. In the Japanese animation, the lead animated character's red eyes flashed rhythmically for 5 seconds.
Does this mean that animation should be excluded from your Web development tool kit? By no means. In fact, the National Epilepsy Awareness Web site has an animated GIF on every page. (We will look in more detail at animated GIFs in the next section.) Figure 13-10 shows a page that provides links to animations of brain activity during a seizure. The site displays an elegant profile of a grey-haired woman and a picture of a human brain on a swirled purple background. The screen was captured as the pointer highlights a dark purple sphere with three waves, each being traversed by a moving point of light. ALT text tells us that this image is a link to the home page of the site.
Figure 13-10. A page from the site of the National Epilepsy Awareness campaign. Accessed January 9, 2002, at http://www.ucbepilepsy.com/asp/animation.asp. Used with permission.
Certain flicker rates have been specifically associated with in-ducing seizures. This is why Section 508 paragraph (j) is so specific: it forbids blinking and flickering between 2 and 55 Hz (or cycles per second), and WCAG 1.0 makes this a Priority 1 checkpoint (7.1). The United States uses NTSC video signals at 60 Hz. That's faster than Europe and Japan, which both use a 50 Hz cycle. A strobe light at 10-15 Hz can induce seizures in people with a certain genetic makeup. While this is not a common occurrence, it is essential to keep flicker rates in mind if you build animation into your multimedia materials. Give users the ability to pause, resume, and stop playback of your animations. This in turn means using plug-ins that allow users to access these controls. (See Chapter 14 for further discussion of accessible uses of scripts, applets, and plug-ins.) If possible, avoid creating strobe-like effects with rapid alternation between dark and light images. If you must use such effects, alert users that these effects are employed, and let the user control when and whether to view the animation.
As we saw on the National Epilepsy Awareness page, the GIF image format allows a single file to contain multiple images or frames. The file displays the frames one after another, as a loop, creating the effect of a short animation. Animated GIFs are popular on the Web since they are widely supported by most browsers and don't require special programming skills. We assume that you know how to create animated GIFs, so we focus instead on how to use them for maximum accessibility. But if you don't know how to create animated GIFs, many of them are available to download for free from sites such as the one shown in Figure 13-9.
Text Alternatives for Animated GIFs
Sites that provide free downloads of animated GIFs do not, however, customarily provide text alternatives to the animations. You must use the alt attribute to do so. Because images in GIF animations are dynamic, you need to provide a full description of what is occurring. The login page for ITAL's Texas 2000 Living Museum (TX2K), for example, includes an animated GIF, shown in a "suspended" view in Figure 13-11.
Figure 13-11. Screen shot of the TX2K login page. Accessed March 27, 2002, at http://www.ital.utexas.edu/cgi-bin/WebObjects/tx2k. Used with permission.
The ALT text for the TX2K animated GIF provides a simple description of what the animation does. It reads as follows: "Animated curtains unveiling the TX2K logo." Depending on the complexity of the animation, you may use simple ALT text, the longdesc attribute, a text link, or a combination of these to convey the meaning of the animated image.
Macromedia's Flash is among the most popular tools in the Web developer's repertoire. Flash content requires a plug-in and works in any browser that supports Java. It is quite popular and, until very recently, quite inaccessible to blind or visually impaired users. In Flash animations, the content is displayed as an <object> element; in versions up to and including 5.0, there is no built-in way to provide an equivalent alternative without extensive programming skills. (Flash plug-ins up to and including version 5.0 create their own accessibility challenges, which we'll discuss in Chapter 14; here we focus on authoring issues.) Macromedia is aware of the industry trend toward greater accessibility, and the company has entered into partner-ship with the National Center for Accessible Media. Flash MX, the new version of Flash released on March 15, 2002, includes a number of accessibility enhancements, as does the Flash 6.0 player released on the same date. Flash MX is written to conform with Microsoft's Active Accessibility (MSAA), the Application Programming Interface designed to help Windows applications interoperate with AT devices. As a result, versions 4.2 and higher of the Window-Eyes screen reader can report Flash content, including reading the text in Flash movies. (JAWS does not support MSAA in the same way, so there is as yet no JAWS support for Flash.)
Developers now have the opportunity to beta test a tool that employs MAGpie to further improve the accessibility of Flash 5 or MX when played on a Flash 6 player. Jason Smith from the American Academy for the Advancement of Science has created an extension for adding captions to Flash using MAGpie's XML data file. The tool is available for beta testing along with MAGpie and will soon be downloadable from the Macromedia Extension site.
Macromedia acknowledges that there is still considerable room for improvement. We had the good fortune to see the new Flash player and Window-Eyes in action at the 2002 South by Southwest Interactive festival in March 2002 in Austin, Texas, and we want to ac-knowledge here that Macromedia has made a significant move in the right direction. We look forward to continued improvements!
Many thousands of copies of the older, inaccessible versions of Flash are still in use as of this writing, however, and it's still too soon for all the strengths and limitations of the new version to reveal themselves. In the meantime, we have to look for useful workarounds that allow us to use Flash and at the same time make sure that no one is left out of the total experience of our sites.
One Solution to Flash Access Barriers
The ATSTAR project chose to use Flash animation. The designers knew that the teachers taking the course would be doing so between classes, in the middle of a workday, or in short breaks, with the possibility of distractions. The designers wanted to include stimulating visual and audio cues at the beginning of lessons and to emphasize certain points to help busy teachers stay alert to important messages. Figure 13-12 shows an example.
Figure 13-12. The introductory page to Lesson 2 of the ATSTAR curriculum. Accessed January 2, 2002, at http://learning.atstar.org/Lesson_2. Used with permission.
In Lesson 2 of the ATSTAR curriculum, learners are introduced to the first step of the ATSTAR process: Building the Student Team. The wheel spins, showing how the six parts of the process come together to create the whole. Then a particular puzzle piece, the one corresponding to the current lesson, flies out of the puzzle, and words about the learning goals are dynamically generated on the graphic element. Further down on the page is a text link that reads "Description of ATSTAR process animation." Activating that link takes us to the page shown in Figure 13-13.
Figure 13-13. Description of a Flash graphic from ATSTAR Lesson 2. Accessed January 2, 2002, at http://learning.atstar.org/curriculum/frame.asp?surl=learning.atstar.org/Process_Step1.htm. Used with permission.
This page describes the ATSTAR process chart. It consists of the static ATSTAR logo and a headline, "ATSTAR Assessment Process:
Step 1 Building the Student Team," which is similar to the one on the animated page. Users who have chosen to follow the description link can now read the explanation of what the Flash animation demonstrates:
The ATSTAR Process graphic consists of a Flash (tm) animation that presents a wheel shaped chart consisting of six puzzle pieces. These interlocking puzzle pieces describe the six steps of the ATSTAR Process. The process chart is a circle because this is a fluid process, and as it ends, it also begins the next phase as the student grows and the needs change. The puzzle piece for step one animates out to the right of the wheel and describes the sub-steps for Building the Student Team.
The page goes on to describe the other graphic elements of the animated process chart, then provides a link to "Continue with Lesson."
The strategy described above is only one way to work around the accessibility problems that Flash poses. There are other, more elegant solutions. It is quite possible, for example, to integrate the text description of the ATSTAR process wheel on the same page where the flowchart appears. In that way, the description would be immediately available to all users without requiring them to follow the link, and our experience suggests that this would help many people not just people with disabilities understand the animation more fully. Using that solution in this case, however, would have violated the ATSTAR goal of minimizing the need for scrolling, which serves a different accessibility purpose (scrolling can be confusing for people using screen magnification software and tiring for those with limited hand mobility).
A third solution would be to integrate a JPEG or GIF version of the ATSTAR process wheel into the <object> element itself, coupled with the text description. The static image would be visible only to users who don't have Flash installed. This would not require any additional programming by the developers the <object> element is set up such that the browser renders whatever it's capable of rendering. The browser displays the Flash movie if Flash is installed but displays the alternative provided (text, GIF, JPEG, and so on) if Flash is not available on the user's machine. An animated GIF depicting a simplified version of the process wheel could then be provided as the alternative. The simplified GIF animation would therefore be dis-played with appropriate text from the alt and longdesc attributes for users who don't have Flash. Unfortunately, this last approach won't help people using computers on which Flash 5 (or an earlier version) is installed in school computer labs, for example, or public libraries. In such cases, the best approach is probably the one we described first: include an extended text description in addition to the Flash animation.
Adding ALT Text to Embedded Objects
Here's an illustration of what we mean. It is common for many sites to include a Flash movie that plays beneath the central image on the screen. The movie may consist of text, including links to other parts of a large site. The following code sample shows how to include alternative text within the <object> element. (Our thanks to Jim Allan for this solution.)
<object classid=clsid:D27CDB6E-AE6D-11cf-96B8-444553540000 codeBase=http://active.macromedia.com/flash2/cabs/ swflash. cab#version=4,0,0,0 height=48 id=ma_scroller width=212><param name="movie" value="http://www.maxaccess.com/ma_scroller.swf"> <param name="menu" value="false"><param name="quality" value="autolow"><param name="salign" value="LT"> <param name="bgcolor" value="#445436"> <p><ul><li> <a href="http://www.maxaccess.com/accessibleFLASHdemo1/"> About Us </a></li><li> <a href="http://www.maxaccess.com/accessibleFLASHdemo2"> News </a></li><li> <a href="http://www.maxaccess.com/accessibleFLASHdemo3"> Shop Online </a></li><li> <a href="http://www.maxaccess.com/accessibleFLASHdemo4"> Contact Us </a></li></ul></p> <noembed><img src="/books/3/135/1/html/2/http://www.maxaccess.com/media_images/ ma_scroller.gif" width=212 height=47 order=0> </noembed></object>
The code creates a list of links centered on the screen at the location where the Flash movie will play if Flash is installed. The links are displayed only if Flash is not installed on the user's computer. The same technique could also be used to display a static image, such as a GIF or JPEG, in place of a dynamic or static image done in Flash. This works because the browser "looks at" the content of the <object> element and renders the first thing it's capable of rendering; since it can't display Flash movies without Flash, the browser will keep looking until it finds the HTML text or some other element it knows how to render.
(The Macromedia Flash Accessibility site offers a downloadable extension, called the Accessibility HTML Publish Template, that is supposed to accomplish something very similar to what we've shown above.)
Adding Accessibility Features to Flash Movies
The techniques we've just shown you work only for users who don't have the Flash player installed on their computers. But it's also important to take steps to make Flash movies themselves more accessible to people who do have the Flash player. After all, where accessibility requirements are concerned, Flash movies are no different from any other kind of video or animation, and the same requirements apply. WCAG Checkpoint 1.4 puts it very clearly: "For any time-based multimedia presentation (e.g., a movie or animation), synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track) with the presentation. [Priority 1]" (emphasis added).
You can do a number of things to fulfill these requirements. None of those options is fully satisfactory, perhaps, but they may be better than nothing. Let's start by talking about adding limited key-board accessibility to pages that include Flash movies and then go on to discuss adding closed captions and audio descriptions.
Adding Limited Keyboard Accessibility. Flash presents some very real challenges to people who navigate the Web exclusively via the keyboard, including people who are blind and people who use a wide variety of alternative input devices that "map" onto the keyboard (that is, devices that translate user actions into keystrokes, so that the application behaves as if the user had pressed those keys). But within limits, there are things you can do to add some keyboard accessibility to Flash presentations. Basically, you have to follow two steps.
In HTML, add an accesskey attribute to the <object> element that contains the Flash movie. For example, if your source document includes the code <object accesskey="z">, then users can press Alt+z to jump directly to the Flash movie.
Add keyboard equivalents to the Flash movie itself, using the techniques described on Macromedia's Flash Accessibility site (http://www.macromedia.com/macromedia/accessibility/). At a minimum, you should include keyboard equivalents for starting, pausing, and stopping the movie. (For a demonstration of these techniques, visit the WebSavvy site at http://www.Websavvy-access.org.)
This approach has serious limitations, unfortunately, so adding these keyboard equivalents doesn't automatically solve all your accessibility problems. For one thing, the accesskey attribute works in Microsoft Internet Explorer 4.0 and higher, but for Netscape Navigator, it works only in version 6.2 or later. And in Internet Explorer, users who use the keyboard to get into the Flash movie and to start, pause, or stop it can't use the keyboard to get back out of the movie to the rest of the page!
(It appears, however, that the JAWS Links List is still available. Thus a JAWS user who found him- or herself seemingly stuck in a Flash movie could press Ins+F7 to bring up the Links List, then select the "Skip to main content" link to jump back up to the top of the page. Of course, the user would have to know that this technique was available and there would have to be a "Skip to main content" link on the page. And, even supposing both of these conditions hold, the user would have to be willing to listen to the page again, from the top, in order to get to the material that follows the Flash movie. This user is unlikely to be a very happy camper. . . .)
Adding Closed Captions for Flash. Like the video presentations discussed earlier in this chapter, many Flash movies include high-quality audio as well as graphics and animations. You can use Flash's audio facilities to include audio descriptions of the objects and events taking place on the screen, as well as other audio material. If you prefer, you may add a second track for the audio description, using SMIL. You can also include closed captions for all audio material that is part of your Flash movie.
A group called WebSavvy part of the Adaptive Technology Resource Center at the University of Toronto, a leading accessibility research group has created an impressive demonstration of closed captions for the soundtrack of a Flash movie. Like the captions for the ATSTAR video we discussed earlier in this chapter, the captions are included in a RealText file. An SMIL file coordinates the Flash movie, the captions, and an audio track. The WebSavvy site provides instructions for viewing the SMIL source as well as a link to the RealText file that contains the captions. The end result is displayed in RealPlayer. (See http://www.Websavvy-access.org/resources/real_demo.shtml.)
Adding Audio Descriptions. Earlier in this chapter, we explained how we added an audio description track to a video presentation about ITAL's TX2K project. You can use those same techniques, with appropriate modifications for a different media type (animation instead of video), to synchronize an audio description with a Flash animation.
The RealPlayer G2 Production Guide provides detailed information about how to include Flash movies in an SMIL presentation that will be displayed using RealPlayer 7 or higher. (See http://docs.real.com/docs/smil/prodguideupdateg2_7.pdf.)