JavaScript vs. Flash for Animation | WebReference

JavaScript vs. Flash for Animation

By Lisha Sterling

Digg This Add to

When you think of interactive multimedia on the Web, you probably think of Flash. Flash offers the webmaster a single platform to create content that will be seen by the majority of Web site users, and that everyone who sees Flash will be able to interact with it in exactly the same way. However, there are some arguments against Flash, and many webmasters choose to use Flash in only limited pockets within their site. What many people don't realize is that you can create similar experiences in JavaScript, and by doing so you can avoid many of the problems inherent in Flash.

Problems with Flash


One of the major problems with Flash is that it presents difficulties for many people with disabilities. For some the issues are in translation from Flash to the screen reader. For others the big problem is the lack of keyboard navigation options in most Flash animations. For those who cannot use a mouse, an animation that requires mouse clicks is of no use.

If you think that accessibility isn't important for your US-based Web site, you might want to think again. The Americans with Disabilities Act (ADA) was specifically extended to Web and other electronic media in the enforceable policy codified in 2001. Since then there have been a few high profile court cases, including the 2004 case in New York against Cendant, Inc. (owners of and and the 2006 case against Target. And even if the ADA doesn't apply to you, it makes sense to think about this audience when you create Web content, since the tools for online accessibility can be a cost effective way to do good and generate more business at the same time.

It's possible to create somewhat accessible animations with Flash technology, but there are several problems with it. For one thing, Flash accessibility tools are only available to those using Windows and Microsoft Internet Explorer. For those using a non-IE based speech browser or a speech browser on another platform, Flash is unusable. There's also a problem with Flash animations, even with the best accessibility options, because every time the screen changes, the reader returns to the top of the page. You can imagine, then, how your lovely animation sounds to your sight impaired users.

Search Engine Friendliness

The next major problem is Flash doesn't work well with search engines. While there are capabilities within search engines to index Flash, they do it poorly. The Macromedia Flash Search Engine SDK has been around for years, but you're unlikely to see any Flash-only Web site show up properly in a free search engine. The same issues that make Flash inaccessible to people with disabilities also makes it inaccessible to indexing spiders. For all intents and purposes, spiders are deaf, dumb and physically unable to navigate fully with a mouse.

For an example of this problem, have a look at the Web site, an online boutique art stock agency with a collection of digitized work catering to Interior Designers and the Hospitality Industry. Type in "decorstock" on Google and you'll get a listing for the Web site and a few articles about the company. Type in " people" and you get no returns. Try "stock art fine" and you'll get bored of clicking through pages before finding DecorStock.

Due to the indexing issue, top search engine information sites still advise Flash-only sites to create secondary HTML sites so they won't disappear into thin air. DecorStock is having to create a new search engine optimization strategy, where their Flash site is supplemented by a spider-friendly browse index of the artwork in their database.

Poor degradation

The next major issue for Flash is it doesn't fail well. When a Web application is said to degrade well, it means that even if an end user doesn't have the latest and the greatest software, they'll still have some content, and will be able to interact at some level with your application. Unfortunately, if a user doesn't have Flash at all, or if they don't have the right version of Flash, they'll get nothing but a hole where Flash ought to be.

One of the main reasons to use Flash is it allows you to create rich, interactive multimedia experiences on the Web that work across the major browsers in all the popular operating systems without the need to test your content on each platform. If Flash works on one platform, it will work on all platforms that have that version of the Flash plugin.

However, that ignores the fact that there are various reasons why someone might not have the same version of Flash on their system, or any Flash at all. Plugin versions aren't always released for all platforms at the same time, and some less popular platforms can be one or two versions behind. The user may be a disabled person who has already learned that trying to run Flash makes it harder to navigate a page. The user may be on an office or school computer where Flash has been banned. And users on some Linux distributions or BSD, especially those who are running their *Nix on an x86-64 architecture may not have the option of installing Flash at all. No matter what the reason is for the Flash-less browser, you want users to stay at your site.

One can even argue that Flash helps lock in existing platforms and slows the uptake of new ones because of the time lag in developing plugins for the new platforms. It also punishes those who are early adopters of systems that don't include the non-standards compliant Flash.

Using JavaScript

These days, you can use JavaScript libraries that work fantastically across almost all platforms, and with a little thought you can ensure that you're still presenting usable content to users who don't have JavaScript enabled. Consider, for instance, the heavy use of JavaScript in sites like Google Maps or Yahoo!Mail. They work well for almost everyone as-is, and the lower-featured HTML-only versions kick in if your JavaScript isn't working. You can also see this in action at the Official Ringo Starr Website, which I coded while working for Signatures Network in San Francisco. On that site, I created all of the header and rollover button animations in JavaScript. The animations even work in IE on a Mac (one of the browsers for which everyone says "you'll never make it work there"), and if you turn off JavaScript, you still have a usable site with still versions of the graphics. There are no holes, no plugin suggestions, just a site that works.

The non-JavaScript version was written by adding a no script tag with the static versions of the images and links. This is such a simple solution, and it didn't take hours to write a second version. In fact, the no script version was the version I started with in order to get the images aligned before writing the animation flows.

With JavaScript and CSS, you can write accessibility into the site from the beginning. For any mouse-driven action, you can create a keyboard equivalent with as little as a single line added to your code. Of course, it's important to add alt tags to images whenever they have bearing on the usability of the page. You can set the tab order of the elements in your page so a mouse-less user can navigate in a logical way based on the flow of information rather than the default order in the browser. CSS even includes standards for telling screen readers what voices to use, these can be added to your definitions for bolded text or headers, giving a customized experience similar to the one that sighted users receive.

Another advantage of JavaScript is that the code to make an animation flutter across the entire screen is no bigger than one that flutters across a small section of the screen. You can have static text, a complete application, or anything in between, and your animation can interact with any part of the page, or weave in front of and behind the rest of the content, and you still haven't changed the size of the file script. The complexity of the actual animation and the size of any image files used in your animation will determine its memory usage, not the size onscreen. All the while, your text and links will be 100% indexable by the search engines because they're available in plain text for the spiders to read.

Killing the Proprietary Plug-In

Whenever someone comes along and tries to solve an old problem in a new way there's a certain amount of resistance to the idea, especially when people think the "new way" has been done before and failed. Early JavaScript animations quickly gave way to the domination of Flash in the browser space, but now it's time for JavaScript to make a comeback. The language has matured. The cross-browser compatibility issues have been hammered out, and the success of JavaScript and Ajax in Web-based applications of all types may have paved the way for newer, faster, and richer experiences that don't make demands on users regarding their choice of computing tools or physical abilities.

About the Author

Lisha Sterling is a partner at the Israeli Venture Technology firm She has been working in Web development and e-business consulting since 1994. She has a passion for usability and accessiblity in new technology and likes to read human factors research in her spare time.

Original: May 16, 2007

Digg This Add to