A lot has already been written by various influential authors in the field of web development when it comes to the importance of accessibility and degradability in the age of Web 2.0 and AJAX. After reading this entry on Roger Johansson's weblog and joining the discussion that followed I figured it would be nice to jot down my personal thoughts on these matters in a posting on my own blog.

I consider myself to be a modern, standards aware web developer who loves clean code and cross-browser web development like any other serious web developer. However, I feel that the accessibility card is sometimes played too often, and too heavily. So, Should a website / web application be 100% accessible and 100% functional without Javascript being enabled? My answer would be: "It depends.".

Living in a Web 2.0 world

A lot of websites use AJAX, AHAH, AXAH or whatever other buzzy term people invented for the same thing: dynamic updating of page content with the help of the now standardized XmlHttpRequest object (XHR). In order to make use of XHR, one thing is a necessity: Javascript needs to be enabled on the client's browser. If we depend on XHR this implicates the website / application will not function without Javascript being enabled. Oh! The horror!

AJAX is often used by people simply because they can, or because they think it's cool. While I agree it has it's 'cool factor', this should of course never be the main reason to use it. A great example of AJAX being used in a totally brain dead way is this website. Every click on the entire site results in an XHR being fired up to update a large proportion of the page. I'm sure everyone will agree on the fact that the use of XHR doesn't add anything to the user experience on this particular site. It's clearly been used 'just for the heck of it' ignoring all of it's disadvantages when it comes to SEO or bookmarking of particular pages on the website.

Let's also look at Digg. On this particular site, visitors can 'digg' a posted article with a single mouseclick. A little AJAX thingy fires up and updates the counter next to the posted article. A whole page reload saved! In this example it makes perfect sense to also provide a non-JS fallback. It's easy to implement, the user experience is basically the same and the only expense is an extra page being loaded. It would be flat out stupid to miss this opportunity. Nevertheless, they DIDN'T! (I'm still in shock here). The source is full of onclick="some code" and inline Javascript. Nothing works without Javscript enabled while in Digg's case it would definitely not be all that hard to make this happen. A big screwup if you ask me! Shame on whoever developed it.

On unobtrusive Javascript

Quite often people seem to bring the need for unobtrusive Javascript into the discussion arena when it comes to the matters at hand. I feel this has little or nothing to do with it. Modern web developers agree that markup should be separated from design. We can accomplish this by strictly using CSS for any design related features of a website. This leaves us with clean (hopefully) semantic (X)HTML code which is easy to both create and maintain. Most of us (not all of us unfortunately) have taken this an extra step further by also strictly separating the behavioral layer from the markup. This means we don't want to use onwhatever="some js code" or loose javascript fragments anywhere inside the document but attach all our behavioral code after the document has finished loading. We also want to place all our javascript code in separate files. Again: cleaner code and enhanced maintainability. It will also enable us to create fallbacks for non-JS enabled browsers. Sometimes, that is. The bottom line: unobtrusive Javascript is a must. However, it has absolutely nothing to do with the debate on whether to use Javascript at all or whether it's a necessity to provide a non-JS fallback at all times.

Enhanced usability

AJAX is often used to seriously enhance the user experience and to accomplish things that simply don't translate very well to a non Javascript-enabled scenario. A great example is the project I've been working on for the past couple of months. For various admin screens which will be used by customers of the service we created fully functional AJAX list widgets. They can be used to browse, search and filter large lists generated from a database. We're also using AJAX to submit partial form components and to quickly lookup information needed to accomplish the main task related to the specific screen at hand. Alltogether our practices save the user a gazillion of page reloads and the need of popup screens to access certain information without leaving the main screen. The final result? Customers get their stuff done in an enormously reduced amount of time.

So here comes the question: Should we make sure all of this works without Javascript? We think not. And so we should be put against the wall in order to be shot, according to some. We beg to differ. Providing a non JS version of the application would result in a slow, tedious and time consuming version of the application that everybody would just hate to use. In just three minutes everyone would beg for the JS enabled version because things would just work so much smoother. The amount of extra development time involved would also be rather significant because we'd need to toss a gazillion of extra parameters back and forth between every request in order to keep track of what the user is doing. I could go on about it for a while but I hope I've illustrated the fact that a non-JS version of this application wouldn't really cut the cake. It just wouldn't be worth the effort nor the pain of having to use it given the fact that we know that only a tiny percentage (if any at all) of the future customers would ever require it. So here's a clear cut example of a well thought out decision to NOT provide a non-JS version of the application. This paragraph could be compacted into one meaningful sentence: We didn't bother with a non JS version because we value usability over accessibility. In THIS particular case, mind you!

Accessible? or Usable?

As I mentioned in the beginning of this article when trying to answer the question whether a website should be 100% accessible: It depends. It depends on the target audience for the project and the goal you're trying to achieve with it. This means that I strongly believe that government information sites should be 100% accessible. Even with Lynx. No discussion about it. Accessibility of the information is king on this kind of site. If you care about SEO you should make sure all important information should be accessible to search bots. This means you shouldn't load any content you want to have indexed with an XHR. It will ruin your search rankings for sure. Sometimes however these things just don't matter. I've already given the example of a web application behind passworded user accounts. Another great example would be an AJAX powered chat environment. Chatting by reloading the whole page every time you want to check for updates just sucks. I know so because I built such an application: a chat site for mobile phones that don't have any javascript, java or flash available. Using it is a huge pain in the ass and the only reason people ARE using it is the fact that there's absolutely no other way to chat on a primitive GPRS enabled mobile phone. In a browser environment however, people would hate it. XHR and Javascript enable developers to create a chat environment that closely resembles a stand alone application with (almost) instant messaging, instant feedback and fast response times. When building such an application I strongly feel it's perfectly acceptable to let go of some of the holy accessibility issues. Again, usability wins over accessibility. At least it does for this particular developer.

So... what's the verdict?

My position on the issues discussed in this article boils down to the following:

• Use unobtrusive Javascript! Everywhere! Always! This has NOTHING to do with whether a site should work without Javascript or not. It's simply the proper way of doing it. Separate code from your markup just like you're separating layout from it.
• Don't use AJAX just because you can. This may be fine on a personal site but... don't do it on a professional client project. If it enhances usability however, make good use of it.
• If it's a key requirement that every single soul needs to be able to access all information on your site, be very careful with using Javascript. Make sure EVERYTHING works without it.
• Whenever it's easy to provide non-Javascript functionality without resulting in a ruined user experience, do it! Shame on Digg!
• Whenever your project is really much more like a true application and SEO or bookmarking aren't a big deal (the chat example), go ahead and have it require Javascript. I strongly believe it's better to throw in a friendly message mentioning the fact that Javascript is required than to deliver a totally crappy user experience. Usability is everything. It will make your customer either love your site and stay or run away to your competitor.

So here's my original point: It all depends. There's no black or white as some try to suggest. There's just a whole spectrum of greys really.

So, what do you think?