News


A Flash in the pan or all things to all people?

Adobe is keen to trumpet the accessibility features of Flash CS3, but there are drawbacks as well as advantages which users need to be aware of.

Since version 6, accessibility features have been built in to Flash, so developers can label elements of the Flash movie, such as buttons or graphics, to expose them to screen readers, along with the contents of text fields.

This also allows a name and description to be attached to movie elements.

With the Flash 8 plug-in, the developer can update this information with ActionScript, so, if a dynamic screen is being used to show content which might come from a database or XML, the labelling information can be obtained from the same source.

That’s as far as the built-in accessibility features go, but the power of Flash allows the developer to go much further.

Flash is a rich multi-media environment, able to provide superior recorded commentary where budget allows. This is better than a computer generated voice, because it can be programmed to keep up with changing content, and allow highly interactive features to be accessible to the blind or partially sighted by using audio prompts and keyboard shortcuts.

For partially sighted users, the scalability is a boon. Flash based programs can be maximised on a big screen and content will scale up without loss of quality.

For people with hearing disabilities, subtitles can be provided for video content, or a transcript can be supplied as an alternative to audio content.

Those with limited motor skills are able to access highly interactive content via the keyboard rather than the mouse.

So Flash can be made more accessible than any other web or CD-ROM based content, but it needs a sizeable budget.

There are serious downsides to the built-in accessibility features of Flash.

The audience can be limited by the software it uses. This is because Flash uses Microsoft Active Accessibility (MSAA), which is only available in Internet Explorer on Windows, and it seems only works with three screen readers, JAWS, Window-Eyes and IBM Home Page Reader. Only users with those programmes can receive it.

The built-in accessibility features only work with relatively static and linear content. If the content is animated, constantly changing or highly interactive, it is possible to change labelling information on the fly, but this forces the screen reader to start reading the Flash movie again, preceded with a “Loading… load done” message.

For static and linear content, HTML would be as good as Flash, and it is inherently accessible. One approach could be to provide an HTML alternative to a Flash based site.

Flash is often used to develop programs on CD-ROM. When Flash content is packaged as a projector, an executable file that doesn’t need a browser to open it, these accessibility features are not available.

One solution to this is to provide an HTML page as an alternative way of launching the program, but this may disable key features.

Where content is relatively static and linear, consider providing an HTML alternative or ditching Flash altogether.

Only rely on the built-in accessibility features of Flash if you can be sure that the audience is using compatible screen readers such as JAWS, Window-Eyes or IBM Home Page Reader screen readers on Windows.

Spread the news:
  • Twitter
  • del.icio.us
  • LinkedIn
  • Digg
  • Reddit
  • StumbleUpon
  • email
  • RSS
  • Add to favorites

Tags: , ,

Leave a comment