Clearleft’s Ajax training course
Last Friday I mosied down to the Big Smoke for clearleft’s Ajax one-day workshop presented by Jeremy Keith, and catch up with Molly, Lloyd and the rest.
It was their first training day, and was very smoothly organised; central venue, plenty of coffee, fresh fruit, good lunch – although they forgot the “Huggies” rule (H.G.I.S.: Hungry Geeks Inhale Sushi). Keith has all the essential qualities of a fine speaker; his timing was very good, he’s entertaining, discursive, passionate and knowledgeble about his subject matter. I’d certainly attend another Jeremy Keith extravaganza. (I have no connection with … blah blah disclaimer blah.)
Here are my main take-homes from the day. They’re geeky, so watch out …
You can’t just plug Ajax in as an afterthought
“You boy!” shouts The Head of Marketing, looking up from her champagne breakfast as eunuchs pour more asses’ milk into her bathtub. “Ajax is on all the competitors’ sites. It just sexes up what their site did before, so it’s no new development. Make our site Ajaxy. By tomorrow.”
Almost certainly can’t be done, unfortunately for you (but fortunately for us Web 1.0-loving luddites). I hadn’t thought about it before, but if you want to have some Ajax update just your contact us form, or just your shopping cart, you have to have a corresponding module on your server to call. So you must have a discrete lump of server-side code that spits out the html you want to update – no more, no less. This may not be a problem for modern, well-architected sites, but I can think of loads of sites I’ve worked on in which there’s no modularisation to speak of. To Ajaxify (Ajaxificate?) those, you’re looking at seriously re-plumbing the back-end. Tell that to the marketing manager in her bath.
Hijax: degradable Ajax
Ajax accessibility. Err. Umm…
So a functioning Ajax page would be very, very difficult to make accessible. How would you alert a user to the fact that content is updated? How would you navigate them to that new content?
I wondered, in the discussions we had at the end of the day, whether actually it was a long-term problem at all. My reasoning was that there are many screenreader vendors, all of whom attempt to corner market share by offering more and more features. It’s competitive. For example, when Flash 6 was released, with the potential to be authored accessibly, the Window Eyes 4.1 screenreader supported it at launch, while JAWS 4.5 raced to catch up (months later, if my memory serves). Similarly, Window-Eyes offers Firefox support, which JAWS has just added, along with new abilities to navigate the internal structure of PDFs.
So I speculated that, if enough high-profile sites were Ajax-driven, one of the screenreader manufacturers might build support for it as a unique selling point for their next release. But is it OK to publish pages that are currently inaccessible in the hope that the assistive technologies will catch up at some unknown point in the future?
Probably not, I think. But is it reasonable or even sensible to dismiss an emerging technology merely because assistive technology vendors don’t have tools to support it?
It strikes me, at any rate, the Ajax “rich experience” User Interface is here to stay; users have enjoyed sophisticated graphical interfaces for years – far longer than the Web has been a household word, and compared with the richness of desktop interfaces, the Web is clunky indeed.