Flash MX: Moving Toward Accessible Rich Media

Macromedia released Flash MX in mid-March of 2002, including enhancements to the player and the authoring tool to improve accessibility for people with disabilities.

Admittedly, some areas like screen reader access couldn’t possibly get any worse than they were in previous versions of the player: popular screen readers such as JAWS and Window-Eyes ignored Flash content completely. Other features, such as the ability to add captions (which has been available since Flash 5), benefit from improvements Macromedia made to the Flash architecture in this release.

The changes have also automatically improved access to existing Flash content when viewed in the Flash Player 6, but to maximize Flash accessibility for your users you’ll need to publish content from Flash MX.

A target for critics#section2

Flash is a frequent target of criticism for people concerned with access issues.  The W3C’s Web Accessibility Initiative’s Interest Group list archive is full of posts complaining, commenting, and seeking advice on how to best use Flash in an accessible site.

Several articles on the topic exist, including Jim Heid’s September 2000 “A Call to Action: Making Flash Accessible,” which provided constructive suggestions for improvement and helped raise awareness of access issues in Flash 5.

Although much of the criticism of previous versions of Flash is justifiable, it is worth mentioning that Flash 5, QuickTime, and RealPlayer all share similar issues accessing content.

All three are ignored by major screen readers; all have limited, if any, keyboard access; and all have some level of support for captions and audio descriptions. (QuickTime and Real have done more in this area, but neither has a perfect solution).  Enter Flash MX and Flash Player 6.

Section 508 and Flash#section3

The Section 508 amendments to the Rehabilitation Act of 1973 have separate regulations relating to the accessibility of software applications and web-based applications.  Macromedia needs to address issues in Flash with both the authoring tool and the player, but the bulk of Macromedia’s efforts with Flash deal with the player and changes within the authoring tool to allow authors to add additional information for assistive technology, as do my comments here.

The Flash MX authoring tool has a variety of issues for disabled Flash authors, particularly relating to screen reader support.  Many of these are problems that all tools with drawing and visual placement user tasks grapple with.  Given the widespread distribution of the Flash player (Macromedia claims that over 98% of web users have it), it is easy to see why the initial focus was weighted toward accessibility of Flash content rather than authoring.

Access via assistive technology#section4

The changes made to the Flash player are heavily focused on the ability of Flash to exchange information with assistive technology, particularly screen readers.  This area was the greatest weakness of Flash in previous versions.  In the past, users with screen readers encountering a page with Flash on it would be unable to access the information: screen readers didn’t understand Flash, so they were designed to ignore it.

When most modern screen readers interact with a web page, they create an off-screen model of the HTML, including all text and hyperlinks.  Flash content, referenced from an <object> or <embed> tag, is one layer too deep, and screen readers have no way to get important information.

Here’s the big change: Flash Player 6 now uses the Microsoft Active Accessibility (MSAA) API to exchange information with a web browser that supports MSAA, which channels information to and from assistive technologies that support MSAA.

Today, the only screen reader that allows users to interact with Flash content is Windows-Eyes from GW Micro.  (Freedom Scientific’s JAWS, the screen reader with the largest share of the market, is working to add support in upcoming months. )

Platform and browser limitations#section5

The only browser supporting MSAA at present is Internet Explorer on Windows, but Mozilla is implementing it as well , so look for a future version of Netscape using MSAA.  There is no support for this sort of accessibility for the Mac at this time—but to be fair to Macromedia, nothing similar to MSAA currently exists for the Macintosh operating system.

How it works#section6

A user with Window-Eyes 4.2 and Flash 6 Player can now navigate Flash content in a manner consistent with the way he or she navigates an all-HTML web page. The user will be able to read the Flash content line-by-line or use the tab key to skip from one actionable item to another.

In a straightforward Flash presentation, all text is read to the user, the text in all buttons is read, and basic form elements (input text, check boxes, radio buttons, and form buttons) are also read. So far the role of the author has not changed from the past—all of this information is accessible by default.

Changes in the authoring environment#section7

As the author adds to the Flash content, more work is needed.  Images, often added as “graphic symbols” must instead be added as a “movie symbol.”  The Flash author then must use the accessibility panel in Flash MX to ensure that the movie is accessible and that an appropriate text alternative (“name”) is designated.

If the image in the movie symbol doesn’t add to the content of the presentation, the author can choose to hide it from assistive technology by deselecting “Make Movie Accessible.” Similarly, if the author wants to use an image for a button symbol instead of text she must provide the text equivalent in the accessibility panel.

In Flash, movie symbols often act as containers for multiple symbols.  In many cases, the content within the top-level movie symbol is important, and the author can repeat the previous steps to make any “child” symbols accessible.

The author can add information to the “parent” movie that provides additional context to the user, or if the content is better described collectively, the author can add an overall description of the contents of the movie symbol and deselect the “Make Child Objects Accessible” option on the accessibility panel.  An entire Flash presentation is similar to movie symbols in this way, and can be summarized with this same technique.

Objects that can’t be currently made accessible include invisible buttons and some specific form components: combo boxes, list boxes, and scroll bars. These components serve useful purposes, and I am hopeful that Macromedia will develop accessible versions of these components.

Accessible Flash in Action#section8

Let’s look at a specific example where we can see the previous techniques in action and learn about two key limitations of current Flash content.  Zoot Suit Culture is a Flash presentation made by WGBH Interactive as part of the web complement to PBS’s American Experience program on the Zoot Suit Riots in the 1930’s.

The first Flash screen shows a list of interview topics that are in the category “Music & Dance.”  A screen reader user would hear:

“Loading page, load done.  Loading page, load done.  This feature contains interviews categorized into two areas, music and dance, and fashion.  Zoot Suit Culture. Music and Dance area. Button Fashion. Button The Big Band Scene. Button The Pachuco Hop. Button Downtown LA. Button Pachuco Attitude. Button Theaters. Button Dance Halls. Button Servicemen. Button Music off.  Bottom.”

If the user used the tab key to scan the page, he or she would only hear the buttons read.

Delivering the content#section9

Here’s what was done to make this content accessible:

1. A description was added to summarize the presentation and provide context for the user (the first sentence after “load done”).  A visually-impaired user entering the presentation would benefit from additional context that is only available visually, so explicitly communicating that there are two sections and their names is a good idea here.
2. Descriptions were added for each of the seven buttons that link to interviews.  If these buttons contained simple text, this step would be done automatically by Flash’s auto-labeling feature.  However, these buttons have two layers of text to create a shadow effect, and they are arched.  Arched text is broken up into lots of little text boxes in Flash and the information is passed to the screen reader based on which letters are on the same line.  The result is a jumble of letters, and the jumble is read twice because there are two versions when you include the shadow text.  For each button, a name (e.g. The Pachuco Hop) was explicitly designated in the accessibility panel and all child objects within the button were hidden by deselecting “Make Child Objects Accessible.”

Room for improvement#section10

Here’s what could be improved:

1. Tab order.  You may notice that the tab order is not what you might expect.  Flash 6 Player determines the tab order, sometimes with undesirable effects.  In this case, the order is acceptable if not straightforward.  It would only be a problem if the first and last buttons were mixed in with the buttons to the interviews, so the decision was made to leave the tab order unchanged.  Changing the tab order requires a simple ActionScript command, but is a process that requires meticulous care in naming objects.  Adding a tab order field to the properties panel would be a great improvement.
2. Document structure.  Unlike XHTML, Flash has no implied structure.  In this presentation, structure might help to identify the fashion section button as a different type of button than the buttons to the interviews.  In a presentation with more information, structure in Flash and an easy way to navigate by structural level would benefit users.
3. Voicing strategy.  Window-Eyes repeats “Loading page, load done” whenever there is a change in the MSAA representation of the Flash content, and the screen reader moves focus to the top of the Flash content.  As a result, when any button is followed this phrase is repeated, and in presentations where objects are animated or where text changes, the phrase is repeated for every change unless the change is hidden via the accessibility panel. Sites using lots of animation will, therefore, need to perform rigorous testing with assistive technology to be certain that the presentation functions correctly.
4. “Skip to content” links.  This example doesn’t require a skip link, but due to the way Window-Eyes supports Flash, this isn’t currently possible.  This creates a problem for authors interested in creating these links since a button leading to a location in the Flash content after a long list of navigation buttons will actually result in the screen reader restarting at the top of the content.

Challenges#section11

From the author’s perspective, development is challenging for a few reasons:

1. To test your work with a screen reader, you will need to be minimally familiar with Window-Eyes.  There is a free demo version of Window-Eyes that is available for download, but it has a steep learning curve. For thorough testing, consult with regular users of Window-Eyes.
2. When using Window-Eyes, the yellow focus ring that appears around buttons when tabbing is not shown.  This hinders the debugging of tab-order problems.
3. There is no way to browse accessibility settings without selecting each item.  It would be helpful if you could see all the settings in a list, like the one the movie explorer provides for text.
4. screen reader support is not at a point that eliminates the need for an HTML alternative.  Many users using older versions of assistive technology will not upgrade for some time, due to the expense of the software.  For larger projects, publishing SWF and HTML files from a database may alleviate the workload, but an HTML export option as was available for Flash 5 would be useful, and an HTML export option that used equivalents entered into the accessibility panel would be even better.
5. Accessibility is required for usability, but most developers don’t really understand usability as applied to assistive technology.  Flash authors will need to learn about accessing content through a single point of focus, and how that differs from the experience of taking in an entire page in one glance. A drag-and-drop game may be a great idea with vision and a mouse, and all of the information may be available to a screen reader, but can a screen reader user really use it?  More research is needed to understand and enhance the usability of rich-media for assistive technology.

Access via captions, audio description, subtitles, and dubbing#section12

Flash can be captioned and subtitled, and now that Flash authors can incorporate video into Flash, this is more important than ever.  Since caption and subtitle text will change often, it needs to be hidden from screen readers to avoid repetitive voicing of “Loading page, load done.”  Developers can include captions and subtitles in Flash content in four ways:

1. Type text directly onto the stage at different points in the timeline.
2. Use Flash’s XML parsing engine to display caption data contained in an XML file, such as that created by the Media Access Generator (MAGpie) 2.0, the new version of NCAM’s captioning and audio-description tool which will be in public beta release soon.  Macromedia plans to offer a downloadable extension that does the hard work of writing ActionScript for this task, and current plans include the ability to detect the user’s language preference and use that information to delivery subtitles in that language when available.  The interviews that are part of the Zoot Suit Culture site demonstrate captioning done using MAGpie 2.0 and a captioning extension created by Jason Smith at the American Association for the Advancement of Science.
3. Caption your video or Flash content manually or using MAGpie, creating a QTtext file. Convert the QTtext file to a movie and import it into the Flash presentation, making sure to synch the start of the video and the QTtext movie.
4. Use “burned-in” captions.  Burning captions into the video during the encoding process is an old-school technique that often produces lousy looking captions, but it does work.
5. Captions can be made to be “closed,” or user selectable, by including an interface item that can be used to show or hide captions.  There is no preference setting for the display of captions or subtitles, which is unfortunate but tolerable, and very similar to what is possible in QuickTime.

Synch, sound, and bandwidth#section13

A significant problem Flash will need to deal with is the loose synchronization of media elements.  Captions download and play more smoothly than video does, sometimes resulting in a loss of sync. Another issue is the way that XML parsing is done, if caption data is to be delivered this way. Once the caption data stream starts, it keeps going until finished. Try playing one of the Zoot Suit Culture videos and right click to pause the video a few seconds in. The captions should pause, but don’t. This is not desirable behavior.

Audio description can be included in Flash, but the author will need audio files that are made for the task, preferably by trained describers.  MAGpie 2.0 will help authors who are taking the task on themselves determine timing for audio description clips and can also be used to record the description. A dubbing soundtrack can be incorporated into Flash as well.

There are also no preference settings for audio description or dubbing as there are in Real’s RealOne Player. Authors may find that creating separate versions for described and non-described content saves bandwidth, rather than having all users download extra data for audio description that most of them don’t need. Similarly, a Flash presentation containing a three-minute video and four different language versions of the audio program will create a considerable increase in download size.

Is Accessible Flash Still a Dream?#section14

What really matters is whether access features actually help users. With changes released in Flash MX and Flash 6 Player, Macromedia has taken a big first step toward making Flash accessible to all users, but they will be the first to say that there is >more work ahead.

People concerned with accessibility issues will find shortcomings in Flash, as is also easy to do with HTML. Rather than deriding Macromedia, we need to work with them to progress toward better solutions.

Some Flash authors will refuse to add additional information until they are forced to, either by a government client working under Section 508, state-level, or university regulations, or by possible future legislative mandates that cover the private sector. If a client asks a design house that uses Flash to create a site and accessibility is part of the specification, hiding behind the inaccessibility of Flash is no longer an option. In lean times, authors-for-hire can only turn away so much work before hunger sets in.

Most authors will come willingly, eager to push the envelope of Flash development in a new direction, and these people will create models that others can learn from. As with HTML, mistakes will be made and listserv threads on the proper way to use “name” and “description” will abound, but on the whole, the community will move in the direction of progress and accessibility.

Much work remains: developers need education and training, additional assistive technologies need to meet Flash halfway via MSAA, and improvements to the player and authoring tool should be suggested. Macromedia’s Flash MX and Flash 6 Player should be used to make and deliver accessible Flash content, and interested people should discuss successes, limitations, and strategies. Macromedia should be applauded for their efforts, and encouraged to continue.