Validity, Accessibility, Flash: Choose Two

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.

More recently, Bobby Vandersluis presented Unobtrusive Flash Objects (UFO), which alleviates many of Satay’s side effects, as well as passing Andrew’s assistive technology test suite. The HTML page will even validate. Great news, right? Sadly, there are a couple of gotchas that will trouble the hardcore standardistas: first, UFO works by affixing invalid code to a placeholder block via JavaScript. So you haven’t polluted your source, per se, but you’re still inserting invalid code into the document’s DOM tree. That placeholder block is also a little problematic in that it has no semantic value in the context of the document, and in the absence of JavaScript, you’ll only get blank space. (Another script, Geoff Stearns’ FlashObject, exhibits all the same behaviors as UFO.)

This information leaves designers with some unattractive choices to make:

Default Macromedia code

This uses the invalid embed element, 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 embed in 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.