A List Apart


Flash MX: Clarifying the Concept

In “Flash Access: Unclear on the Concept,” I dissected Macromedia’s plans for making Flash accessible to people with disabilities. At the time, Macromedia had ignored accessibility completely. Once it had belatedly committed to solving the problem, the company did not know just what it was getting into.

Article Continues Below

People keep telling me to stop being such a bitch, so here is a much cheerier and less disempowering update. Macromedia no longer ignores accessibility and does know what it’s getting into, but only the very earliest steps have been taken.

The screen reader problem

The new Flash MX authoring environment and the equally new Flash Player 6 solve a few accessibility problems.

Screen reader compatibility is the first Macromedia access milestone. Screen readers—which, by the way, are not called “voice browsers” or “text readers”—are software that reads web pages, and anything else on your computer, out loud. (I’d show you a picture, but apart from a few uninteresting configuration screens, these programs have no overt visible form.) The leading screen readers are:

  1. IBM Home Page Reader
  2. JAWS (by Freedom Scientific)
  3. Window-Eyes (by GW Micro)
  4. Outspoken (by ALVA Access Group)
  5. Emacspeak (freeware for Linux)

Typically, screen readers can also output text to Braille displays instead of or even in addition to voice output. Braille displays are fascinating, rarefied, and costly devices. Tieman, Freedom Scientific, and ALVA are notable manufacturers. Not all that many people use them, in part because not all that many people read Braille (maybe 10% of blind people).

In ordinary HTML websites, screen readers can read text on the page, plus text equivalents like alt, title, and longdesc. They can also:

  • tell you the number of images, frames, and tables on the page (yes, friends, the truth can be revealed—every screen reader except OutSpoken for Macintosh can handle tables quite adequately, so go ahead and use them)
  • list every link on the page
  • announce or ignore punctuation
  • enunciate words letter-by-letter and numbers digit-by-digit
  • speak at superhuman speeds (is 300 words per minute fast enough for you?), which experienced screen reader users can comprehend

Have a look at a useful little QuickTime video called “Introduction to the Screen Reader.”

Nearly every blind or visually-impaired person online who uses a screen reader does so on the Windows platform. Apart from the large general installed base of Windows machines, the reason for Windows dominance traces back to a Microsoft software infrastructure known as Active Accessibility. MSAA acts as an intermediary between the structure and appearance of Windows software programs (including Windows itself and various browsers) and “adaptive technology” like screen readers.

Adaptive technology can poll MSAA to find out where the cursor is located, where text, toolbars, and icons are located and what they say and mean, and more.

In order to make a computer accessible, a screen reader manufacturer merely has to write software compatible with MSAA calls, plus the usual caveats about compensating for individual programs’ incompatibilities (including Microsoft’s own software). This is not a small task, but it is a much easier task with MSAA than it would be if adaptive-technology makers were forced to reinvent the wheel, which is actually the case on, say, Mac OS, which offers nothing in the way of an accessibility infrastructure. The Gnome Accessibility Project is an ongoing but incomplete effort to write an access infrastructure for Linux.

At the moment, the only screen reader that works with Flash Player 6 is Window-Eyes by GW Micro. The big name in that field, JAWS, will apparently be made compatible in the next dot-level upgrade.

Why should Flash be accessible?

Because of the U.S. government’s Section 508 requirements. Though sprawling and hard to understand, 508 requires that technology sold to or used within the U.S. federal government and a limited number of outside entities be accessible to people with various disabilities. That includes web technologies of all kinds.

It is not widely understood that 508 regulations have been in effect and enforceable since June 21, 2001. They’re not coming down the pike; they’re here already. In practice, there is no actual enforcement; we are living in a kind of grace period. But the requirements eventually will be enforced, and noncompliant products could not be bought by the U.S. government thereafter.

In simple and quite unexaggerated terms, if Macromedia didn’t make Flash accessible, after a certain point it could never install another copy of Flash on the computers of the largest single buyer of information technology in the United States.

How’s that for “letting the market decide”? If you want to keep your biggest client, you comply with its demands. And in practice, IT vendors everywhere are frantically modifying their software and hardware for 508 compliance, which will benefit every disabled user of that hardware or software whether inside or outside the American government. 508 has the effect of requiring accessibility for the entire English-language computer industry worldwide.

(A legalistic detail: Technically, government agencies are responsible for compliance, not outside vendors, and we already have seen complaints about offloading 508 compliance to software and hardware makers. The effect is the same: Flash has to be accessible when used by entities covered by 508.)

That’s the real reason Macromedia is going to all this trouble. It is also true that the company now believes accessibility is the right thing to do for all the usual ethical and business reasons, but the inciting incident was the prospect of permanently losing U.S. government sales.

And as for the question “If Flash is all about visual presentation, why should we bother making things work for the blind?”: Blind and visually-impaired people aren’t the only ones with relevant access needs—deaf/hard-of-hearing and learning-disabled people are two other groups, not to mention those with mobility impairments that make navigating the web difficult. In any event, audiovisual media have been made accessible to people with disabilities for decades. I personally have been watching captioned TV for nearly 25 years. Audio description for the blind has been aired on TV in the U.S. since 1988. First-run movies are captioned, described, or both. Static HTML websites are made accessible. So are theatrical and dance performances and museum exhibits.

Is Flash so very different that it should be exempted? Hardly.

MX/6: The first hurdle

Macromedia’s new “authoring environment,” Flash MX, and the new Flash Player 6 offer substantial, real, and only slightly incomplete screen reader support. Among other things, you can assign text equivalents (similar to alt and longdesc in HTML) to buttons, input fields, movies, and a few other items, all of which screen readers can find and read out.

Text per se is automatically “exposed” to screen readers, meaning that many parts of many existing Flash sites are instantly made accessible if you’re using Flash Player 6 and the right adaptive technology. Authors don’t have to lift a finger.

Relevant Macromedia sites:

That last item reveals the limitations of MX/6’s accessibility to date. It’s a completed version of the Voluntary Product Accessibility Template created by the Information Technology Industry Council. It’s meant as a quick way to check compliance with 508 regulations.

Macromedia gives some evasive answers and almost begrudgingly concedes Flash’s inadequacies:

  1. Incomplete keyboard access [§1194.21(a)], including an inability to use forms entirely via keyboard [§1194.21(l)]. It’s a much bigger deal than people think; screen readers are notoriously picky in dealing with onscreen forms, and while we need to insist that screen reader manufacturers get their products working properly, accessible code has to be there to use in the first place. (In Flash, the scroll bar, list boxes, and combo boxes are not accessible)
  2. Incomplete control over color choices [§1194.21(g)]. Admittedly difficult or impossible to do; here in the real world, color schemes cannot be randomly or open-endedly replaced
  3. Stop animation [§1194.21(h)]. The spec calls for “at least one non-animated presentation mode”; it is not quite the same to deselect “Play” from the contextual menu on any specific Flash animation. In effect, if you animate something, you have to provide an equivalent unanimated version, which defeats the purpose of animation in many cases
  4. Caption and describe an animation [§1194.22(b)], a severe failing that Macromedia fudges here
  5. Provide a text-only page [§1194.22(k)].  Macromedia cops out and offloads this task onto HTML

HTML equivalence

I just finished writing a book about “traditional” HTML web accessibility, so please believe me when I tell you that the existing Web Content Accessibility Guidelines are outdated and poorly explained. HTML is itself not completely up to the task of making web pages accessible. But the capabilities or HTML are a useful baseline of comparison.

Among the things you can do in HTML that you can’t do in Flash:

  1. Set and change text languages (though you can detect a language setting using ActionScript)
  2. Add titles to nearly everything
  3. Add long descriptions to certain data types (like frames and iframes); Flash does not use equivalent data types, but you can nonetheless make frame- or iframe-like components in Flash
  4. Mark up acronyms and abbreviations (dubiously useful in HTML, but the capability is there)
  5. Include multiple levels of alternative content (like nested <object><object></object></object>, or the many alternatives in <iframe>)
  6. Group and annotate form elements (using input, legend, fieldset, and the like)

Note that some commentators accuse Macromedia of pulling a Microsoft by developing self-contained proprietary programming realms that undermine the universality of HTML and standardized web technologies. Macromedia denies it, but if that happens, Flash has to be at least as accessible as HTML. At present, it isn’t.

Unfair testing

The 508 requirements and the list of what’s possible in HTML are in many ways an unfair comparison. Flash isn’t HTML, and even some of the HTML-specific access capabilities are not very useful (like acronym and abbr). Text-only pages aren’t very useful, either, but they are required under 508. Colorblindness is poorly understood, and the existing requirements, which call for essentially random or arbitrary color replacement, not only are absurd in the real world but don’t necessarily solve the inaccessibility for people with color deficiencies.

HTML has been around long enough that its capacities have influenced accessibility requirements. Accessibility experts are, moreover, generally hostile to good visual design. There’s a considerable bias within web accessibility toward “universal” HTML and away from “proprietary” software like Flash and PDF. People are just gonna have to get over that. DVDs, home videotapes, television, and the movies are all accessible in slightly different but functionally comparable ways. HTML, Flash, PDF, and whatever new technology comes along can all be accessible in their own ways.

This issue may clarify the general objections of some Flash critics. Instead of complaining about Flash-only websites, shouldn’t we be concerned about appropriate alternatives? An HTML site should be available in parallel with a Flash site; the HTML site should be as HTML-like as possible, with the Flash site as Flash-like as possible. You can have similar but not identical content and functions in both sites.

Similarly, Flash-only sites should be as accessible as possible in Flash-specific ways, while HTML-only sites should have HTML-like accessibility. The 508 and WCAG specs as written do not reflect the multiformat reality of the web.


The most significant deficiency in accessible Flash is the absence of primitives—built-in procedures and capabilities—for captioning (for deaf viewers) and audio description (for blind viewers).

Flash animations—even very discreet, tasteful, highly usable animations, including those that do nothing but move text around onscreen—are a form of cinema. Cinematic works are already made accessible in a variety of media and settings (TV; tape and disc; movie houses; online). There is no such thing as a perfect system in any of those media; some access provisions are only barely adequate.

Nonetheless, data structures are already in place for captioning and audio description in non-Flash media. There are, in effect, slots into which you can stick caption text or a recording of an audio description. In “traditional” online video of the QuickTime/Real/Windows Media ilk, we suffer from a profusion of data structures, including RealTextQTtext, SMIL, and SAMI.

It is not particularly easy to add captions and descriptions to traditional online video, which in many ways is significantly worse than very old media like TV. But it is at least possible. (See, for example, MAGpie.) You can hack your way through the existing text primitives in Flash to create a captioned animation; WGBH has a nice example up where caption text, though hard to read (screenfonts remain an issue), is actually selectable.

It is also theoretically possible to add a second audio track using the existing Flash sound structures that will function as descriptive narration.

But the reality is that it remains impossible to caption or describe a Flash animation within a Flash authoring program itself. You the viewer cannot simply select a standardized, universal command in the Flash player itself to turn on captions or descriptions. If there weren’t already a range of small failings in screen reader access, the absence of captions and descriptions alone would be enough to make Flash Player 6 noncompliant with Section 508. As it is, the absence merely makes the player more noncompliant.

Macromedia knows all this, in part because I have talked to them at great length to make sure they (a) don’t overlook captions and descriptions and (b) don’t blow it when they try to implement those features. The issue is that the development team for accessibility at Macromedia is small (never more than four people full-time, usually more like 2½ people). The company wisely chose to get screen reader access working first and worry about everything else later.

I am told that rudimentary captioning support will appear in a dot-level Flash upgrade this year or next. It is a fair supposition that MAGpie will play a large role. Freebie suggestion: Add support for SMIL, which is a full-fledged W3C recommendation.

There remains the general problem, applicable to all audiovisual media, of the lack of training in accessibility, which Macromedia developers will not be able to solve but must eventually be solved anyway by someone, somewhere, somehow. Even if we had a perfect technical infrastructure for audiovisual accessibility, there’s no training on how to do it properly. I’m very involved in that process (see the warning about subtitling your own DVDs); news on that front will likely be announced in 2002.

Authoring tools and competition

As it turns out, accessibility is much more sweeping than it appears on first blush. Two categories of software—programs used to create websites, and browsers—must themselves be accessible. It’s not enough for data (like a .html or .swf file) to be accessible; all the software you use to create, view, browse, or enjoy those files has to be accessible, too. In the Web Accessibility Initiative terminology, this is known as authoring-tool and user-agent accessibility.

Flash MX, Dreamweaver, Homesite, Freehand, and other Macromedia products do not meet even minimal accessibility guidelines. (These, too, are implicated by Section 508, by the way.) Then again, nothing outside of WAI testbed projects meets the specs, and nothing probably will meet the specs for a couple of years.

Also in Macromedia’s defense, its chief rival, Adobe, has a highly imperfect accessibility record, too. PDF and other Adobe-centric issues will be the focus of a future article.

A good start

Macromedia has taken serious steps to fix its accessibility deficiencies. There’s still a lot that’s missing, but Macromedia is aware of nearly everything that needs to be done and will presumably fix it all. (They have no choice, really, if they want to keep the U.S. government as a customer.) Macromedia has not been open and upfront enough about what its software cannot yet do, and has not quite admitted that it’s still not Section 508-compliant, which U.S. government buyers (and now everyone else) knows anyway.

Still, the Macromedia case is a concrete example of a high-profile company with a kewl product embracing accessibility in an unbegrudging way.

So what’s your excuse?

Tossed gauntlet

Footnoted public declaration: Once Macromedia gets captioning and description and a few other odds ’n’ ends taken care of, I hereby volunteer to do any necessary amount of work on one or more Josh Davis Flash projects. Yes, we are going to make Praystation or moral equivalent fully and elegantly accessible, at which point everyone who ever doubted it was possible will just have to shut up.

Could people in the know please notify Josh Davis of this plan?

30 Reader Comments

Load Comments