Article
Accessible Flash Parts 1 And 2
Beware Cloaking
Cloaking, as defined by search engines, occurs when a method such as this is used to supply a bot with content that does not match the actual content in the Website.
From the Google Webmaster's FAQ:
"The term "cloaking" is used to describe a Website that returns altered Webpages to search engines crawling the site. In other words, the Webserver is programmed to return different content to Google than it returns to regular users, usually in an attempt to distort search engine rankings. This can mislead users about what they'll find when they click on a search result. To preserve the accuracy and quality of our search results, Google may permanently ban from our index any sites or site authors that engage in cloaking to distort their search rankings."
Altavista has a statement, too, although it's less clear in its definition of cloaking.
As can be seen, search engines frown upon cloaking and some actually ban Websites that use these techniques to gain a better search ranking. As such, I would strongly advise against supplying content that does not match what your human visitors see -- it's not worth getting banned from engines like Google that, apart from being one of the biggest search engines, also supplies search content to many other engines.
And anyway, you want your visitors to be met by the content they were searching for, right?
Future Directions
An interesting feature of Flash Player 6, and one that will hopefully be made more stable, is the Named Anchor. Named Anchors allow different frames and scenes in a movie to be targeted from a URL, without reloading the entire movie. The benefit of this capability is that, as each named keyframe is targeted, the URL changes to reflect its unique id.
This will allow visitors to capture the URL that relates to the content they're currently viewing, by hitting the bookmark keystrokes. It will also permit users to navigate the site using a browser's back and forward buttons.
Named Anchors are, at the present time, manually set on the timeline, which makes an ActionScript-based Flash site controlled from the URL pretty difficult to implement. This is something worth experimenting on, though, to better define its current capabilities and limits.
Conclusion
The code and its implementation discussed here are a step towards more accessible Flash content. This information can be used as a basis on which to build Flash Websites that are fully indexed by search engines, enhancing both Website traffic, and the awareness of Flash as a viable development tool.
As examined in this case study, flow on effects include:
- Bookmarking for direct return to content within the Flash Website
- Scalability and stability to handle content as it is added to the Website, and
- Client confidence that a Flash Website can be indexed without major development and cost overheads.
You, the reader, are more than welcome to add and subtract from this process and implementation. Bringing about improvements on the original scheme, and making it more stable, can only assist developers and designers in the promotion of their Flash work.
Use it, build on it, make it better!
Further Resources
Robert Penner's back/forward button implementation using a frameset:
http://www.robertpenner.com/experiments/backbutton/backbutton.html
Jakob Nielsen's classic Flash diatribe from 2000. Unfortunately, this is what remains in the collective consciousness whenever Flash and accessibility are mentioned together. As the URL states 'use it' to provide another point of view:
http://www.useit.com/alertbox/20001029.html
Flazoom.com Flash usability white paper:
http://www.flazoom.com/usability/usability_toc.shtml
Flash -- 99% Good -- A first aid manual for Flash Websites
http://www.flash99good.com/index_flash.html