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.
Implementation
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.