MikePadgett.com

Accessibility and web applications

— A vogueish tidal wave of asynchronous interaction could be a bit of a worry for web accessibility.”

What AJAX isn’t, in this context

Over the last couple of years, we’ve seen a significant leap forward in computing technologies and on one side of the coin, for the first time the Internet looks capable of delivering on the promise it showed a decade ago.

The flipside is that, during this time, the detritus of the computing has also increased exponentially, with over 95% of emails classified as junk [1] and ever more vocal reports of shady behaviour on the part of software vendors [2,3].

Enter AJAX

Riding the crest of this digital wave, the web technology “warp drive” that brought us Basecamp, del.icio.us and GoogleMaps – defined and described ad nauseam as “Web 2.0″[4] – represents both sides of the coin.

The positives are well-documented, the negatives less so. I decided to zoom in on one particular aspect: the conflict between AJAX [5] and Accessibility. This is not an especially new area of concern, but recently I wanted to check what progress there had been.

AJAX vs. Accessibility: why is there a conflict?

The key front-end advantage of the AJAX programming technique is that data can be served to the client without a page refresh. Small amounts of data are requested and managed by using a powerful scripting language. This language is JavaScript, and the AJAX technique finally shows how powerful it really is.

But therein lies the problem. Assistive technologies such as text-only browsers and screenreader software step over JavaScript altogether. As Joe Clark rightly points out [6], the WCAG 1.0 checkpoints include that:

“if you use applets and scripts: Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.” [7]

So how do we use a web application like Google Maps if our assistive technology steps over or mauls the very JavaScript that brings us the functionality needed to navigate the interface and serve maps dynamically? And just what would an alternative accessible page for a map of your hometown contain? Could it be something like David Hawgood’s map of Kent [8]?

Here’s another example: if we choose to validate a form with AJAX, so it’s possible to check for data entry errors in real time as the user fills out the form [9], then isn’t an assistive technology user at risk of entering invalid data?

One step forward, two steps back?

If, like me, you consult on web accessibility issues, then AJAX is a major concern: procurers see the power of an AJAX-ified application but none of the fallout.

People seemed to be all too willing to put aside the years of building awareness, interpreting and implementing standards and complying with the law just as soon as the jaw-dropping cleverness of this powerful (and discriminatory?) approach to web development became clear.

AJAX became a saleable “feature” of web applications, moulded into a point of difference that could be touted by salespeople who very likely had no idea what software had to do with the Achaean strongman.

The sad truth on this angle is that, as Clark succinctly points out, accessibility is also just a product feature.

For procurers whose personal experience of assistive technology amounts to little more than the wearing of spectacles, and whose personal knowledge of the law is as blurry as not wearing those spectacles, accessibility just ain’t sexy.

The response: silence!

One answer to all this might be: change the assistive technology software, not the development techniques. Another might be to simplify the complexity of the offering (often wrongly interpreted as “dumbing down”). In the best tradition of human interaction, the best response is probably to meet somewhere in the middle.

The product of research conducted by James Edwards et al on screenreader reactions to AJAX is predictable: the reactions are unpredictable. [10]

The key finding, for screenreaders at least, seems to be that the whole process of updating content inline, which is what AJAX facilitates, is not picked up at all. This acts out as “I select a button or a link and nothing happens“. Not good.

If AJAX is used almost totally to improve user interaction, Edwards makes a typically valid point: “[i]nteractions are just details, and perhaps what we’ve really been doing is projecting our own desires and preferences onto users for whom they’re not really relevant”.

Rolling with the punches

Imagine a boxing match attended by politicians. If you asked a cross-section of the attendees about the result of the bout, all that you’d learn is that the red corner and the blue corner both won.

Similarly, both of these are true: accessibility best practice is totally on the ropes and AJAX is seeing stars.

On the one hand, progress is both inevitable and inexorable, but on the other, we have come too far towards a best practice for accessibility to lose out now.

Seconds away, round two?