I’ve worked with Adobe Flash for years and never had to develop with screen readers in mind until recently.  Making a swf that would play nice with screen readers was more involved than I’d have imagined.  The challenges included operating systems that disregarded de facto standards, browsers fussy about the embed code used, and what seemed like glaring oversights in Adobe’s own product.  Let me share with you some of my experience in the hope it will make it a little easier for the next guy.

I also want to thank aut0poietic for his help in this little effort. He blazed the trail before me and was kind enough to loan his map.

Inherent Obstacles

Exposing Flash content to screen readers is fraught with obstacles.  Its sort of like playing a game where the ref randomly says “you’re not allowed to do that,” then sends you back to the start.  Frustrating.

Screen readers themselves are problematic, and many do not support Flash at all.  JAWS by Freedom Scientific does support Flash and works better than many.  It is the screen reader I used for testing, but don’t count on the success you have with JAWS translating to other readers.

Operating Systems present another obstacle.  I had zero success trying to test screen readers in OS X.  As I understand it, Adobe Flash relies on the widely used Microsoft Active Accessibility libraries for its screen reader support.  Apple eschewed this approach and developed their own incompatible approach to accessibility.  The result?  No matter what you try, a Flash movie played on a Mac will not be visible to screen readers.  Just try checking the value of flash.system.Capabilities.hasAccessibility if you don’t believe me.  You can read more about this in the Adobe help docs.

Yet another challenge stems from the idiosyncrasies of individual browsers in how your embed code must be formulated before it can be exposed to screen readers.  More on this a little later.

The Basics

The basic steps to making Flash content accessible and available to screen readers is well documented elsewhere.  But there are some differences between Flash and Flex.

In Adobe Flash, click on the stage, open the Accessibility Panel and check Make Movie Accessible, Make Child Objects Accessible and (optionally) Auto Label.   Open the Accessibility Panel for individual MovieClip and SimpleButton instances and specify a name and/or description.  Do this if you did not check Auto Label, and for instances that need names but are not associated with a TextField.  By setting the name and description fields you are setting the alternative names screen readers will use when reading your swf.

In Adobe Flex, open the project Properties dialog, select the ActionScript Compiler tab and check Generate accessible SWF file.  For the Flex SDK add the -accessible flag to your compile command.  Alternatively, you can edit the flex-config.xml file and set the compiler -> accessible node to true.  For ActionScript projects you will need set the name and description for screen readers by assigning a values to the name and description properties of your DisplayObject’s accessibilityProperties property, then calling flash.accessibility.Accessibility.updateProperties().  Flex projects can set these values in the mxml or via ActionScript blocks.

One note about alternative names: JAWS and other screen readers will announce the name you specified, followed by “button” if the stage asset is clickable.  Just something to keep in mind when you’re assigning names.

Issues with Externally Loaded Content

Marking the movie as accessible and setting the accessibility panel’s name and description fields is sufficient for a single swf, but i was using a Loader instance to load external swfs.  Making loaded a loaded swf visible to screen readers is not straightforward because the Loader class, even though it is extends DisplayObject, does not have its own instance of accessibilityImplementation or accessibilityProperties.  These properties return null.  The content it loads is also missing these properties.  A work-around is to move the loaded swf from the Loader’s contentLoaded proprerty and make it the child of some other DisplayObject.  Finally, either set the loaded swf’s accessibilityProproperties manually or assign it a copy of another DisplayObject’s accessibilityProperties.  Using the stage’s accessibilityProperties worked for me.

Browser Quirks

Once I’d worked out the issues above I found my efforts stymied when I tried to use a screen reader on the swf when it was displayed in a webpage.  It seemed JAWS could read the contents of the swf just fine in either Flash (where the child swf was created) or in Flex (where the swf was loaded by its parent swf) but when it came to the web page, JAWS failed.  I eventually found that the problem stemmed from the embed code I was using.  You see, the live site was using the standards friendly Flash Satay formulation for the embed code, the Flex debugger was not, and of course the Flash standalone player does not use html.  To help troubleshoot this issue I took advantage of the Microsoft’s Active Accessibility 2.0 SDK tools:  specifically AccExplorer32.exe.  This utility let’s you focus on a swf embedded on a web page and inspect it the way a screen reader will see it.  Further testing revealed that IE required the classid attribute before the swf could be read by screen readers, and Firefox required the embed tag, not an object tag.

This pretty much rules out using the satay formulation so it was back to the Twice-Cooked formulation of the embed code.  Grr.  Oh, and before you ask, using SWFObject to load the swf file was not going to be an option  for me so I didn’t bother testing it, but it seems unlikely to work.

In Closing

Flash content and screen readers just don’t play well together, but you can certainly achieve limited success.  Windows users will be able to use screen readers with your swfs but the Mac and Linux crowd will be left out.  IE and Firefox will perform well with screen readers like JAWS but other browsers and other screen readers (most likely) will have a degraded experience.  Still, if you’re aim is to make your swf files as accessible as possible, and if you are required to adhere to Sec 508 standards it should be, limited screen reader support is better than none.