Flash Access: Unclear on the Concept

In Christian theology, it doesn’t matter exactly when you accept Jesus Christ as your personal saviour. As long as you do it before you croak and ask forgiveness for your sins, you’re in like Flynn.

This, apparently, is the Macromedia philosophy when it comes to accessibility.

The company’s flagship product, Flash, is intrinsically inaccessible to anyone who cannot see properly and is very often inaccessible to a deaf or hard-of-hearing person. It’s also completely inaccessible on slow computers or any machine that lacks the Flash plug-in, rendering those viewers more functionally disabled than they actually are.

Macromedia has, however, undergone a kind of latter-day conversion and has called Father Mulcahy over to the rhinestone-bedecked four-poster bed from which it wheezingly receives callers. Suddenly Macromedia has got religion when it comes to access, repenting at last for years of inaccessibility.

“The Web’s for everybody,” Macromedia CEO Rob Burgess says. He may indeed have come to believe that, albeit belatedly.

What’s the catch? The Macromedia kids have had years to learn, but appear to know very little about accessibility. I’ll get to a psychological examination of Macromedia and its legions of devout Flashistas later, but let’s start at the beginning.

Beyond the press release#section2

Macromedia executives would make excellent politicians, skilled as they are at co-opting the vocabulary of their critics. Macromedia issued a set of press releases and backgrounders on its forthcoming accessibility range, which applies not only to Flash but to Dreamweaver and other products:

• Press release
• Product features supporting accessibility
• New tools for evaluating accessibility

Macromedia makes great hay of tying its many new offerings to the World Wide Web Consortium’s accessibility guidelines – name-dropping them, in effect. (In an extra bit of deliciousness, most of those links above lead to frame-based pages, eliciting this complaint for “unapproved” browsers: “Your Web browser does not support frames. Please upgrade to the latest Netscape or Internet Explorer browser.” Love that accessibility, Macro!)

Now, I go back over 20 years in accessibility. When I read the specifics of Macromedia’s accessibility plans, I got worried.

Definitions#section3

Accessibility is poorly understood. That’s because, while disability is commonplace in human society, sensory disabilities are relatively rare. If you aren’t black and/or American, you might think you know a lot about U.S. black culture because you’ve seen every Spike Lee film, but a kind of cultural awareness of deafness or blindness is very hard to come by, and few of you will have deaf or blind friends whose experiences you can learn from.

Moreover, while access for disabled persons has received some attention, it isn’t widely accepted that old-school techniques like subtitling and dubbing do, in fact, constitute accessibility. This idea seems never to have occurred to Macromedia in particular.

So, as an introductory lesson in media access, let’s spend a moment getting to know the Big Four media-access techniques. Later we’ll explore how they relate to the Web and Flash.

Now a word about adaptive technology. There are few, if any, specialized hardware or software products used by deaf and hard-of-hearing net-surfers, in large part because the Web, as a visual medium, is rarely inaccessible to that group. Blind and visually-impaired netters, however, tend to use one or more of the following:

1. Screen magnification: Software blows up the image on a standard or auxiliary monitor. May also change the onscreen colours or move text from left to right in an inset window.
2. Screen readers: Software and hardware that reads Web pages out loud in a computer voice. On the net, most modern screen readers sit on top of standard Web browsers. You usually control a screen reader by keyboard, not mouse.
3. Braille displays: Despite the common misconception, very few blind people read Braille, and it’s a somewhat inefficient way to handle text-dense Web pages. Braille displays can produce a single line of Braille or many lines. (These days the most famous user of a Braille display is Bruce Maguire, who launched a successful action against the Sydney Organizing Committee forthe Olympic Games’ inaccessible Web site.)

Online accessibility#section4

The two fundamental principles in online accessibility are serving everyone and providing alternatives. An accessible Web site functions for any visitor regardless of characteristics they cannot change.

Accessibility revolves around words.

• To be accessible, a picture requires words, if not a thousand of them. The words might be written or spoken.
• Where there’s audio or some kind of narrative soundtrack (e.g., a dance film), you need to render the soundtrack in visible (or at least capturable) words.
• Words in one language may need to be translated – in speech or in writing.

When creating soundless Flash animations, in virtually all cases the correct accessibility technique is description. You can do it in two ways: Text or speech.

1. In HTML, the most basic access provision for a static image is an ALT text – a few words identifying the image that will be displayed if your browser can’t load the image. In HTML 4, the LONGDESC feature was added: You can specify a separate file that provides as long a textual description of an image as you like. It is, however, difficult to acquire the skill of encapsulating a visual image in words. (Few browsers or assistive devices support LONGDESC – at present. iCab and pwWebSpeak, a screen reader, understand LONGDESC; see the Break This Page! experiment for details.) These approaches are conceptually transferable to Flash even if we don’t end up using ALT and LONGDESC per se.
2. It may also be appropriate to produce audio description. A.D. is even harder to do than writing out a LONGDESC. In fact, it’s so hard that even companies claiming to do it professionally make tons of mistakes.

The difficulty of training authors to provide their own accessibility is one issue, an artistic one. Let’s start, however, with the basics of making it even technically possible to add access features.

An open questionnaire#section5

There is ample evidence that Macromedia does not actually understand the requirements of accessible Flash. The company seems to have glanced at the World Wide Web Consortium’s accessibility guidelines and settled on the most minimal and expedient “solution” to each of those checkpoints. Even if a Flash developer assiduously made use of all the fledgling, half-hearted access provisions of the new Flash plug-ins, you still would not end up with an accessible file.

Here are some passages from Macromedia’s announcement, plus a few open questions for Macromedia and anyone who’s interested. Still waiting for some answers.

(This is not an ambush. Macromedia has seen these questions at least three different ways, and, prompted by them, a Macromedia functionary rang me up. We had a pleasant discussion that proved the company doesn’t know what it is up against.)

Content Controls#section6

Macromedia Flash allows developers to provide a control menu that can stop, pause, fast -orward or rewind Macromedia Flash content so users can magnify or replay content as needed. These content controls are available in the JavaScript Integration Kit.

1. Are we talking about an absolutely standardized navigation control, similar in universality to the Back and Forward buttons and keyboard commands in browsers? Or will each designer be able to write his or her own special commands that differ from other sites?
2. Are the controls themselves accessible? They’d have to be so, because screen readers cannot interpret even a big button in a Flash file that reads REW in a bitmapped font. Adaptive technology has to be able to interpret the underlying sense or function of an interface widget.

Alternate Text#section7

Macromedia Flash allows developers to provide text representations of Flash content for browsers that do not support Macromedia Flash. The alternate text generated by this feature can be understood by assistive devices.

I get the impression Macromedia has a 1995-era mental image of how accessibility works, one that isn’t even current for static images, let alone animation. Even W3 accessibility guidelines, while requiring ALT in HTML 4, also recommend the use of TITLE and LONGDESC for static images. For moving imagery in Flash, what we need are captions and text and audio descriptions, not ALT-style five-word placeholders.

Does Macromedia mean to say that accessible Flash:

1. will provide accessible, universal onscreen and keyboard controls that will turn on and off captions, text and audio descriptions, subtitles, dubs, and any other access features built into the file – controls that will always be the same at every site?
2. will contain new data structures for at least those Big Four access technologies, akin to what QuickTime has? The result would be a form of closed captioning, subtitling, description, or dubbing – alternate tracks you could turn off and on. (That is not the best approach anymore in the first place. Every attempt at creating closed access online has failed. It is now much easier to produce entirely separate files with access provisions you cannot turn off, and merely select the file you want.)
3. will provide a single ALT-text-like phrase to sum up an entire Flash movie? (How many Flash files have you seen that could be epitomized in a few words?)
4. will enable authors to embed a stream of text and audio annotations that, when experienced along with the actual movie, provide an experience like watching a movie or TV show with captions and audio descriptions (or at least one of those)?

What work did Macromedia do in thoroughly researching and understanding how accessibility is actually achieved in the real world?

Customized Color Swatches#section8

Web graphics – especially those containing text – must have adequate contrast between foreground and background to be seen clearly by users with certain visual disabilities. In Macromedia Flash, custom color swatch panels can be used to save and share examples of optimal contrast in hue and saturation of Web graphics.

The HTML parallel here is user stylesheets and browser settings that let you force your own foreground/background colours on a page irrespective of what the author selected.

1. Will I be able to specify that I want white foreground and black background no matter what? Or will developers have to choose to include an alternate colour-swatch set, which I could then select?
2. How do I know it’s there in the first place? What standardized indicators has Macromedia developed so that my screen reader, or some other assistive technology, or my naked eye or ear will be able to note that this choice is even possible?
3. How can this provision meet the intended goal – providing colour schemes a specific visually-impaired individual finds comfortable – if the designer has to make a guess (invariably not an educated one) as to which alternate colours to choose?
4. How will designers find it attractive to redesign their entire Flash file for an alternate colour scheme? That’s more than twice the work, because colour is not a layer of paint: It’s intrinsic to a design. A high-contrast alternative design (to use an example) will force a complete rethink of each component of the file.

Upcoming: Macromedia Flash Accessibility Developers Kit#section9

Macromedia is building a kit to guide developers of accessible Macromedia Flash content. The Macromedia Flash Accessibility Kit, containing guidelines, Smart Clips, sample code, and more, will be available by the end of the year for free download.

Well, what good will the developer kit do if it is in any way an add-on or an option? As we know from the experience of authoring programs (including Dreamweaver), if you don’t show a dialogue box that includes all the possible access tags (like COLGROUP or OPTGROUP or LONGDESC) and have it in the face of a designer every day forever, the designer (a) won’t know the tag is there, (b) won’t use it, (c) will have to manually code such access tags if he or she, for some reason, even knows they exist and accepts they’re important. And some of these tags, like COLGROUP, are so hard to understand that they really need automated help.

So the question is: Why make a Flash accessibility kit an option? Why shouldn’t developers be forced to at least look at every possible access provision during all steps of authoring and have to make a conscious choice to include or exclude such functions? Only a tiny minority of developers will order the optional access kit, which in itself is inadequate.

How, exactly, does this ensure that Flash “content” will be accessible in the future?

The “authoring” buzzword#section10

A word about the term “authoring.” It’s a convenient buzzword, like “special rights” or “left to pursue other opportunities” or “functionality,” that seems to sum things up nice and cleanly but actually camouflages more than it reveals.

When you think “authoring,” you think of creating a file that meets technical standards. Or, in old media, “authoring” can mean “create a master” (e.g., “authoring a DVD”). In neither case is there any reference to content. You can use an authoring tool to create content. People type away in Dreamweaver and GoLive every day. But the fact remains that “authoring tools” exist to automate technical drudgery.

Technical drudgery is almost nonexistent in accessible media. It’s nearly all artistic. Flash “authoring” tools do let you create actual artistic content, and the mindset of Flash “authors” has evolved to include that specific kind of art under the big tent of “authoring.”

But an “authoring” tool isn’t going to help you create accessible Flash, with the tiny exception of setting up ALT and LONGDESC tags or their equivalent.

What’s really needed#section11

Macromedia is arriving at the accessibility party unfashionably late. It is already too late to retrofit accessibility on thousands of Flash movies. Macromedia’s planned access kit will not be sufficient to make Flash “content” truly accessible.

Quite likely, accessible Flash is a lost cause. Even if absolutely perfect authoring tools were available, we face the barrier of Flash authors. They’re even worse than HTML designers: Young guys, with little life experience, impressed with the way-cool designs they can create. That life experience is crucial: Hotshot Web designer d00dz design sites for people like themselves. And that means young guys with a preference for high-colour, chop-socky imagery suitable for video games.

There is no understanding that such approaches might be improper from an art-direction or usability perspective, as they so very often are. It is hopeless to expect these lads to go out of their way to program alternate readable and audible text analogues of the martial-arts movie they’ve created in Flash for their “bleeding-edge” client. They just aren’t that mature.

These “designers,” and I do use the term loosely, will work any necessary number of billable hours to create that selfsame sexy Flash animation (and even fire clients if they don’t play along), but the idea of adding a few more hours to make it accessible will be greeted with “The client won’t pay for that.” What that really means is “We don’t believe in it. We don’t get it. We certainly aren’t interested in selling the client on it.”

At this point in the narrative, the minority of Flash developers who understand accessibility and have a more worldly outlook are up in arms at having been stereotyped. And well they should be. The excesses of Flash are shameful, and the excesses are due largely to these hotshot boy-wonder programmer d00dz who have spent the last three years soiling the swimming pool.

To achieve accessible Flash “content,” we’ll need much more extensive authoring tools than exist anywhere in the world. A developer will need to be able to create simple text analogues like ALT and LONGDESC, complete audio descriptions, captions, subtitling, and dubbing. That is a tall order.

Taller still is the process of educating developers not only in the need for such provisions, but how to execute them properly. That will entail teaching visualist designers to write – a formidable task, through no fault of the designers’ own; if writing were their true means of expression, they wouldn’t be designers. It will entail a mastery of frustratingly obscure and deceptively difficult techniques: Captioning so much as an aspirin commercial is not an easy, self-evident, or straightforwrad task. Audio description of highly experimental audiovisual works like Flash animations (particularly of the Once-Upon-a-Forest or Praystation calibre) has never been attempted; there is no prototype.

There are no publicly-available manuals for captioning, subtitling, or dubbing; there is exactly one set of U.K. guidelines for audio description (links and commentary). As with typography, developing an understanding of these media takes time and a very great deal of exposure. Current Flash authors spend very little time watching accessible media as they are presently known.

The artistic barrier, then, greatly exceeds the issue of technical capability. Even with perfect data structures in Flash and near-universal browser compatibility, Flash authors won’t know what to do.

Macromedia, then, has opened up a very big can of worms. What all audiovisual media badly need is a very comprehensive, multilingual, intrinsically accessible instruction guide for making traditional and “new” media accessible. It’s the sort of thing that Macromedia, archrival Adobe, Apple, Microsoft, and one of the Wintel manufacturers should jointly fund. It will cost lots of money, but it’s an absolute necessity.

As with the entire discussion of Flashturbation and the inappropriateness of Flash as it is most commonly used, “the developer community” has a very large contribution to add in making Flash accessible. It’s time for responsible Flash authors to exert pressure – including peer pressure – to do accessibility right.

Like this:#section12

Like Loading...