10 "MUST READ" ARTICLES ON AJAX AND ACCESSIBILITY

AJAX (Asynchronous JavaScript and XML) is the hot and happening new web technology - all the really cool sites are using it now, right? It’s all about the user experience, right?

Well, perhaps, but more often than not that user experience is flawed for as many as 25% of your site’s visitors. Furthermore, using AJAX may actually be hurting your web site. But don't just take my word for it, read all about it yourself. Collected below is a series of articles and opinions that hopefully will leave you with the same conclusion - if you’re going to use AJAX, you had better be prepared to works twice as hard, and possibly maintain 2 versions of your web properties: there often is no other way.

AJAX Accessibility Overview - www-306.ibm.com/able/resources/ajaxaccessibility.html

The use of AJAX and dynamic, incremental updates are a paradigm shift of Web usage, people are not always expecting this new behavior. Users may be unaware of updates to a page or may not notice that a part of the page has changed. For example, if a user updates a quantity field for an item in a shopping cart, AJAX can be used to detect the quantity change and automatically update the total price, taxes, and shipping cost fields on the form. The user may not expect these fields to automatically update without having to explicitly request an update. Even if a user is expecting information to update, they might not notice the actual change in data.

The problems can be exacerbated for those who use assistive technologies (AT). Updates can occur on a different area of the page than where the user is currently interacting. This is especially true for people that use screen readers and screen magnifiers.

An important lesson learned about AJAX and accessibility - www.robertnyman.com/2006/04/25/an-important-lesson-learned-about-ajax-and-accessibility/

After some digging, we found out that the JavaScript file was completely blank! The reason for this, apparently, is that the proxy server they had to go through to access [the] internet totally cleansed any JavaScript file that contained this text:
new ActiveXObject

So much for object detection and every other approach we recommend to web developers. Not a single line of code was left behind in the file. And the problem is that it won't throw an error or show the content of a noscript tag either; everything just stops working.

Front-End Architecture: AJAX & DOM Scripting - www.garrettdimon.com/archives/front-end-architecture-ajax-dom-scripting

A potential problem with AJAX is redundant code or misplaced business logic. Remember, JavaScript is only meant for enhancing behavior and performing client-side manipulations. It was never meant to handle complex business logic or hefty calculations. However, if you're not careful, it's easy to overlook this and have your business logic split between your server-side code and a client-side script file. That is almost guaranteed to turn into a maintenance nightmare.

Another possible problem is potentially having to duplicate logic in both your server-side code and your client-side scripts. This is more of an architectural decision. As long as the client-side scripting only enhances the experience and doesn't perform any actually functionality, which it shouldn't, then you should be fine. Bear in mind, if you have any redundant logic, you just doubled your effort when it comes time to maintain or enhance your work.

Responsible Asynchronous Scripting - www.thinkvitamin.com/features/ajax/responsible-asynchronous-scripting
Using XHR (XMLHttpRequest) circumvents the browser's history. As a result asynchronous scripting is most appropriate for actions and transient or conditional data-not navigating content. XHR doesn't break the back button, misunderstanding user expectation does.

Try this litmus test: If refreshing a page immediately after that page has been updated by remote scripting results in an essentially identical page then you're doing okay. If not, head back to the drawing board.

AJAX and the Search Engine Problems - weblogs.asp.net/mschwarz/archive/2005/08/06/421761.aspx
There are already thousands of web sites using AJAX or similar techniques. One problem all of them have is the point that web crawlers will only search for HREF, SRC or some other link tags. I never saw a web crawler that is searching for AJAX JavaScript proxies.

Accessibility of AJAX Applications - webaim.org/techniques/ajax/
AJAX will not work in all web browsers. As its name suggests, AJAX requires JavaScript. This alone means that AJAX applications will not work in web browsers and devices that do not support JavaScript. For this reason it is not accessible to many typical Web users. The Web Content Accessibility Guidelines also require that web applications function when JavaScript is disabled or not supported. AJAX also requires that XMLHttpRequest be supported, which many browsers do not.

The current solution to these problems is to either provide a non-AJAX alternative to your application or to allow your AJAX application to continue to function if JavaScript and XMLHttpRequest are not supported. Such a requirement may be very difficult to achieve. While developers may choose to require the users to use a browser that supports AJAX, they must understand that such requirements may not be possible for all users - especially those using portable devices or older web browsers.

For Many AJAX is Not Degrading, But it Must - vanderwal.net/random/entrysel.php?blog=1770
Part of my problem with much of the push towards AJAX (it is a good, no great thing that XMLHTTPRequest is finally catching on). But, it must degrade well. It must still be accessible. It must be usable. If not, it is a cool useless piece of rubbish for some or many people.

Accessible JavaScript Guidelines - cookiecrook.com/AIR/2003/train/jsguidelines.php
Use JavaScript to enhance the usability features for the majority of users, without negatively affecting the accessibility for the minority of users. You can almost always fall back.

Why Ajax Sucks (Most of the Time) - www.usabilityviews.com/ajaxsucks.html
The fundamental design of the Web is based on having the page as the atomic unit of information, and the notion of the page permeates all aspects of the Web. The simplicity of the original Web contributed to its ease of use and its rapid uptake.

AJAX breaks the unified model of the Web and introduce a new way of looking at data that has not been well integrated into the other aspects of the Web. With AJAX, the user's view of information on the screen is now determined by a sequence of navigation actions rather than a single navigation action.

Emerging web technologies will simply not "go away", and avoiding them or burying our heads in the sand won't change this fact. So best practices and real solutions must be developed.

This does not mean we cannot use JavaScript, it only means we add it as an option rather than a requirement.

The Hows and Whys of Degradable Ajax - particletree.com/features/the-hows-and-whys-of-degradable-ajax/
The general strategy here is to start by creating a page that works like a normal site-processing information on page loads and refreshes. Then, if JavaScript is enabled, we have our scripts bypass this normal functionality and replace it with sweet Ajax functionality.