Accessibility issues with Ajax

The word Ajax has been buzzing around the web industry for the last couple of months like somebody suddenly discovered fire.

The term was coined by Jesse James Garrett at Adaptive Path in February 2005 and is usually explained as Asynchronous JavaScript and XML. Personally, I prefer the less elegant but considerably more honest description: asynchronous JavaScript using XMLHttpRequest with CSS and the DOM. Not quite as catchy. Marketing departments everywhere can relax.

The interesting thing about Ajax is that very little of it is actually new. It’s essentially a collection of technologies web developers have had lying around in the toolbox for years, suddenly assembled into something useful enough to deserve a fashionable new name.

XMLHttpRequest itself has been around since 1998, originally introduced as an ActiveX control in Internet Explorer 5.0 and developed for the web-based version of Outlook, allowing pages to send XML via the HTTP protocol. Ancient history by Internet standards. So why all the excitement now?

Ajax – the universal solution.

Because developers have finally started using these old ingredients to build genuinely interesting web applications with richer, more responsive interfaces. Google Maps and Gmail have shown what happens when the browser stops behaving like a glorified document viewer and starts behaving more like an application.

Naturally, there’s a catch. There’s always a catch. Ajax applications rely heavily on JavaScript running in the browser, and once you start changing pages behind the browser’s back, some of its oldest and most familiar conventions begin to fall apart.

Take the Back button. People use it constantly. They trust it. They understand it. It is one of the few pieces of browser interface that even your mother probably knows how to operate. And Ajax can cheerfully break it.

Then there’s the familiar indication that something is happening. With a traditional page request, the browser gives the user some feedback while it loads. Ajax does its work quietly in the background, which sounds wonderfully sophisticated until somebody clicks a button and nothing appears to happen. Congratulations. You’ve created suspense. It’s now your responsibility to tell the user that the application is actually doing something and hasn’t simply died.

Browser compatibility is another small banquet of misery. Your JavaScript needs to survive different engines, different implementations and different interpretations of what everybody supposedly agreed the standards meant. More logic moves onto the client, which also means asking more from the machine sitting on the other side of the screen. machine specifications.

And then there are the users without JavaScript. Estimates suggest they represent roughly ten percent of web users. Whether they disabled it deliberately, are using a browser that doesn’t support what you’re doing, or are trapped behind some corporate configuration assembled during the Cold War doesn’t really matter. Your magnificent Ajax application doesn’t work for them.

None of this means Ajax is bad. Quite the opposite. I think it’s an extremely useful technique, and we’re going to see much more of it. But Ajax should be an enhancement, not a hostage situation.

Build something that works first. Then make it faster, smoother and sexier with JavaScript. Understand the difference between graceful degradation and progressive enhancement, and don’t assume that because something looks impressive in your browser, everybody else is enjoying the same experience.

Ajax has enormous potential. Just remember that every shiny new technology eventually has to meet an actual user. That’s usually where the trouble starts.