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#section2
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 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?#section3
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#section4
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:
- 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
[§1194.21(g)]. Admittedly
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
HTML equivalence#section5
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) - Add
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
nested
<object><object></object></object>,
or the many alternatives in<iframe>) - 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#section6
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.
Multimedia#section7
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 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
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#section8
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#section9
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#section10
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?
Overall a good article, …
While it is certainly accessible to put tables in a web page, the carte blanche – *go ahead and use them*, seemed a tad irresponsible and lacking. This statement missed the point that if tables are used, they neeed to be written or marked up correctly in order to be delivered in an accessible way. Not ALL readers deliver or access table information in the same way. And not too many people are aware of the linear output of complicated tables, orthe techniques of associating data in the correct way.
Missing also are the good points of multimedia delivery and how Flash may make content more accessible to those that need more than text, which may be most of the population. This higher percentages also includes those with cognitive and or learning disabilities, and even those with no disability or access issues. Multimedia is a tool to deliver content with good functional design abilities and higher reaching results than text only. Yes, alternatives are needed for those that cannot access the information. But accessibility and multimedia includes these areas, too. They are often overlooked, because most of the focus is on visual first, hearing, then motor, and cognitive issues remain in last place or forgotten. [important issues for delivery of content via education]
Finally a rather pointed question…
Where is all the anger or pressing active questions that needs to be directed at Mac equipment?
Are Mac’s going to ever be made to work with accessibility in better ways? I understand many or most of the readers work with Windows systems, but with Mac OSX is it not possible to run these under Virtual Windows mode?
I think it is great, no matter what the reason, Macromedia is working on Accessibility issues. I had seen some of this come about back in 2000, following the Jim Heid article…
“A Call to Action: Making Flash Accessible,”?
http://www.heidsite.com/archives/Flashaccess.html
Now, we also need to look at GoLive, Premier, and many more… and I see that was mentioned and I will be looking forward to reading more about these other topics.
One last point. Often it is displayed that the software or computer, etc … is the culprit to meeting Accessibility issues or guidelines. Many times it can also be said the equipment that these users do use and the companies that make this equipment – also have to get on the ball and rework or improve their products to meet these guidelines that others have met. This is not an easy issue and the responsibility belongs to everyone. The equipment, the software companies, the browsers, and lastly also the people using the equipment to access such information. If others are working to conform, the equipment should also conform on the flip side. And this will all take time.
Thank you.
I have one question, how do you make PhotoShop accessible to someone that is blind?
Is this even necessary?
I can understand improvinge PS’s keyboard access, but I have a hard time justifying the cost making the program accessible to someone who can’t see at all. It is, afterall a program for creating and editing visual imagery.
Would lack of support for blind users disquallify PS as a tool for government agencies?
Seems kind of unreasable if it does.
The concern or area re accessibility in graphics tools mostly involves motor issues? Maybe some cognitive issues(??) – then again most GUI’s could use a bit of improvement to even average audiences.
On the flip side, there probably are people with visual difficulties using graphics tools.
[1] Color vision differences – In this area it may or might be important that any tool icon or device in an app, have enough contrast so that the item can be distinguished.
There may also be fully or partially color blind users, using Photoshop or any other graphics tool, putting out black and white imagery.
[2] Aging populations, and low vision users may need icons or graphics on icons to have the ability to enlarge enough to see these. However, maybe their OS offers this functionality on their own work spaces, though I am not sure if this translates to all software installed?
Regarding blind users and applications, I know several that write and design or code web sites, use FTP, teach using the internet and online delivery of material, and also program… so yes these tools do need appropriate functionality for blind users.
This was an excellent article, Joe.
“While it is certainly accessible to put tables in a web page, the carte blanche – *go ahead and use them*, seemed a tad irresponsible and lacking. – anon.”
Don’t get too worked up over this. I don’t think he needs to get into all of the details of HTML table markup in an article about Flash accessibility.
Oh, and if Apple wants to continue selling their computers to schools then they had better get up to speed with accessibility. And fast.
Many states are implementing their own accessibility guidelines for web sites, or they are just mandating that their agencies have to follow 508. So many people do not understand what this means, and just shrug it off. It’s quite a shame, since this legislation will eventually be more closely associated with the Americans with Disabilities Act. And when that happens, everyone will get a serious wake-up call. Just ask the folks in Australia about Maguire v. SOCOG.
The web is still in its infancy. Accessibility requirments are going to make it grow up.
The author ends the article volunteering to make Praystation fully accessible. No one would put to doubt the importance of accessibility today, but that’s not the quid of the question.
The real matter is: Why? What for?
Making an all-visual site like Praystation accesible for screen readers doesn’t make more sense than creating an audible tour for blind people at a museum – unless 508 compliance extends as a mandatory term for web sites, and, with all respects, that is quite a stretch indeed. Having all sites be measured with the same stick falls quite off the mark. A general interest site like Yahoo and a designer’s portfolio site attract to very different audiences with very different interests. Accessibility is always a lofty goal, but its importance scale depends very much on the type of site, its usual audience, and many other factors in between.
Besides, I don’t think Joshua Davis would give a damn about it all.
I notice that Davis’ Praystation seems to use Flash objects for navigation as well as for the artworks themselves.
It really depends on whether Davis wants to open his artworks to the general public or not. I don’t think private art galleries are *required* by law to have audio tours or accomodations for people with disabilities.
But doesn’t the lack of such accommodation cause art to suffer? Doesn’t the artist create something for the world to experience and think about? If some are shut out from the experience, what’s the point?
I explained perfectly well why Praystation should be made accessible: To show that it can be done. I’m just not very big on deciding for the crips which kinds of information they will and will not have access to. Wordless music videos and live dance performances are made accessible. I don’t see how Flash is so very, very special. I could be missing something here, though. I probably am.
I agree, Joe, that using Flash does not relieve the burden of accessibility. If you argued for that, you’d also have to argue that all visual art be excluded, and that’s simply not a fair argument.
I also understand, Joe, why you’d want to make Praystation accessible– it is definitely an artistic and visual implementation using Flash. If that can be made accessible, then you’ve removed the argument that Flash artworks can’t be made accessible.
However, Josh Davis has made it clear that PrayStation is his online sketch pad, and damn all the opinions people have about it. It’s certainly within his rights to make that site.
Certainly, I support accessibility, but I can’t think that the newbie learning Flash or the granny sharing a picture collection can (or should) be expected to be knowledgable on the needs of all people worldwide.
This, it can never be required that all web pages be accessible, as the web is intended to be an open forum for all kinds of documents.
To another point:
Even if Macromedia does all of this work to make their products accessible, let’s not forget that the desktop browser is not the web. Alternate representations of Flash sites should still be made available.
Flash may be a great tool for animation and artistic rendering, but the person using Lynx or surfing your site on their voice browser will likely not be impressed by alt text saying they need the Flash plugin.
And that is why I am more for W3C recommendations. With the work on ECMAScript, DOM, SVG and SMIL (for example), I think that an open implementation to rival Flash may be forthcoming, in good time (Call me a hopeless optimist) .
Meanwhile, I’ll stick to my non-Flash implementations, thanks. 🙂
Now that a screenreader can access Flash content, I have one question: why can’t my browser’s Edit -> Find? That would also be a major vistory for usability and it’s a shame that hasn’t been implemented as-of-yet.
Praystation may be Josh’s personal experimental sketch pad, but surely that is the perfect place to start to experiment with accessible, art based media. A big enough challenge to excite…
On the other hand, what about approaching WDDG, Digit, Hillman Curtis, or another of the Design Agency Flash sites that perhaps more use for Flash Accessibility.
I am definitely missing the point.
Making websites accessible to disabilitied people is good. However, moving information into a visual format and then translating it back into a linear medium seems quite backwards.
Joe, the point is that even though it CAN be done, that does not mean it should. It will be more efficient and just make more sense to keep a seperate formatting process. Different audience, different medium, different tool.
My friend cannot use his legs, yet his car is modified so he can still drive. However, bike designers do not create their bikes with him in mind. So? The transportation industry still delivers him pt A to pt B.
While it is NICE that flash has this capablity, the reality is that generally a more personalized and site specific disabilitied equivilant will be more effective than the garbled feedback from an approach like this. When recording music, we try having the source as direct as possible with a minimal amount of routing points. This sends the signal to a digital converter and then back into analog.
Thought it said preview under the msg box 🙂 What I meant to say at the end was that the approach of using flash for the disabilitied was like sending an analog signal into a digital converter and then back into analog.
Dreamweaver is a product that I use in building the web, but I find that I need to always modify the code to make it W3C compliant. I want Macromedia to make their products compliant with Section 508.
I think it is not only the company’s responsibility to ensure that compliant code is written for these programs, (as well as other companies’ programs), but it is the users responsiblity to push for changes to be made in order to futher the cause. We need to write to companies like Macromedia, Adobe, etc., and tell them that we want to have our future products, (Dreamweaver, Flash, GoLive, etc.,) accessable to the disabled. We are their CLIENTS, and we keep their companies running. I think they need to be reminded of that fact.
With all respect Leo, you are definitely missing the point.
‘moving information into a visual format and then translating it back into a linear medium seems quite backwards.’
We are not talking about converting an interaction design into a linear narrative – the examples of narrated and closed-captioned rich media were used as examples, screen readers and alternative input devices allow just as much interaction as a standard browser, why should flash get in the way?
The analogy of conversion to and from analogue really only comes up in certain visually dense information media, like charts and maps, the reason we use which is specifically *because* you cannot really understand the data any other way.
In any event, if you stop thinking of making Praystation accessible as a question of screen-reader access to alt texts, things become more manageable. Flash animations are cinematic and cinema calls for audio description. That, plus alternative texts and all the usual access to interface elements (still imperfect in Flash), will do the trick.
Why not just make web pages, and documents available via the phone? That totally solves accessibility for all types of disabled users who cannot see or use their limbs properly. The deaf still can read on the screen which for most sites, thats all that really is neccessary. My company has a product that lets blind persons listen and navigate books and documents via any telephone using the sound of their voice.
The interaction is still possible, through dhtml, which seems to be more geared for it. The nature of flash goes against mass text display, while hyperlinks and bookmarks are ideal for it.
Can you please explain the why? Why would we make a graphical nav, test it, then go through changing bits and pieces for a text nav, and test it, vs doing 2 seperate designs? Not because of 508 or regulations, but in practice.
I am not arguing nobody should do this, and obviously an html/pdf etc version can be packaged alongside the swf, I am just curious as to why it makes more sense to approach it this way. (Not a couple of advantages, but why it outweighs the other approaches).
I’m surprised that no one has raised the point that Josh Davis’ work is already very powerfully “described” auditorily.
While I can understand interpreting dance and explaining the movement to a visually impaired viewer I’m not convinced that this is akin to trying to translate the pieces on Praystation. You could write a script to direct the dancers and explain to them how to move, seal it in a time capsule and be fairly confident that the person who opens it up could direct a group to preform something that resembled the original effectively translating the movement into words. Praystation’s scripts are interpreted by the computer and are created with the intent of never achieving the same result twice. Would describing what’s happening in words take away from the soul of the work?
Don’t the haunting works of Shapeshifter and Josh’s own found sounds lend more of an “auditory explanation” — or sympathetic experience — to the visuals than a screen reader could?
Wy
Leo, you mentioned converting something from analog to digital, only to turn around and translate it back to analog. Actually, it’s more like translating it to digial, but keeping the analog available in case anyone wants to use it.
Take a typical film, for example. You start with a script, then create a storyboard, then shoot the raw footage and record the sound, edit everything togther, and then present it, (then have a big party afterward). Someone who is blind might not be able to see the footage you’ve shot, but they sure can listen to the soundtrack and dialog. They could also read the script, or have it read to them. Question is: Will you let them?
There was a great CD-ROM put out years ago by Art Speigleman and Voyager, which was essentially a multimedia version of his comic novel Maus. Instead of replacing the original book, it enhanced it. You could add notes, bookmark pages, listen to audio commentary, view sketches of various panels, and review source materials. It was an amazing work.
Wouldn’t it make more sense to make another swf at that point with full text instead of using basic labels?
It is similar to the img alt tag thing – they are useful while loading a page and on mouse overs, but it is more user friendly to have a unique text only version more specific to the medium rather.
As for the challenge: would that be using built-in usabilty features or creating a full seperate project? In my eye, that is the same thing, with one forcing a handicap of staying within the original media design.
Unfortunatly when dealing with all the US gov’t it has to be compliant. So I agree with “how would a blind indivdual use photoshop”, or “the analogie of a website being like McDonalds, and McDonalds has access so so should a website”
What is all comes down to when designing for the gov’t, which I do, it has to be compliant with 508. So creativity goes down the drain. Thought of flash are never in my mind. Perhaps in a couple years when the technology catches up with the legislation I will be able to utilize it. But until then it is just basic HTML.
Good Day
What is wrong with basic HTML websites? Have we gotten that far into technology that we cannot accept that creativity and design can also be incredibly simple? The technology doesn’t make the design. I mean, great movies that use amazing CG doesn’t make it a better movie than one that does not. I think we should try to make the web content accessible to as many as possible – this also included reducing the browser-dependent page designs. And while we’re making all these presumptions about what those with various disabilities would like to access on the web, has anyone thought to ask them? I would argue that even though one cannot see does not mean that he or she could not successfully use Photoshop – every visual person definitely cannot use the program. Didn’t we get over segregation years ago? Compliancy to section 508 and making websites accessible does not exclude creativity – it just actually makes you think more and use technology less. I find it an almost welcome change – how many terrible dhtml/flash websites have you seen? I don’t have anything against the technology other than when it stops being accessible or even used in a way that makes it cool for everyone. Numerous Javascript popup windows have killed my taste for personally using Javascript although I appreciate it when others do it well without taxing my user experience.
I have a qestion.
How can may I make alpha blending and motion tweening a bit more eye catching for a 3 minute animation?
If anyone is having trouble using the “Feature Grid” link in the article, try this one http://dynamic.macromedia.com/bin/MM/software/trial/hwswrec.jsp?product=vpat but be prepared to fill in a questionnaire if you can’t/won’t login…
The Macromedia site is of course shockingly inaccessible and the link to the HTML version is buried so well I only found it by accident. Bah.
If anyone know this please let me know!
I just made a flash banner 468×60 and when i tried to publish it into .gif file it comes out over 200Kb to about 600Kb. But the .swf file comes out to about 6Kb.
Can anyone tell me what’s the problem??
Your problem is that you are using Flash to do what should be done with standard, open formats. Is it text? Use text (HTML or XHTML). Is it a graphic? Use a graphic (PNG or JPEG). Is it interactive? Use a combination of HTML, CSS, and JavaScript (aka “DHTML”). Flash is destroying the web one URL at a time, and it’s long past time that we as web developers took a stand and refused to use, view, or recommend it.
Hi, Is anybody out there know about the Flash captioning tool? I read an article saying that it will be out as a freeware from Macromedia in June but I can’t find anything from Macromedia website.
code of flash with keyword
Brandon,
ever heard of browser quirks when implementing DHTML?
(there are, even with gen 6/7 browsers.., NN7 is quite ok, NN6 is not!)
Besides, DHTML can’t do what open format SVG can;
as long as SVG is not widely available it’ll be Flash for sophisticated animation, I guess.
Marek
Brandon,
ever heard of browser quirks when implementing DHTML?
(there are, even with gen 6/7 browsers.., NN7 is quite ok, NN6 is not!)
Besides, DHTML can’t do what open format SVG can;
as long as SVG is not widely available it’ll be Flash for sophisticated animation, I guess.
Marek