Making Flash Accessible – A pragmatic approach

My first serious exposure to Flash and accessibility was in 2004. One of my problems then was my understanding of accessibility. That’s improved a little, but the landscape changes (along with Flash and Actionscript) and since then I still haven’t found a solution that lets me produce ‘accessible’ content with the same effort as my usually inaccessible work.

While I don’t have anything I’d call a ‘complete solution’ I’ve used a number of partial solutions along the way:

• providing an onscreen link to an HTML-only version of the interactive content. This is never a straight copy of the text content. It’s a re-write of the interactive content as though it were an article, delivering the intended message without any audio, video, animation, images or colour. It’s the quickest way I’ve found to give a version of the content that’s accessible to the maximum number of assistive technologies with the minimum of production effort (and cost to the client);
• providing Flash content that is visible to MSAA enabled assistive technologies (like the JAWS screen reader) and also ‘wired up’ for keyboard navigation; and
• customised captioning combined with keyboard navigation, like this example (from 2004) to provide content accessible to hearing-impaired users and keyboard-only users.

AFAIK, obstacles that still stand in the way of convenient production of accessible content in Flash include:

• Flash still isn’t happy talking to Apple’s assistive technology. We can still only rely on MSAA as a technology bridge between the Flash Player and the real world (in this case, Microsoft’s real world);
• The vast number of impairments and their relevant assistive technologies. As well as additional development time it presents a massive overhead in testing. I’ve never yet been able to successfully justify the additional cost of purchasing the most basic assistive technologies (JAWS, a workstation to test on) to any employer.

So where to from here? I need to assume that there won’t usually be the budget or resources for producing multiple versions of the content, so I think the majority of my clients (Australian, so our legislative requirements aren’t yet as stringent as the US) would be happy with keyboard and screenreader accessibility.

For static content that’s fine, but interactions (beyond standard component-based radio-button and checkbox interactions) will need to be designed and coded quite differently, or ignored altogether.

If you’ve read this far you might already have pragmatic solutions to these problems – what are you doing about them?

Bookmark It

Hide Sites