For those developers who are lucky enough to develop applications for modern browsers and damn IE 5 and those who choose to turn off JavaScript, I have one message: I hate you. At this stage, many Ajax projects are about adding little bits of usability to an existing applications — an in-place edit here, a search term suggestion there — without rendering it unusable to its current user base.

The simplest idea is to have just two states: Ajax on or Ajax off. If off, the interface behaves like a normal web application. If on, you get all the bells and whistles. And the world would be a simple place if we just had vanilla and chocolate ice cream. So along comes the idea of degrading gracefully, not just on or off but a stepwise falling off as the browser loses capability. A lot has been written on this topic, so I thought I’d round up some of the best articles and see what they have to offer:

• The Hows and Whys of Degradable Ajax – this article takes the approach of really trying to separate on the browser regular web application development from Ajax. Their method is to design a vanilla web application with post-backs, links, forms and noscript tags. Once the vanilla site is done, all of the events generated by the pages are captured using JavaScript. For example, each link might have an onclick attribute that processed the click event and returned false. It is on top of these captured events that the Ajax version is built. The technique in this article, which was written in late 2005, is pretty ad hoc, doesn’t abstract widgets or make use of a framework, and really doubles the work for the developer, requiring him to essentially developed to applications. (Jeremy Keith calls this style of intercepting events of a vanilla web site HIJAX.)
• Graceful Degradation with Prototype, Scriptaculous and Ruby on Rails – this three-part article is also from late 2005, takes more of a framework approach. IDs are assigned to DOM elements that require some sort of Ajax behavior. Rules are defined in JavaScript that use regular expressions to match those IDs to behaviors, such as the effects in Scriptaculous. (Note: I was never able to find part three of this series.)
• CSS: The Tech Ajax Forgot – this article from July of 2006 suggests using CSS to hide Ajax elements until a JavaScript onload event can make them visible by manipulating their styles.
• Open Says Me – this article takes a more architectural approach, dividing a Ruby application into separate modules with advanced, Ajax functionality having its own controller. A cookie and some filters ensure that the more advanced functionality can only be accessed by appropriately capable browsers.
• Introduction to dojo.io.bind – this might be considered cross browser compatibility, but technically the Dojo toolkit degrades gracefully from browsers that support XMLHttpRequest to those that support IFrames, dynamic script insertion, or other more exotic transports.
• Three forms of AJAX: solid, liquid and gas – this short article argues that implementing Ajax at a sub page level gives the best possibility for degrading gracefully.
• Ajax and Accessibility – this white paper from Backbase looks at the issue of degrading gracefully from the perspective of accessibility. One of their suggested approaches is to provide a second user interface that uses no Ajax and is compatible with accessibility technologies such as screen readers.

After spending a good time digging for information on this topic, I am vaguely dissatisfied. I was disappointed not to find more progress since late last year. I know that frameworks such as Tibco GI and Ajax anywhere claim to degrade gracefully, but precious little information is available on how they do that. It’s possible that after being top of mind in late 2005, everyone found that it was much more efficient and interesting to focus on pure Ajax for the latest browsers. If you build it they will upgrade, so to speak.

Technorati : accessibility, ajax

Share/Bookmark