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.
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#section1
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:
- IBM Home Page Reader
- JAWS (by Freedom Scientific)
- Window-Eyes (by GW Micro)
- Outspoken (by ALVA Access Group)
- 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
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
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?#section2
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.
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
(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
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.
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#section3
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
longdesc in HTML) to buttons, input fields, movies, and
a few other items, all of which screen readers can find and read
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
gives some evasive answers and almost begrudgingly concedes
- 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)
- Incomplete control over color choices
difficult or impossible to do; here in the real world, color schemes cannot be randomly or open-endedly replaced
- 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
- Caption and describe an animation [§1194.22(b)], a severe
failing that Macromedia fudges here
- Provide a text-only page [§1194.22(k)]. Macromedia cops
out and offloads this task onto HTML
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:
- Set and change text languages (though you can
detect a language setting using ActionScript)
titles to nearly everything
- 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
- Mark up acronyms and abbreviations (dubiously useful in
HTML, but the capability is there)
- Include multiple levels of alternative content (like
or the many alternatives in
- Group and annotate form elements (using
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.
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
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
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
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 RealText, QTtext, 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
It is also theoretically possible to add a second audio track using
the existing Flash sound structures that will function as descriptive
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
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#section7
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#section8
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?
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?