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.

Article Continues Below

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.

An accessibility panel in Flash MX.

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.


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.

18 Reader Comments

  1. Ok – we might be overreacting to FlaskMX, but there is no structure and it is not open. I think what alot of us would hope for is that Macromedia would embrace SVG a W3 recommended vortor redering technology which uses xml. SVG is up to par at this stage and provides great document structures which will help us grow beyond alot of these problems.

  2. OK, wonderfull aritcles. A good clarification about accessibility problem in Flash. But I’d like to read on these pages something about Flash MX and the future of web design. Macromedia think it’s Flash-based, and you?

  3. > But I’d like to read on these pages something about Flash MX and
    > the future of web design. Macromedia think it’s Flash-based, and
    > you?

    Gosh, the PRESENT of web design is Flash-based. It’s also HTML-based. And XHTML-based. And XML-based. And CSS-based. And DOM-based. And CMS-based. It’s a lot of things, and they all meet different needs.

    It’s understandable that Macromedia would take a “Flash everywhere” position. If your company made Flash, you might make similar statements. If XML was a corporate product instead of an open and emerging standard, the corporate owners of XML™ might issue equally broad proclamations.

    Flash is an amazing tool, Flash MX is better than its predecessors, and the badly needed accessibility enhancements discussed in this week’s articles make it better still. But powerful as it is, and integrated as it is with Cold Fusion, XML, and so on, it’s still just one tool among many.

    The future, I expect, will offer designers and developers even more technologies to choose from, and they’ll pick the ones that best serve their project and audience.

  4. Flash content having little or no structure not only poses accessibility problems for users. Any search engine that chooses to index SWFs will basically get a load of unstructured, possibly jumbled text. Links will only be found by looking for obvious URL strings in things like getURL.

    Of course, part of Flash’s appeal to designers is that it doesn’t force them to think logically about structure, but that’s also its weakness and makes true accessibility difficult. It’s the best animation format we have, ideal for many interactive features, and I’m guessing it’ll be one of the top video formats in a year’s time, but for the foreseeable future I’ll be sticking with XHTML for structure, text content and navigation.

  5. I think I mostly agree with Mr. Zeldman on this one, Flash has it’s place in the Web. Obviously you don’t want to use Flash, even now that it supports MSAA, for handing out technical documentation but, it might be great for generating interactive graphs for physics lectures. Just so long as those interactive graphs are as fully accessible as we can make them, Flash should be fine.

    However I think that point should be that some things are easier to make accessible than others for some applications. If you have a lot of text, HTML will always be the easiest choice to implement accessibly.

    And one unrelated comment, is Apple doing anything to implement something like MSAA in OS ten plus? They’d better get on this.

  6. IMHO, Macromedia’s not really pushing a ‘Flash everywhere’ philosophy, it just seems that way because Flash is so damn popular. MM’s attitude is more in line with Zeldman’s “just one tool among many” view and John Dowdell has an excellent article at the MM developer center on this:

    “Where’s HTML in MX?”

    To be fair to the conspiracy theorists, however, I can see how Macromedia is trying to have Flash be one tool among many that THEY create. It’s hard not to think so, when you look at the broad and ever-increasing scope of their authoring tools, which currently generate html, xhtml, xml, css, flash, asp, jsp, coldfusion, jpgs, gifs, pngs… the list just keeps going. And that’s just the front-end stuff!

    Anyone else uneasy with this all-solutions-to-all-people strategy?

  7. Quato from: http://www.macromedia.com/desdev/jd_forum/jd005.html
    Sometimes people in those threads got on an SVG rant, but that has very little relevance to this discussion. SVG is just a file format for vector graphics, and never solved the practical problem of widespread computer viewability. Flash solved both those problems years ago, and then solved reliable animation and interactivity, and is now moving towards video integration, efficient application development, connectivity and communications, and viewability on portable and embedded devices too.

    SVG is a W3 recomendation with many advantages for search engines, metadata and 508 accessability issues. Flash solved “viewability” years ago! SVG is only getting going now and it offers much more functionality that an swf can. All we ask is ‘please include” svg functionallity. Adobes LiveMotion does. Remember Adobe missed the internet boat at the beginning. Macromedia had killer apps incl. flash out befor Adobe were on the drawing board. That was years ago. Macromedia, dont sit on the fence. It’s time to move on. Implement SVG in flash. In combination with actionscript … should be awesome.

    In the meantime if Flashplayer 7 would support SVG It could save us an extra plugin

  8. According to Adobe, LiveMotion does not support SVG. In the LiveMotion FAQ, Adobe explains why SVG is not supported (http://www.adobe.com/products/livemotion/pdfs/lm2_faq.pdf).

    Considering how much Adobe has put into advancing SVG as a standard, it’s suprising that the one tool that is ideal for demonstrating how much better SVG is compared to SWF, is instead pushed as an alternative for generating SWF content.

    As for accessibility, Flash MX has a major headstart over LiveMotion. LiveMotion may have a better UI than Flash, but it still falls short when is comes to creating accessible content.

  9. While I appluas Macromedia for the effort they are putting into making flash accessable, I am not sure that it is really possible. Flash is, after all, an interactive and highly audiovisual medium. I have not seen flash used to merely convey information that would be easily accessible to an impaired user. More often, it is used to add audiovisual flair to a page or in more avant-garde sites used to create an entirely new medium that isn’t translatable into text any more than a painting is. The point of flash is to make pages cooler, and that coolness will be totally lost on users who can’t experience flash in all its glory. My recommendation? If you have important information, make it available in a non-flash format, like XML. This is better not just for accessability but also for versatility, searchability, and is generally more appropriate.

    Also, do you seriously expect Macromedia to use an open format for Flash? They have a natural monopoly right now, and if they opened their format they would lose that. Flash is the best application for creating Flash content, because it defines flash content. I don’t see what advantage an open standard would offer macromedia.

  10. SWF for a big chunk has been figured out, or at least been optimizable via FLASM for awhile now (check sourceforge).

    I believe this debate is close to the whole 508 deal. If it goes through the farce of 508, then opening up to a publically open swf format is important in making those changes viable.

    The biggest telltale for svg will be from the community. It is possible to create an svg interpreter for flash (new draw commands) for many basic vectors. Check out were-here or any other flash site – there are talks about flash 3d (x, y, z) engines, and many agree on some type of xml/standards input.

    However, where do we draw the line between shockwave and flash? Where will Macromedia?

  11. It’s all information that is being conveyed, one way or another, right?
    You indicated that “[you] have not seen flash used to merely convey
    information that would be easily accessible to an impaired user” and
    that “The point of flash is to make pages cooler”. I think that what
    makes well-designed Flash pages cooler is when the user-interface to the
    information is improved and makes accessing the information easier.

    A great example of using Flash to improve visual access to a large
    volume of information is the “Deep Time” feature at PBS’s Evolution site
    (http://www.pbs.org/wgbh/evolution/change/deeptime/index . html). This
    example doesn’t work with a screen reader, but the information within
    the presentation is valuable. If it is possible to make the content
    accessible within Flash, shouldn’t we? Some aspects of the visual
    interface are difficult to imagine translating well to an audio-only
    rendering, but I believe that more research is needed on what the best
    ways to offer information for people using assistive technologies before
    dismissing Flash as a medium not to be used to deliver real information.

    It is a real challenge to figure out ways to present visual content in text and audio, but it can be done. A person who is blind may nt be able to observe a painting through their own senses, but certainly can participate in a discussion of how a particular work fits into some historical context if information about the painting is provided in text.

    If assistive technology can be used to strip out the same information
    that a developer might include in an XML format, what’s the difference
    for the user?

  12. How can I access .swf files from my visual basic code? How can I render .swf files on my vb form?

  13. Over the last few years we’ve been attempting to address accessibility alongside the delivery of rich media for eLearning. Our own implementation, though based upon a Macromedia solution (Shockwave) would not have been achievable using Flash.

    As well as providing full keyboard access for navigation and interactions (basic multiple choice through to drag and drop). We have rather than relying on third party screen readers incorporated full and configurable TTS as part of the solution.

    Throughout all of this we have attempted to adhere closely to recommendations described by the IMS Accessibility Working Group (http://www.imsproject.org/accessibility/index.cfm). In particular we have tried to develop a solution based around Direct Access rather than Compatible Access (imsacc_wpv0p6.pdf #2.4). Whilst Flash MX from what I have understood so far has attempted to address what is described as Compatible Access. To my mind means unpredictable results and expensive TTS solutions.

    Our ongoing efforts are available to demo at the following address http://www.canvaslearning.com. Click on ‘DEMO’ and then select CANVAS LEARNING PLAYER DEMO (note: The Author Demo though related, is something altogether different)

    You will require Shockwave, and (on win32) will need a SAPI conformant voice engine (http://activex.microsoft.com/activex/controls/sapi/spchapi.exe). The player will also install a couple of Shockwave Xtras. On the other hand all of this is free and you won’t need Window-Eyes or Jaws.

    To make keyboard access more usable, we’ve grouped navigation and materials separately. This in fact works to such an extent that many able users actually prefer to use the keyboard as opposed to the mouse. The keyboard controls are as follows;

    Control & Right arrow: Next group item
    Control & Left arrow: Previous group item
    Control & Up arrow: Switch group
    Control & Down arrow: Select deselect item

    Happy to field any questions or comments.

  14. Flash ignores fundamental web user interface principles, it’s proprietary, it’s slow, it’s destroying the web one web page at a time, and it gets worse every day. Every day another vile Flash-only web site infects the web. Every day another pernicious Flash advertisement hijacks your web browser. Flash has its uses, but as long as it continues to be so grossly misused that it endangers the web as a whole (and it does, mark my words), there is no alternative but to boycott it (and the people who use it) entirely. Just say “no” to Flash — and not just “no”, but “Hell no!”.

  15. Does anyone have any information on how widespread the use of Flash is among those with accessability issues? I wouldn’t think that those with visual imparements would have embraced Flash already. Even though FlashMX now has some 508 compatability, if users don’t have the plug-in, does it matter?

  16. Marc,

    A simple but no brainer solution for purveying content to handicapped users:
    put the info in

    Position the


  17. I forgot to clarify:

    >so it doesn’t annoy those who have JS deactivated…
    The non handicapped users able to enyoy/read Flash content
    who have JS deactivated for security reasons are ment.


  18. Marek,
    You state:
    “handicapped users mostly have scripting disabled anyway”.

    This is totally unsupportable. You can not find data on this topic. Furthermore, anecdotal evidence suggests that disabled users are very much like non-disabled users. Some turn js off, most leave it on.


Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA