Ajax, Hijax and accessibility
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
The main aim of Keith’s Hijax methodology is a model of Web Standards “Progressive Enhancement” lovliness, which ensures the degradability of the web page/ web app (call it what you will). It is basically the principle of unobtrusive JavaScript applied to Ajax. By building your pages correctly (that is, adding the Ajax to a traditional, usable, working, page), you’ll ensure that they work for people who don’t have JavaScript on their browsers (or ActiveX on their IE6 desktop etc.)
Hurrah! the proponents of universal access shout. Yippee! some Accessibility types will shout, because if it works without JavaScript, it’s accessible too, right?
Wrong.
Ajax accessibility. Err. Umm…
If screenreaders didn’t support any JavaScript, then they’d get the working, traditional page that gets hijaxed by JavaScript, and all would be well. We could ask all screenreader users to turn off JavaScript, as Derek Featherstone suggests, but it ain’t gonna happen. (Have you ever tried to turn off JavaScript in IE? It’s buried way down in the menus, and it’s unreasonable to ask people to do that for just your site, when the reason that the screenreaders have some scripting capability is because 90% of the Web would be useless without it.)
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?
An alternative method of “Ajax” exists (if we ignore the overly-precise acronym “Asynchronous JavaScript and XML”). Keith’s definition of Ajax (“The ability to update part of a page instead of the whole page”) is equally applicable to Flash, which can be accessible to Windows machines via MSAA. I’m no Flash expert, but Bob Regan tells me that Flash can discover whether there’s assistive technology (AT) looking at it, and presumably therefore offer a more AT-friendly way of alerting a user of content updates, while keeping the slick experience if there’s no AT on board.
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.
Any thoughts?
(Last Updated on )
Buy "Calling For The Moon", my debut album of songs I wrote while living in Thailand, India, Turkey. (Only £2, on Bandcamp.)
8 Responses to “ Ajax, Hijax and accessibility ”
To clarify my point it is okay to use CSS that IE6 doesn’t support but we must provide alternatives, right?
IMHO the question is not whether we should (or not) use technologies not implemented in AT (assistive technologies). The real point is if technologies are not standardized (eg W3C stampped), there is:
1) no serious way for AT vendors to implement them.
2) not much hope that accessibility be really, sufficiently considered by technology creator.
True, but remember that the problem lies with generated content in general, not Ajax in particular. The crux of the matter is having screenreaders recognise that a portion of the currently loaded page has been updated – whether that update came from the server or not is academic. So the problem does lie with standards: using the DOM in combination with ECMAScript to update a page written in (X)HTML after the page has finished loading. Throwing XMLHttpRequest into the mix does add a proprietary technology but, in this case, it’s a red herring. The real issue lies with how screenreaders cope with technologies that do have the standards stamp of approval.
Thanks very much for the kind words about the workshop, Bruce. You neglected to mention what a great audience I had. In particular, there were some terrific questions asked. My personal favourite was when you asked a question about some code I had up on-screen and the answer to your question was revealed in the very. next. slide. Such timing! I love it when a workshop comes together.
I agree that Ajax is here to stay. Hijax is the next step.
By Hijax I also refer to the mechanism of indirect Ajax, where the web 1.0 post back is suppressed and replaced (the post back is hijacked) with an out of band call (XmlHttp) to the server.
A web server and screen reader can transfer pages using different compression methods, so of course you can develop a screen reader that supports Hijax internally. Infact if you look at one of the latest Hijax frameworks you’ll notice that direct Ajax programming is moving away from DOM manipulations and over to business logic, and Hijax is taking over the DOM-manipulations.
But why not let the browser handle the Hijaxing internally? That is what happens in the Windows Application framework, the window manager takes care of the screen updates. Hijax is the window manager for web forms… So, screenreader developers out there: Look closely at the Hijax frameworks out there and draw up som standards, so that a Hijax-enabled web server can send only modified bits to a Hijax-enabled screen reader.
In that way we will be able to have nice responsive applications on the web and browsers that are Hijax-enabled will be able to access these applications without having to download a Hijax framework together with the content.
[…] Ajax, Hijax and accessibility […]
“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?”
No. I mean, is it okay to use CSS that IE6 doesn’t yet support in the hope that it will catch up at some unknown point in the future? No it is not, same goes I reckon.