Flash Article

Flash 8 Best Practices

Guidelines for Accessibility in Flash

Screen readers are complex, and you can easily encounter unexpected results in FLA files developed for use with screen readers, which is software that visually impaired users run to read websites aloud. Flash applications must be viewed in Internet Explorer on Windows, because Microsoft Active Accessibility (MSAA) support is limited to this browser. A screen reader is software that lets your visitors hear a description of the contents of web pages. Text is read aloud using specially designed software. Obviously, a screen reader can only interpret textual content. However, any descriptions that you provide for the overall SWF file, movie clips, images, or other graphical content are also read aloud. It is important that you write descriptions for the important images and animations so that the screen reader can also interpret these assets in your SWF file. This is the SWF file equivalent to alt text in an HTML web page.

Freedom Scientific JAWS for Windows is one of the most common screen readers available; version 4.5 and later is compatible with Flash Player 6 (6.0.21.0) and later. Window Eyes by GW Micro is another one of the most commonly used screen readers, and version 4.2 and later is supported by Flash Player 6 (6.0.21.0) and later. Accessible content is interpreted differently by each of these screen readers, and might also behave differently on different players. You can download free but time-limited demo software from the following websites:

• Window-Eyes from GW Micro
• JAWS for Windows from Freedom Scientific

Note: Flash Player 7 (and later) does not work with all screen reader technologies. It is up to the third-party software provider to handle the information provided by MSAA.

Creating Accessible Sites

Flash Player uses Microsoft Active Accessibility (MSAA) to expose Flash content to screen readers. MSAA is a Windows-based technology that provides a standardized platform for information exchange between assistive technologies, such as screen readers, and other applications. Events (such as a change in the application) and objects are visible to screen readers by using MSAA.

Making a website accessible involves several different criteria:

• Expose the information to screen readers. Use the techniques outlined in this section to expose parts of your SWF files to screen readers.
• Make text or images realizable. Some visitors might have difficulty reading small text or seeing small graphics. Allow users to zoom in on these elements, taking advantage of scalable vector graphics in SWF files.
• Provide audio narration. Consider providing an audio narration for visitors without a screen reader, or where screen readers might not work, such as with video content.
• Provide captions for audio narrations. Some visitors might not be able to hear an audio narration for your site or a video. Consider providing captions for these visitors.
• Do not rely on color to communicate information. Many visitors might be color blind. If you rely on color to communicate information (such as: Click the green button to go to page 1, click the red button to go to page 2), provide text or speech equivalents.

Historically, many online presentations (such as videos) provide alternate ways for visually impaired visitors to access the content. An example of this would be a textual description of a video. However, Flash provides textual information directly to the screen reader. Although this usually means you need to make additional settings or ActionScript adjustments in a FLA file, you do not have to create a completely separate version.

Parts of your SWF file can be exposed to screen readers. Text elements (such as text fields, static text, and dynamic text), buttons, movie clips, components, and the entire SWF file can be interpreted by MSAA-compliant screen readers. The following sections discuss how to work with Flash and screen readers.

Section 508 is legislation in the United States that provides guidelines for making information accessible to people with disabilities, such as vision impairments. Section 508 specifically addresses the need for websites to be accessible in several ways. Some websites, including all federal websites, must comply with these guidelines. If a SWF file does not communicate all of the information to the screen reader, the SWF file is no longer Section 508-compliant.

Many nations have specified standards and guidelines (such as the Web Accessibility Initiative) to follow to create accessible websites, or follow guidelines established by other organizations. These standards and guidelines do not offer much assistance when working with Flash content, but describe what factors you must address when you create accessible HTML websites, and some of this information applies to Flash.

Exposing SWF File Structure and Navigation

Because of the highly visual nature of some SWF files, the layout and navigation of the page can be complex and difficult for screen readers to translate. An overall description of the SWF file is important to communicate information about its structure and how to navigate through the site's structure. You can provide this description by clicking the Stage and entering a description into the Accessibility panel. You could also create a separate area of the site to provide this description or overview.

Note: If you enter a description for the main SWF file, this description is read each time the SWF file refreshes. You can avoid this redundancy by creating a separate informational page.

Inform the user about any navigational elements that change in the SWF file. Perhaps an extra button is added, or the text on the face of a button changes, and this change is read aloud by the screen reader. Flash Player 7 and later supports updating these properties using ActionScript. This means that you can update the accessibility information in your applications if the content changes at runtime. For more information on updating accessible properties at runtime, see Creating Accessibility with ActionScript in Flash Help or the Flash 8 LiveDocs (Using Flash > Creating Accessible Content > Creating Accessibility with ActionScript).

Controlling Descriptions and Repetition

Designers and developers can assign descriptions for the animations, images, and graphics in a SWF file. Provide names for graphics so the screen reader can interpret them. If a graphic or animation does not communicate vital information to the SWF file (perhaps it is decorative or repetitive), or you outlined the element in the overall SWF file description, do not provide a separate description for that element. Providing unnecessary descriptions can be confusing to users who use screen readers. For more information on assigning names and descriptions, see Using Flash to Enter Accessibility Information for Screen Readers in Flash Help or the Flash 8 LiveDocs (Using Flash > Creating Accessible Content > Using Flash to Enter Accessibility Information for Screen Readers).

Note: If you divide text or use images for text in your SWF files, provide either a name or description for these elements.

If you have several nested movie clips that serve a single purpose or convey one idea, ensure that you do the following:

• Group these elements in your SWF file.
• Provide a description for the parent movie clip.
• Make all the child movie clips inaccessible. This is extremely important, or the screen reader tries to describe all the irrelevant nested movie clips, which will confuse the user, and might cause the user to leave your website. Make this decision whenever you have more than one object, such as many movie clips, in a SWF file. If the overall message is best conveyed using a single description, provide a description on one of the objects, and make all the other objects inaccessible to the screen reader. Looping SWF files and applications cause screen readers to constantly refresh. This occurs because the screen reader is detecting that there is new content on the page, and because it thinks the content is updated, it returns to the top of the web page and starts rereading the content. You should make any looping or refreshing objects that do not have to be reread inaccessible to screen readers.

Note: Do not type a description in the Description field of the Accessibility panel for instances (such as text) that the screen reader reads aloud.

Using Color

It is tempting to use a wide array of colors in a Flash SWF file. It is possible to use all these colors in an accessible SWF file, but you must make some decisions about it. For example, you must not only rely on color to communicate particular information or directives to users. A color-blind user cannot operate a page if it asks to click the blue area to launch a new page or the red area to hear music. Offer text equivalents on the page or in an alternate version to make your site accessible. Also, check that there is significant contrast between foreground and background colors to assist users who have difficulty seeing particular colors, to enhance readability. If you place light gray text on a white background, users cannot easily read it. Similarly, small text, which is commonly found in many Flash websites, is difficult for many visitors to read. Using high-contrast and large or resizable text benefits most users, even those without impairments.

Ordering, Tabbing, and the Keyboard

The reading order and tabbing are possibly the two most important considerations for making accessible Flash websites. When you design an interface, the order that it appears on the page might not match the order in which the screen reader describes each instance. There are ways you can control and test reading order, as well as control tabbing in the SWF file.

Controlling Reading Order

Screen readers sometimes read assets in an unpredictable order. The default reading order does not always match the placement of your assets or the visual layout of the page. If you keep the layout simple, this can help create a logical reading order without the need for ActionScript. However, this isn't always possible and doesn't necessarily work as expected. You have more control over the order in which your content is read if you use ActionScript. For more information on controlling reading order using ActionScript, see Creating Accessibility with ActionScript in Flash Help or the Flash 8 LiveDocs (Using Flash > Creating Accessible Content > Creating Accessibility with ActionScript).

Because the default reading order is not predictable, use ActionScript and test the reading order in your SWF files.

Caution: Do not miss ordering a single instance in your SWF file, or the reading order reverts to the default (and unpredictable) reading order.

Controlling Tabbing and Content

Visitors who rely on screen readers to describe a site's content typically use tabbing and keyboard controls to navigate around the operating system and web pages, because using the mouse is not useful when the screen cannot be seen. You should offer intelligent tabbing control in accessible SWF files using the tabIndex and tabEnabled properties with the movie clip, button, text field, or component instances. In addition to tabbing, you can use any key press actions to navigate through the SWF file, but you must communicate that information using the Accessibility panel. Use the Key class in ActionScript to add keypress scripts to the SWF file. Select the object for which you want to use the keypress script, and add the shortcut key in the Shortcut field on the Accessibility panel. Add keyboard shortcuts to essential and frequently used buttons in your SWF file.

Note: Avoid invisible buttons in accessible SWF files, because screen readers do not recognize these buttons. (Invisible buttons are buttons for which you define only a hit area, the clickable region, for the button.)

Similarly, give your users control over the content of the SWF file. Many SWF files have a rapid succession of information, and screen readers frequently cannot keep up with this pace. It is simple to resolve this problem by handing control of the process to your user. Provide controls for the SWF file, letting the user step through the file at their own pace using buttons, and letting them pause the process if necessary. Users with screen readers might interpret the content at a slower pace than other users, so giving control to the user is important in these cases.

Handling Audio, Video, and Animation

Many SWF files contain audio, video, and narrations, because it is easy and robust to deliver this media using Flash. When you provide audio narrations or video that contains speech, it is important to provide captions for those users who cannot hear. You can use text fields in Flash, import video that contains captions, or even use an XML caption file. You can use video cue points to specify when a text field should update text information at runtime. For information on using captions in Flash, see Accessibility for Hearing-Impaired Users in Flash Help or the Flash 8 LiveDocs (Using Flash > Creating Accessible Content > Accessibility for Hearing-Impaired Users).

For information on using Hi-Caption SE and the Hi-Caption Viewer component, see the Flash Professional 8 Third-Party Extensions product page. This third-party extension lets you create captions that you save in an XML file and load into the SWF file at runtime, among other advanced controls. Alternatively, you can use cue points and a text field to display caption information.

Extending Flash and Accessibility

With the extensibility layer in Flash 8, developers can create extensions that enable advanced authoring with little effort. This enables third-party companies to develop extensions that involve accessibility. You have several options for validating your SWF files or adding captions.

For example, a validation tool can look through your SWF file for missing descriptions. It checks to see if a description is added for a group of instances, or if text has a label for the instance, and tells you about any problems. The tool also examines the reading order in your SWF file, and finds all instances that must be specified. Reading order can be specified after the SWF file is analyzed using a dialog box.

For information on the currently available third-party extensions, see the Flash Professional 8 Third-Party Extensions product page.

Testing Frequently and Making Changes

It is strongly advised that you test any SWF file that is intended for use with screen readers. Test your SWF files when each new version of Flash Player is released, including minor revisions, such as Flash Player 7 (7.0.19.0). In addition to testing the SWF file with different Flash Players, also test the SWF file with both Window Eyes and JAWS for Windows screen readers. These two screen readers handle SWF files differently, so you could get different results for the user experience.

Note: You do not have to test different browsers, because the technology used to expose SWF files to screen readers (MSAA) is supported only by Internet Explorer on Windows.

To test your sites with a screen reader:

1. Open your site in a browser without a screen reader, and navigate through your site without using the mouse.
2. Open your site in Window Eyes, and navigate through your site, listening to how content is read in the screen reader.
3. Try navigating your website after turning off your monitor and using only the screen reader.
4. Repeat Steps 2 and 3 using JAWS for Windows.
5. If you use audio narration, test your site without speakers.
6. Test your site with several target visitors.

When listening to your SWF file using a screen reader, Ask yourself the following questions:

• Is the reading order correct?
• Do you have descriptions for shortcuts in your SWF file?
• Do you have adequate and complete descriptions for the elements in the interface?
• Do you have adequate descriptions for navigating the site's structure?
• Is the SWF file content read when it is updated or refreshed?
• If you change the context of any elements on the Stage (such as a button that changes from Play to Pause), is that change announced by the screen reader? There is no official tool available for validating SWF files, unlike HTML validation. However, some third-party tools exist to help you validate the file. For more information on these extensions, see the Flash Professional 8 Third-Party Extensions product page.

Page 9 of 11

Previous Page

Next Page