Flash is an amazing type of tool for creating fancy, engaging websites. It provides a setting where one can create just about any kind of effect - flying through stars, doors opening into rooms, even entire games are written/developed in it.
At last, this rich media medium has taken shape to offer persons with visual disabilities access to the web using either Window-Eyes from GW Micro or JAWS from Freedom Scientific because of new integratation with Microsoft Active Accessibility (MSAA) technology.
Support for Microsoft Active Accessibility (MSAA) allows assistive technologies to access the contents of a Macromedia Flash movie. This means that text content, buttons, input text fields, movie clips, and even entire movies can be made accessible to screen reader users. In addition, a new panel has been added to Flash 8, called the Accessibility panel. It provides designers the ability to include a text equivalent for a single element (such as a button) or for a group of elements (such as a series of animated images, like planets wizing by in space).
Flash 8 also makes it easier to assign a specific reading order for content. Designers can specify values for the relevant objects on the screen. Flash player will reorder the objects into the desired reading order.
The Macromedia Accessibility Resource Center also provides a number of documents offering tips and techniques for designers to help them create accessible Macromedia Flash content. Topics include adding text equivalents in Macromedia Flash, working with buttons, accessibility hints, adding animation, Frequently Asked Questions, ActionScript and accessibility, and captioning in Flash 8.
Checking Flash Accessibility
Is there a tool, like the ones for HTML and Style Sheets, to validate Flash as accessibility compliant?
Not yet. Flash content is inherently more complex than HTML. As such, it is more difficult to construct measurable rules and even more difficult to validate those rules. For example, Section 508 and W3C require that a text alternative be provided for all images in HTML. In cases where the image contains no content (for example, it’s a picture of something, rather than a snapshot of a table of data), a special alt tag is used to hide the image from a screen reader. In Flash 8, text equivalents are not needed for all elements of a Flash movie. Using an autolabeling feature, text equivalents are automatically provided for several elements. Flash 8 also allows access to features such as content magnification, mouse-free navigation, sound synchronization, and custom color palettes.
But sadly, some Flash content will not be accessible using the current Flash Player. Such content includes dynamic text variables and custom navigational elements. Examples would be a text box that changes its contents (like a game score) as the person plays the game.
Specific Design Tips
Provide names for graphic icons.
Use text equivalents for animations that highlight or direct a person to a specific area of the page. When you use a feature like Break Apart for text, be sure to provide a name or description. When a group of related graphics are used to convey a single idea, provide a single text equivalent and make the child objects inaccessible. For example, if you had a set of planets floating around the screen, provide a single description such as “The known planets of our solar system in orbit around the sun.”
Make Looping Elements Inaccessible
Movies that loop (replay themselves) cause screen readers to refresh frequently. Even in cases where the movies are at the bottom of a page, the screen reader can interpret motion as an update to the page and return to the top and start reading again. What a nightmare for your end user! Thus child objects of movie clips or entire movies should be marked inaccessible.
Allow Users to Control Motion
Mind your speed of animation because screen readers may have a difficult time keeping up with quick changes in a Flash movie. If its important information, let the user control the timing of new information being presented by adding Next buttons that control movement.
Also, when adding buttons and other controls, make sure that users can navigate using only the keyboard. To provide keyboard access, keep scripts within frames as opposed to attaching them directly to objects. Avoid using empty movie clips as buttons too because these clickable or ‘hit areas’ are not recognized by screen readers. But most effective is if you add keyboard shortcuts to commonly used buttons to facilitate access.
Audio
It’s important when delivering narrative audio to provide captions at the same time. Captions can be delivered using any of 3 methods.
Remember too that music and audio that plays as a move loads can be a problem for screen reader users. Audio from a Flash movie can interfere with the end users ability to hear the contents of a movie using a screen reader (it could play overtop of the voice of their screen reader, so then they can’t hear what’s on screen!). So it’s important to make sure that control over when music is played is provided to the user. Just make sure you provide the end user with a play and pause button to manage that extra audio from your site.
Explain the State of a Control
For all controls, its very helpful to provide the user with feedback on the control as it changes. As the state of a button changes, the accessibility information for it should be updated as well (indicating to the screen reader “button down” or “button selected”).
TEST it!
Try accessing your flash content using screen access technologies such as Window-Eyes from GW Micro. That will provide the best insight into the usability of a movie for screen users. Also, test your site using only the keyboard without a screen reader running as keyboard access differs when a screen reader is not present.