Introduction
A while back I got into a forum discussion over the accessibility of CAPTCHA systems. That isn’t what this article is about (in fact it wasn’t what the thread was about either, but I soon changed that!). I only mention it because one comment in particular stood out as symptomatic of an attitude I come across time and time again:
“I am very much in favour of making the web more accessible to everyone, but …”
As I said in that thread, to be “very much in favour” is a cop-out if you’re not prepared to follow that through to its conclusion; it only pays lip-service to the idea of accessibility, without being prepared to do what it actually takes. I stewed on that thought for a few days, and eventually followed it up with a rant on my own site: Technology is the last, best hope for accessibility. In that post I railed against developers who can’t be bothered to care:
“Server-side programmers who hide on the server and deny that the client-side matters; client-side programmers so obsessed with the latest cool thing, that they’re quite happy to leave groups of people behind in the name of what’s cutting-edge and sexy.”
See, the web already was accessible to everyone. Tim Berners-Lee’s original vision for the web was all about universal access; and the technologies involved – such as HTTP and HTML – were designed to be platform and device agnostic; it shouldn’t matter what kind of technology you use to access the web.
But commercial interests got in the way, and the desire for branding overtook the need for open, standardised solutions; in effect, we tried to run before we could walk, because the huge commercial uptake of the internet far outstripped its early capabilities. And so we got things like browser wars, browser-specific DHTML, and table-based layouts. These were things that got in the way of the original vision, because people wanted rich content when the technology wasn’t ready. And now it’s happening again.
Of course to the majority of people this is all irrelevant – if it works, and it looks good, where’s the problem? Well the problem unfortunately is that there’s a victim, and the victim is accessibility. What I’m suggesting in this article is that it’s not acceptable to have a victim – especially when it’s a group of people who are already suffering disproportionately - and if what we’re doing creates that, then what we’re doing is wrong. I’ll look at the argument in detail, get to a conclusion, and along the way I’ll suggest how we can find non-Ajax solutions to a lot of the web functionality that Ajax is commonly used for.
“most” doesn’t need to be enough
Ajax is a sound and useful idea. But every idea comes down to a practical implementation - a technology that makes it happen - and in this case the technology is immature, because it leaves groups of users behind. Most notable and greatly affected are those using assistive technologies, but also those using less capable browsers that don’t support the necessary scripting objects, or don’t support scripting at all.
It might be reasonable to say that JavaScript support is not an accessibility issue, if it’s a user choice - if a person switches off JavaScript deliberately then shouldn’t they take responsibility for that choice? Well, yes, they should, but that’s not the real issue here; the real problem is more complicated, and isn’t a user choice.
Screen readers like JAWS, Window-Eyes and Hal are script-capable devices (since they sit on top of a script-capable browser, usually Internet Explorer), yet their ability to handle JavaScript applications is nothing like equivalent. We can’t rely on non-script fallbacks, nor on a scripted interface - these devices fall through the net of progressive enhancement.
Now that probably won’t come as a surprise. The fact that assistive technologies have problems dealing with asynchronous updates to the DOM is fairly well known by now (for a summary of the state of play, check out Improving accessibility for today’s Ajax at Access Matters; I’d also recommend a recent ALA article, Accessible Web 2.0 Applications with WAI-ARIA, which looks at one promising solution to this issue).
You could also say – and quite fairly – that this is the screenreaders’ problem, that the technology is broken and needs to be fixed. Yeah fine, but that really doesn’t help. The simple fact is that there are people using the web right now, using technology that’s increasingly failing to cope, and they don’t have the option of using something better, because there isn’t anything better.
(Let’s look at this using an analogy – suppose you could speak English and Spanish, and you’re talking to someone who only speaks English. Do you continue to speak to them in Spanish just because you think it sounds nicer? Do you complain that it’s their fault for failing to understand you?)
So let’s take the situation as read and move on to an interim conclusion: this problem has not been solved, and in my opinion, until such time as it is, Ajax techniques should not be considered suitable for widespread use.
It’s really not okay to leave groups of people behind, simply because they no longer fit your model of what a user is. Still, I appreciate that neither is it palatable to delay useful progress and development, if other groups of people can benefit from it.
But I don’t believe it’s necessary to do either - we can have our cake and eat it too, if we remember this simple observation:
New innovations often inspire us to do things that we don’t really need the new technology for, it’s simply that the change in approach and easy capability inspires new ideas.
In other words, the emergence of Ajax techniques has inspired a whole new wave of applications, but in many (if not most) cases, these applications don’t actually need Ajax to work - it’s simply that we hadn’t thought of them before. It’s easy to assume that the evolution of ideas follows an unbroken chain of cause and effect, but this isn’t really the case; evolution is as random as it is deterministic, and we can cherry-pick the best ideas – we can build Web 2.0 applications without using Ajax.
Web 2.0 != Ajax
One of the darlings of Web 2.0 is the photo-sharing site, Flickr. I really love Flickr, and am certainly not suggesting it’s a terrible web site, but Flickr uses Ajax gratuitously, and arguably unnecessarily. None of Flickr’s core functionality requires asynchronous updates to the page; all of it could be achieved in the “traditional” Web 1.0 way. If it were done like that it would be a whole lot more accessible and arguably a lot more usable.
To illustrate, here’s something I whipped up earlier. Thinking about how Flickr could be made without using any Ajax, I hit upon the idea of an editable page, similar to a wiki, on which everything that’s user-editable can be modified all at once. So it’s either read-only like a regular page, or it’s editable like a form. You can download the full example files here.
This distinction makes for better accessibility because the technology baseline is lower; and I also think it makes for better usability because there’s no mystery-meat to the interface anymore, no clicking things to see if it’s edit-in-place. You have output elements, and input elements, and never the twain need meet.
This demo is not perfect by any means (it’s missing a couple of features, and it could look prettier!), but it should serve to illustrate the point - we don’t actually need Ajax to provide an editable interface. The page is constructed as a single form, and all editable parameters are fields in that form (editable parameters are indicated with a yellow box). The whole thing makes a POST request when submitted (rather than using GET data, which is inappropriate for some kinds of action); and of course, it all works without JavaScript.
It’s also semantic XHTML throughout, with no tables for layout!
Now to me, that’s far more useable than the original interface, because it’s obvious what everything is - there are no form actions disguised as links, or links disguised as buttons - it does what it says on the tin. But I know that the usability thing is debatable - you might look at that and think it’s far less useable than the slick, micro-update, edit-in-place format of the current site. Usability is, after all, one of the main touted benefits of Ajax, and if we can design interfaces that are more self-contained and versatile, then isn’t that a good thing? (Would Flickr even be Flickr - would it have been so successful at all - without that “progressive” user experience?)
But posting forms and page refreshes are norms of current web behaviour. They’re part of a set of expectations that all Internet users share by now - everybody knows how that works. Is it really a good thing to ride roughshod through these expectations so soon, simply because we think it’s better another way? (What is that “yellow fade” thing all about, other than re-creating status functionality that the browser already had?)
Striving for better things is not good enough, if in the process we lose some of our users completely. I think of progressive enhancement like a hierarchy of objectives: where accessibility is the highest, most important thing, followed by usability, followed by aesthetics. Ideally we want all three, but if achieving one of the lower levels means sacrificing one of the higher ones, then it’s simply not justifiable, in my mind.
Good usability or not, the pure accessibility issue is pretty much undeniable, I think. All browsers and all assistive technologies know how to deal with forms. You don’t need JavaScript, or a mouse, or stylesheets, or even color to make that work!
“And the men and women … well, the men … who went to the moon - they did it with no mouse, and a black-and-white text-only screen, and 32 kilobytes of RAM!”
But Ajax allows for applications that are otherwise impossible…
How could Google maps possibly work without asynchronous updates? And what about Meebo, the online messaging service, which similarly couldn’t be done without Ajax (or an excessive and highly unfriendly stream of constant page refreshes!)?
Meebo and Google Maps need Ajax to work, and so I have no real criticism of them, and accept that the pure accessibility issues are (as far as I can think) unsolvable for now. I’m not a puritan, and if it comes down to a division between, “do X for the majority”, or, “don’t do X at all for anyone”, I’ll usually side with the former.
Twitter I’m not so sure about - it could be done without Ajax, because its periodic updates are relatively infrequent. Twitter could work by refreshing the whole page, or an iframe containing just the message list, say, every minute or two; but automatic page refreshes have their own accessibility issue quite apart from this (because most user-agents don’t allow control over page refreshes, and to reload a page without user intervention is equally rude and intrusive). So again, if Ajax is what it takes, and it’s that or nothing at all, then you won’t hear me complaining too loudly about gratuity or lack of forethought.
Indeed, a client of mine has a successful web-development division that recently did some work that could only have been done with Ajax. They were asked to make improvements to the usability of a legacy system, their client having already been told by other developers that such improvements were impossible, since the system was so entrenched and nightmarish to edit. But Ajax allowed improvements to be made by injecting new UI components directly into the interface, without having to touch the back-end at all! And that’s great - and their client was very pleased!
But all of these examples are really edge cases - circumstances that seldom apply. Most of us, most of the time, are working on applications that don’t really need Ajax, and which don’t significantly benefit from using it. So much Ajax is pointless, used purely for its own sake, or for the sake of being trendy.
I recently went to see a company who were developing a complex, entirely Ajax-driven application; to me Ajax really didn’t seem necessary for what they were trying to build. I wanted to give them a fair go, but I was pretty sure in advance that I was going to hit a brick wall when it came to accessibility. And I did. And their arguments were reasonable in purely financial terms - if we can achieve 90% penetration using this technology, why should we care about that other 10%?
But what if everyone thought like that? What would happen to that 10% who suddenly found the web to be a place in which they’re no longer welcome? Who found that technology - the ultimate enabler - had become just another barrier?
It’s happening right now, and it’s really not okay. This headlong rush toward Rich Internet Applications is happening without due care and attention.
To boldly stay
In 2293, in his opening speech to the peace conference at Camp Khitomer, the Federation president spoke these insightful words:
“Let us redefine progress, to mean that just because we can do a thing, it does not necessarily follow that we must do that thing.”
Jesse James-Garrett may have started a revolution, but I’m sure that was not his intention. He had the freedom to use a technique in which accessibility didn’t matter, and universality was not an issue. But most of the time, for most of what we do, we don’t have that kind of luxury; so let’s not be so quick to abandon what works.
Stop being so infatuated, and take time to do things properly.
And anyway … the really good ideas in this evolution of the web are conceptual, not technological - social networking, tagging / folksonomy, user-generated content - and we don’t need Ajax to make any of that work.
So to re-iterate
In summary, these are my points:
1. I’m not saying Ajax is bad, I’m saying it’s immature
2. I’m not saying never use Ajax, I’m saying don’t use it for the sake of it, and try to avoid it for now, instead sticking to accessible alternatives
When Ajax comes of age I’ll be cheering as loudly as anyone. And I’ll be working towards that goal and looking for solutions myself. But until that day comes, I intend to stick to proven, standards-based and accessible tools - not sketchy, proprietary and inaccessible toys.
