If you’re a Flash developer, and are using the accessibility features of the authoring tool to make your Flash objects directly accessible, you’d probably like to be sure that users of the supported browsers and screen readers can use those features. But common techniques for embedding Flash while still using valid HTML, which is not as easy as it seems, appear to cause trouble when it comes to reaching those users. This all stems from the use of the
embed element in the default Flash output HTML, and various tricks exist to quash that renegade element. Andrew Kirkpatrick of Macromedia has put out an evaluation of Flash embedding tricks, testing them for direct accessibility to the Flash object.
A popular method for presenting Flash objects in a valid form is Drew McLellan’s Flash Satay, which strips the
object code down to its bare minimum, and removes the
embed. This is functional in most cases, and having been demonstrated on A List Apart, has quite a following. But it has some side effects, the worst of which is incompatibility with the screen reader Jaws. Andrew discovered that Satay prevents Jaws from accessing Flash’s accessibility-related internals.
This information leaves designers with some unattractive choices to make:
- Default Macromedia code
- This uses the invalid
embedelement, but otherwise works for all browsers and assistive technologies. It’s accessible, and it’s Flash, but it’s not valid.
- Flash Satay
- With the leading screen reader unable to access it, this is valid, and it’s Flash, but it’s hard to call it accessible.
- UFO and FlashObject
- Since it falls back to
embedin all browsers other than Internet Explorer on Windows, this approach also fails the validity sniff test, though it does still allow accessible Flash in the tools Andrew tested.
- Nested Objects
- Ian Hickson offered an approach based on nested objects, but the test shows that Flash objects mis-render or fail in IE 6 for Windows, the Window-Eyes screen reader, and the Home Page Reader talking browser. It’s the worst possible outcome: validity, but neither accessibility nor reliable Flash rendering.
So, who’s to blame? It’s our good friends, legacy and interoperability. Support for
object is still lacking in nearly every browser, surprisingly enough, and this has caused the situation to snowball over a number of years. It’s not fun to talk about, or even to remember, but it’s a problem we’ve been facing for years, and will have to face for a few more. There is no quick fix. In fact, there’s nothing to do in this situation but to make sure that each authoring tool, browser and assistive technology has standardized support for
object in the near future. Until then, authors using the accessibility features of Flash will have a Hobson’s choice: cheat on validity, or fail to reach the audience they had designed for.
Is there a middle ground? Could there be a technique that is functional across browsers and platforms, doesn’t impede the Flash loading, preserves access to its internal accessibility features, and remains valid? Code jockeys, prick up your ears: this is your next technical challenge.