With all the fuss over AJAX and Flash accessibility you get, I thought it might be worth outlining the process we use and highlight one of the advantages you get with it. (Hint, it’s in the title.) It also means that the use of Flash has no impact on your Search Engine Optimisation.
Oh, and although I’m writing this article, much of the implementation (and Flash expertise) is from my colleague and co-author Tom Hooper. Any Flash questions will be directed his way!
Recently we re-launched our CMS’s site, defacto-cms.com, and with it a flashy (in both senses) case study selector. If this were a clients site it probably wouldn’t be worth the time for this purpose, but now the framework is in place it will be easy to replicate.
The ‘carousel’ navigation widget is only used in the case-studies section at the moment, and it is essentially local navigation for that section. You select a case study, it spins into the center, and if you select it the content below is replaced by that case study’s information. The visual effect is not 100 miles away from the iTunes ‘coverflow’ effect, although there are some subtle differences. It uses the Papervision3D open source ActionScript 3 engine for the 3D effect, plus a fair bit of scripting!
NB: Don’t use this in Safari yet! There’s a crash-bug we’ve discovered in Safari affecting the AJAX. You can load and play, but don’t select a case study with the Flash.
It is worth noting that we needed to use quite a recent version of Flash to get that effect (V9.0.28+).
I don’t think there is much new in terms of techniques, although I haven’t seen people use the content of a page as source for the Flash in this way before. It has also had quite a lot of attention in terms of bullet proofing and making accessible.
The foundation is straight XHTML 1.0, and on a basic browser you get a list of links with images.
The HTML needed to run it is a container
div, its content (used in the Flash), and an object which is used to configure the Flash element on the page. This is a very generic method that we will be using for any Flash content, but as an example, for carousel that skeleton is:
<div class="flash-object" id="landing-proposition-inner"> <h2>Websites powered by Defacto include...</h2> <ul> <li><a href="page1.html"> <img alt="Organisation website screenshot" src="shot1.gif" />Organisation Name</a> </li> <!-- more items --> </ul> <object> <param value="/defacto/live/swf/carousel.swf" name="swfLocation" /> <param value="200" name="height" /> <param value="#0E3E80" name="bgColour" /> <param value="url" name="sendMode" /> <param value="9" name="reqMajorVer" /> <param value="0" name="reqMinorVer" /> <param value="28" name="reqRevision" /> </object> </div>
What the scripts do
- Runs, if you have a fairly recent browser (we used jQuery, so it matches Yahoo!’s graded browser support table fairly closely).
- Checks the version of Flash that you have, and either:
- Replaces the content of the container
divwith the Flash, or
- Adds a small “Would you like to upgrade your Flash” link.
- Replaces the content of the container
- If the Flash is added, the current URL and container ID is passed to the Flash.
If I were you, there would be several questions going through my mind:
Question: Why use AJAX?
It prevents you having to re-load the Flash each time you view a case study. Even cached, it’s doesn’t load instantly, and this way you don’t have to sit through the initial animation again and again
We tried that, but it seemed very CPU intensive, and given that the nature of the widget is already CPU intensive, we steered away from that. Although it may mean loading the thumbnails twice, they should be cached for the second load. In our initial testing, the caching/loading differed between browsers:
- Firefox loaded the page fully before the Flash, which is strange, so Flash gets the cached images.
- IE seems to load the Flash and page simultaneously, so the first request for the images is usually from Flash.
Technically as the images are removed from the page when the DOM is ready, they shouldn’t all load, but I can’t confirm this yet.
Question: Why not do the Flash version detection in the Flash?
Progressive layering / enhancement
The easiest way to describe the layering is to describe the progressive enhancement, i.e. what you get with what capabilities the browser has:
- An HTML list (
ul) of standard links that work and image thumbnails.
- An HTML list of links that work. (Images are hidden with CSS, as they are too big when you have the layout in place.)
- An HTML list of links, and a little link at the bottom of the area suggesting you update Flash.
- The Flash carousel version, using AJAX to load the content.
There are several advantages to this whole method that appealed to us:
- The method scales up. The first time we tested this was for a micro-site that replaced the whole site with Flash.
- Search Engine Optimisation (SEO). Since your content is well structured XHTML, Google doesn’t even know you’re using Flash.
- The presentation in Flash can be very different from HTML, even with the same source content. (Caveat: the more Flash elements you layer on top of the source content, the less flexible the content becomes.)
- You can have multiple Flash instances on the same page, each with it’s own variables.
- It is easy to turn on/off, bulletproofing the accessibility.
- No duplication of content, you don’t have to update two things.
- You can edit the content within any XHTML capable CMS.
I’ll repeat that for those at the back: You can edit the content in a CMS, not one coded specifically for editing Flash or custom XML files.
Obviously, you can’t add or change functionality, but in this case you can add case studies (links and their thumbnails), and in other cases you could change the content of pages (i.e. text and images).
We are tripping several alarm bells in terms of accessibility by using Flash and AJAX, but actually it wasn’t that hard.
The pages work fine without JavaScipt. The AJAX loads on a keypress of enter, so screen readers will generally update the virtual buffer. There could be a problem if the content takes a little while to load, but adding Juicy studio’s update buffer function should resolve that.
For the the Flash you just have to put in the work (and knowledge and testing) to ensure that it works with both visual keyboard access and with screen readers. You also have to work out what should be shown to screen readers in what order for it to make sense. We did find a bizarre bug in JAWs (8.0 original version) where the whole pages content was repeated when it entered the Flash, but applying the later patches to JAWs fixed that.
One of the basic assumptions we accepted is that people may not be able to, or want to, use this feature. Therefore we added a “Disable scripts” option at the top. This essentially turns off the advanced scripted features such as the flash, but leaves the cosmetic ones in place (e.g. adding rounded corners).
Usurping the innate page model of the web comes at a cost, some of which we’ve worked around. If you just use the Flash, it’s fine, but if you switch between navigation methods it’s a little clunky as the Flash is not reloaded.
The aspects we did work around were primarily changing the page title when you load a new case study, and providing a mechanism to get back to the index page (in the breadcrumbs).
We also made the visual aspect somewhat more HTML-like, so that a case study has underlined text “View case study”, then when you select it that disappears. Adding this made the keyboard/screen reader aspects easier to deal with as well.
Improvements still to make
Although we’ve restored the titles to individual (AJAX) pages, we haven’t re-enabled bookmarking of individual pages. Although search engines will have no trouble finding the pages, people will have difficulty bookmarking individual case studies.
I’m also not convinced that the double click aspect (i.e. one to move the case study to the center, a second to select it) is the way to go. Some people expect the first click to select a new page, some don’t.
Which did you expect?