A New Approach for Flash Accessibility

My colleague (aka running buddy, aka friend, aka fashionista) Andrea Hill and I had a pow-wow a few months back in anticipation of her Accessibility presentation at Spring </br> . Personally, I thought the conversation was a perfect example of how genius occurs at the intersections of knowledge domains, as we were able to take her expertise on Accessibility standards and my expertise in Flash and Actionscript and come up a back-of-the-napkin approach to Flash Accessibility that might just fix all the headaches caused by interfacing with Assistive Technology. Note that this solution does NOT absolve you from designing for visual impairments, hearing deficiencies and so forth- this is a way of interfacing with screen readers.

State of the Union

Flash content at this point can only interface with several select screen readers, and only on Windows (EDITED: see comments). This is because the Flash player uses Microsoft Active Accessibility, which is, of course, only supported in and via Microsoft technologies. As a result, Accessibility is one of those “Holy Grail” problems you run into over and over again, and everyone slaps a big price on because nobody really knows anything about it.

Solution Overview

Now for the solution. If you really think about the problem, making the flash player accessible is completely redundant. Compiled .swf’s are embedded into the DOM of a web page which, assuming the browser is reasonably up-to-date, already accommodates a broad selection of screen readers. What is really missing is a way for the Flash piece to use the browser as a bridge communicate with them.

Some interesting developments have actually occurred in this arena recently. The first is the release of a “headless” flash player by Adobe which Google and Yahoo now use for SEO purposes, yet could very easily be licensed for other purposes. The second is open-sourcing the .swf file format spec, which could allows someone to write their own ‘accessible’ flash player. Yet both of these solutions are very resource intensive, and take control away from the developer of the application in question.

Enter WAI-ARIA: This is a W3C standard for Accessible Rich Internet Applications (ARIA) that was designed specifically with Ajax-based RIA’s in mind. To give you a quick overview, ARIA outlines a series of attributes by which an XHTML tag (such as div, body, or table) can notify a screen reader of its semantic role, as well as any changes that may occur to/within it. Thus a div tag or unordered list can be given the role of ‘menu’ and an aggressive ‘politeness’ level so that any time the menu changes, the screen reader is notified.

At this point our proposed solution should be pretty clear: Rather than relying on the flash player to connect and manage the relationship with a screen reader, we instead piggyback on the browser’s capability and let it handle our communication for us. This can be easily accomplished via the ExternalInterface class, which not only allows us to interface with the javascript engine, but also allows us to write that same javascript to the DOM from flash so our Accessibility solution becomes completely internalized.


Fig 1: A flash RIA overlaying a DOM abstraction.


To fully understand the implementation of this concept, it’s important to realize that the flash portion of our application completely loses its purpose as a visual display platform, and is relegated to the role of Model and Controller, with the HTML DOM acting as the View. In essence the .swf becomes a Meta application whose job it is to accurately project its current DisplayList hierarchy into the HTML, while accepting commands from that same environment.

This requires a one-to-one mapping between DisplayObjects and HTML elements, which thankfully is fairly easy. To illustrate, take a look at the following two simple code examples. The first is an HTML representation of the DOM rendered by a browser, while the second is an MXML representation of DisplayObjects rendered by the Flash AVM.


Fig 2: XHTML and MXML representations of a similar page interface.

Look similar, right? Even though they’re both abstractions, you can get a good sense of similar object hierarchy and inheritance, and building an bridging framework becomes a question of determination rather than digging into the depths of the Flash Player. The tools are there, the solution is there, all we need to do is build it.


Fig 3: User Interaction flow for different use cases.


  • > Flash content at this point can only interface with several select screen readers, > only on IE running on Windows. This is because the Flash player uses Microsoft’s > Accessibility Interface (whose official name I don’t know), which is, of course, only > supported in and via Microsoft technologies. Correction. Flash is accessible in Firefox, via Microsoft Active Accessibility, which Firefox supports, as do numerous non-Microsoft technologies.

  • I stand corrected, Thanks! Though a bit of research shows that this is a relatively recent improvement via the IAccessible2 inclusion in FF3. Still, a great development overall.... though it's still not cross platform.

  • you still can't tab in and out of a flash movie in FF :( So in practice, nope, still no go. But this is great. Would love to talk some about this...

  • Actually, in this case that'd be an advantage. Remember, you don't want the user to interact with the flash movie itself, simply with the abstracted DOM hierarchy it's sitting on.

  • exactly. Its a great idea, and similar to something I've been toying with in idle moments. Have you or has anyone started anything on this?

  • and what about sighted keyboard users? they DO need/want to tab in and out of flash movies themselves, no?

  • Hi again, Are you laying claim to any IP on this, or can I start a BSD license project without worrying in that regard?

  • By all means, go get started. I haven't gotten into it on anything other than an architectural level, and far be it from me to proscribe an approach. Keep me posted, if you don't mind me getting involved when my schedule clears up again.

  • Susan Chaisson

    I've been trying to use the accessibility panel in flash to create an accessible course built in Lectora (which is accessible). The tutorial I completed using macromedia's OWN files doesn't even work with my screen reader. Has anyone had any experience with this? It reads the buttons but skips over the text boxes, even though they are labelled, and tab #'d in the swf. On another note, why would a sighted user want to tab in/out of a flash movie?

  • Hey Patrick. Yep - good point. But wouldn't this be neater for VI users? So both solutions would be good. To my mind it would be neater for VI users because ARIA would solve the dynamic nature of Flash for blind users. I.e. what happens when content updates (how and when to notify or read out new content...). Rather than building another framework for flash.

  • Because they don't or can't use a traditional pointing device (mouse).

  • susan chaisson

    oops - never thought of that. I guess there hasn't been much more talk on this site since this discussion took place. I'm wondering why accessibility is still not being discussed much on the internet. People trying to find more information so they can design for it (like myself) aren't getting much on the web!

  • Ian

    horrendously out of date reply, but just in case you're got notifications for this Susan - tabbing is also useful for other groups, for example if you aren't able to use a mouse and need to use a keyboard to operate your browser.

Leave a Reply