Talking Point: Should we stop using ajax?
April 27, 2008 at 12:53 AM
Add to Delicious or Add to My Yahoo!
James ‘Brothercake’ Edwards opened up a controversial can of geekiness with his recent Dev.Opera post, Stop using Ajax!. Brothercake argues that we are far more inclined to chase the latest-greatest technology than truly commit to accessibility, and Ajax methodologies are a prime offender. Using not-very-accessible technologies because they’re cool is at odds with the implicit humanistic idea underlying web standards—universal access. His point speaks to the very heart of the standards movement, and how widely we see that challenge. So, what do you think about ajax use v. accessibility? Or, even wider, what do you think about universal access v. technology trendiness? Should there be ebb-and-flow between the two?
Comments
It’s all about the target audience.
Brothercake makes a great point. Designers and developers often do not consider accessibility when building new web applications or sites. There are a large handful of users left in the dust when it comes to AJAX and layouts using table upon table. Many people often use the excuse “we don’t have many people in our user group that need accessibility”, even though you cannot always tell when someone has a disability. If the physical world were based upon these principles, we might as well go back to ancient days and toss the babies with defects over the cliff.
At the same time, he makes too many flawed points to take his advice to heart. “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…” The idea of a majority of AJAX applications is to bring desktop applications to the web (or at least create a new application that mimics the functionality of a typical desktop application). Every person that uses the web has already used a desktop application. Everyone knows how they work as well. So why not bring that quick-response desktop application to the web? Additionally, his point about “re-creating status functionality that the browser already had” is very weak considering the status functionality in almost every browser is horrendous (a progress bar for page loading?)
He goes on to say that “So much Ajax is pointless, used purely for its own sake, or for the sake of being trendy.” At first glance, I can’t help but agree. I have been guilty of this offense, just like many others. Yet to throw the whole lot of AJAX enhancements out the door is not a good solution. One of the main attractions of AJAX is the speed. Browsers take forever to render a page, and that is not even considering the time it takes to transfer all the unchanged content (yes we have high-speed connections and quad-core machines, but all of those little things add up).
The worst part of his article is when he says, “We can’t rely on non-script fallbacks…” Why not? He gives no good reason for this. How is anyone to know whether there is a scripted version of their content if they see an accessible one on their screen? More importantly, why would that matter if they know there is a scripted version if they can navigate a site or application without a problem? Let’s go to the physical world of accessibility. A person in a wheelchair sees that there are regular stairs into a building, but they could care less as long as there is a ramp they can make their way up. When it comes to accessibility in the physical world, it often adds additional time and cost to a project. Why should we balk at this on the internet? Yes, there are plenty of circumstances where accessibility can be built into a feature without having to make a separate additional effort; we should take advantage of this often. Let’s keep the progress and the speed of AJAX, but put in the time and effort to making websites with parallel accessible content and applications.
As Brothercake shows in his Flickr alternative, the layout doesn’t need to be drastically altered to be accessible. The same server-side AJAX processing code can be altered to take accessible POST requests. It definitely is more work, but it can be made into a simple workflow: build an AJAX site or application, and then add the accessibility layer on top of that. Any adept developer can create a simple script generated cookie (or GET variable) to keep the user in the AJAX content. Then all that is needed is some simple server-side logic to decide which type of page should be output. This kind of work has already been done for multi-lingual sites; why not treat accessibility as just another language? Screen readers are happy, fast paced, impatient techies aren’t slowed down, everyone wins!
The worst part of his article is when he says, “We can’t rely on non-script fallbacks…” Why not? He gives no good reason for this.
If you had read the article he links to, you would know that screenreaders interpret JavaScript, so they will not get any <noscript> content (or overwritten content) – but they also have a problem with Ajax updating parts of the page.
April 26, 2008 at /files/includes/10.css:22 AM
Not using AJAX is the wrong message. Using AJAX that is still accessible is a much better way to approach the problem. For example, when and if possible, make AJAX enabled user interfaces degrade gracefully when JavaScript is turned off. The problem is that most users for most websites can access most AJAX interfaces just fine. It cost more to write something that degrades well, and if it only affects 1% of your user base – similar to designing for 800×600 – it’s often times not worth the effort.
While the idea that AJAX helps create more desktop like applications on the web is true enough. The main reason AJAX is so popular is because it tries to addresses the fundamental failing of the http protocol, more spefically the aging request / response paradigm.
By now the web should be utilising a stateful protocol stack that provides for more sophisticated messaging and lower level browser integration.
If you had read the article he links to, you would know that screenreaders interpret JavaScript, so they will not get any <noscript> content (or overwritten content) – but they also have a problem with Ajax updating parts of the page.
I did read the corresponding articles. It’s not about using <noscript> (if he had only mentioned <noscript> then I would have been in agreement). That is a weak implementation at best. The idea I am prescribing is a dual path site/application. Your content should be separated from the coding, and then you just use scripting to add a cookie or GET variable that your server will use to decide which type of interface to send.
Brothercake is a provocateur. The absolutely binary admonition, “Stop using AJAX” is great for attracting our attention. Good job James!
There were times a couple of years ago, when in my job as an accessibility consultant I might have said exactly the same thing.
Today, I disagree … at least with the absoluteness of the command. Note well that I consider James a colleague and friend due to a number of collaborations we have had. Yet, I can’t agree that stopping the use of AJAX is either a correct or feasible answer. We can ask, but we won’t be any more effective than wishing web developers would quit using tables for layout. It’s just not going to happen. Those who want to use AJAX techniques will use them regardless of their accessibility characteristics, and then justify it with some imagined “target audience.”
Let’s face it folks: EVERY audience includes people with disabilities, and we should plan for them to be included.
On one hand, there are far fewer problems with using well thought out AJAX techniques than there were when it first appeared. That’s due to two things. First, all of the screen reader producers are quickly adding features to their products to make AJAX more easily handled. Second, coding techniques such as ARIA add new accessibility capabilities to our browsers and to the accessibility tools as well. Neither is a perfect answer yet, but progress plods on.
It’s always been this way. Someone innovates and creates a new technique. We say “Whoa, our screen readers can’t handle that.” Some time later, often not very long, the screen readers catch up.
What I think James really wants, at least what I want, is for more developers to be aware of accessibility implications and to understand what they’re doing. However, if he had titled his piece “Know what you’re doing,” we probably wouldn’t be discussing it would we?
I completely disgree. For one, AJAX might not equal Web 2.0, but it doesn’t equal inaccessibility either. And though I have little argument against his reasons to think it, i do not believe that’s the obviouse conclusions.
Lets not forget ajax can seriously improve the user experience. It allows the programmer to anticipate a user’s need for information, rather then wait for the user to figure out he did something wrong and might need some help. Sure people use AJAX for the sake of having something different… I don’t see a call for banishing a technology based on a few people not knowing how to apply it as the way out. It needs to mature, best practice needs to arrise, it needs better intergration with the backend. There need to be solutions for when ajax or javascript fails so the user isn’t left with a disfunctional site. But none of these things are impossible. Giving up AJAX at this stage is like giving up HTML back in the days of tables. It’s a premature conclusions.
But, in all fairness, maybe someone screaming that AJAX shouldn’t be used is just the thing we need to get some extra discussions going on how to address these issues.
Solving the problem cannot mean, to avoid a technology because of some reason. It should mean, to get another technology to make Ajax more accessible. That would be the more optimistic approach.
On the other hand we have to point out, that there will be no technology at all in the future, that serves all humans. You can’t make a microsope accessible – and you would never forbid microscopes because they don’t fit to accessability, would you?
I recall when the argument was “let’s use Flash on all aspects we possibly can,” which lead to huge Flash-based menuing systems and the obliteration of the browser’s built in back-button. And the cries went to the sky, for even the average browser, with no blindness, was annoyed. It’s not just annoying to users with disabilities, people.
Most of the Ajax implementations in the web today are doing the same thing. I’m with brothercake on this one.
Furthering the discussion a bit, jQuery’s John Resig responded with some notes about Ajax Accessibility and ARIA live regions. I’d tell you more about it, but I’m just wrapping my head around it now. For those of us looking to learn more on current solutions, I’m sure John’s perspective is a good place to start.