When usability expert Jakob Nielsen proclaimed Flash was 99 percent bad, he was right on at least one account: accessibility. Until the release of Flash MX and the Flash 6 player, about 41 million disabled Web users could not take full advantage of Flash Web sites (According to World Bank in 2000). Even with Macromedia's move to support Section 508 guidelines, the government's plan for Web accessibility, the majority of Flash developers have not adopted the necessary best practices.
In previous versions of the Flash player, disabled Web users were unable to view any content generated by Flash. The Flash 6 player took a big step in this regard by retroactively providing text equivalents to the application's content. This change has allowed assistive Web browsers such as screen readers to view or speak Flash content.
Many Flash developers question the need for Flash accessibility since proper accessibility requires a text-only version of existing Web content. This is a myth: images and animation can actually help users with nonvisual disabilities such as dyslexia. Flash can also benefit the blind by incorporating sound to notify the Web surfer of events.
In 1998 the U.S. Congress amended the Rehabilitation Act enacting Section 508. This act required that IT and Web-based solutions used, developed, and purchased by the federal government be accessible to people with disabilities. While this act does not affect private organizations, it has established a set of informal rules for them to adhere to.
For private companies hoping to sell or develop Web applications for the federal government, Section 508 is extremely important. The application must meet these guidelines and possibly pass an automated accessibility test or an inspection in order to be used. All Web developers targeting government organizations should carefully read through Section 508 and attack these issues early in their application design.
One key accessibility add-on to Flash MX is the accessibility panel. This panel provides users with the following six options:
Make Object Accessible: Hides Flash elements like movie clips that do not provide content. This allows assistive browsers to ignore the content.
Make Child Objects Accessible: Hides child elements of Flash object that do not provide content. This includes child movie clips or child images that should be ignored by assistive browser technology. In the case of a text animation, this will prevent screen readers from also reading the animation's text.
Auto Label: Set an automatic name based on what Flash knows about the object. This bases text equivalents off text labels and content within or near the movie clip.
Name: Brief, descriptive text equivalent for the selected Flash object. This is similar to alt text of an image. The name should always be less than 200 characters.
Description: Additional descriptive text if the name box is too small or a longer explanation is required. In this case the name serves as a summary and the description is more detailed.
Shortcut: Assigns a keyboard shortcut to a particular movie clip or button. This allows you to define "Ctrl+P" to screen readers as a quick way to access the portfolio content on your Web site. This defines only the option and will not implement the keyboard shortcut.
You should note that the accessibility panel is only available for buttons, movie clips, and text. Graphics must be converted into a movie clip to apply any accessibility settings.
While key, this accessibility panel is slightly misleading. The panel implies that implementing this with your Flash applications will make your Flash document compliant with Section 508 guidelines. This is false. To make an application accessible, you must consider more than just text equivalent issues.
Flash's accessibility needs closely resemble best practices for HTML Web design. In fact, Flash applications should not only meet Macromedia's accessibility guidelines but also meet W3C Web Accessibility Initiative guidelines. Like building a usable navigation, these principals focus on how to showcase Web content to color-blind Web users or how to provide additional options to senior citizens with poor vision.
Accessibility is a key element of usability. How can a site be usable to Web surfers if close to one-third of Web users can't take full advantage of the content? Here are some Flash accessibility tips for your applications:
Provide descriptive text equivalents for objects using the Flash MX Accessibility panel. It's very important that the text not only describe the image but also explain what selecting the object will do. For example "View 3-D animation of planet earth" as opposed to "earth image" or "click here."
Sound should not compete with the user's screen reader. For many users, requiring a screen reader to view your site background music or event-triggered sounds may make it hard to hear. If your site incorporates sound, provide an option to mute that sound using a blank button and the text equivalent "Turn of all Flash-generated sounds".
Provide alternatives to mouse-based navigation. Some users will rely on a keyboard to navigate through your application, so tab order and key-press events should be used on all buttons.
Avoid color as a primary method of providing emphasis or direction. Color-blind users rely on HTML pages to underline links, otherwise they may not be able to distinguish a link from other text. Flash users should implement similar practices and always avoid text similar to "Select the orange text to proceed" or "View the red text for error information."
It's important to remember that these tips not only affect accessibility but your Flash application's overall usability. For example, providing additional options to mouse-based navigation could save users time and allow them to use their preferred input method, not yours.
When implementing these tips it is also a good idea to understand assistive browsers and how they work with your Flash application. Each technology has a different need and will require your application to excel in a different way.
Some assistive technologies include:
Screen Readers: Text-to-speech technology allows users with visual disabilities to hear the content of a Web site instead of reading it. This technology heavily relies on proper HTML syntax and is forced to read the content of documents from the top down. Main issues with Flash are the use of text equivalents and proper use of audio. Video and informative images should provide alternative links with detailed descriptions of the media content.
Screen Magnifiers: Screen magnifiers allow users with visual disabilities to enlarge content. Since magnifiers rely on the mouse cursor, effects that move the mouse or change the cursor can cause issues with this technology.
Voice Recognition Software: Uses vocal prompts to navigate the Web. The majority of these applications wrap keyboard commands to voice prompts, making a need for <enter> to submit form content and proper tab order very important.
Alternative Input Devices: People with limited use of their extremities rely heavily on keyboard commands to use applications. Alternative input devices like keyboards require needs similar to voice-recognition software.
Validating Flash with HTML tools like Bobby is not yet a reality. To test your Flash application your best shot is to download the latest version of the Flash 6 player and one of the many assistive browser technologies.
In many cases free trials of the software exist that can give you a good idea of what a disabled user may see or hear. By placing myself in their position, I've developed a better understanding of where my personal Web site and Flash applications succeed and fail.
Other manual validation tips are testing the navigation of your Flash application without a mouse and questioning how a color-blind or deaf user may navigate your site. If you find a user must depend on a voice prompt to continue to the next screen, your Flash application is not accessible.
To find links to this technology go to the W3C's assistive browser list.
In addition to these tips, make sure you take advantage of Macromedia's accessibility guidelines, Section 508 guidelines, and W3C Web Accessibility Initiative guidelines. These resources provide invaluable information on the needs of disabled users and how to optimize their user experience.
Ultimately, you will need to decide how much accessibility is enough. I recommend that accessibility be an issue from the sketching phase and that your application focus on at least meeting broad accessibility objectives. By taking these steps you'll find your applications can easily meet the needs of disabled Web surfers without sacrificing much production time.
Jason Michael Perry is a partner in Out the Box Web Productions and the Webmaster for Pan-American Life, an international financial services company. You can contact Jason by visiting Jasonmperry.com. You can contact Jason by email at or by visiting www.jasonmperry.com.
Return to the Web Development DevCenter.
Copyright © 2009 O'Reilly Media, Inc.