Stanford Online Accessibility Program

10 "Must Read" articles on AJAX and Accessibility

Plus 3 4 more for some light at the end of the tunnel relief...

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.

It appears to be the "must-have" technology at the moment, and a lot of uses for it seem to be contrived. I do see a need for it, but its strength is for web applications, rather than traditional web documents. It reminds me a bit of when Flash first arrived on the scene, and everyone felt the need to learn Flash in order to showcase their skills, with little regard to the true usability of what they were doing.

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. Or, when people explicitly request an update by selecting a link or button, they may be surprised when the entire page does not reload. In addition, since pages are updated incrementally, AJAX applications may not have distinct uniform resource identifiers (URIs) that can be bookmarked. This can also lead to issues with the Back button not functioning as expected.

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. Even if the user is expecting an update, she may not have any idea how to locate the updated content. Applications which set focus to updated data can be especially troubling for some users. Imagine a user who is still reading the first paragraph of a page when an update occurs that moves the focus to a lower portion of the page. The user is likely to become disoriented and now has to find and scroll back to her previous position on the page. If a repeating update occurs that changes focus again, she may never be able to complete the interaction with the page!

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.

AJAX and Screenreaders: When Can it Work? - www.sitepoint.com/article/ajax-screenreaders-work

I'm forced to conclude that, unless a way can be found to notify screen readers of updated content, AJAX techniques cannot be considered accessible, and should not be used on a production site without a truly equivalent non-script alternative being offered to users up-front, on a plain HTML or server-side solution for the benefit JavaScript provides.

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

(A spoof of Jakob Neilsen's article "Why Frames Suck (Most of the Time)" with relevant points none-the-less)

Part of the genius of Tim Berners-Lee's original design of the Web was a total unification of several concepts in a single idea, the page:

• the user's view of the information on the screen
• the unit of navigation (what you get when you click a link or activate a navigation action like a bookmark)
• a textual address used to retrieve information over the net (the URL)
• the storage of the information on the server and the author's editing unit

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.

... It's not all doom and gloom:

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. Here are some early thoughts:

Hijax: Progressive Enhancement with Ajax (presentation) - domscripting.com/presentations/xtech2006/

The Hijax approach

• Begin by creating a website using traditional page refreshes.
• Data is sent to the server via links and form submissions: the server returns updated pages.
• Intercept (hijack) those links and forms using (unobtrusive) JavaScript.
• Send that data to XMLHttpRequest instead of the server.
• The server returns just the information that's required instead of an entire page.

Making Ajax Work with Screen Readers - http://juicystudio.com/article/making-ajax-work-with-screen-readers.php

The accessibility community is understandably concerned about the accessibility of client-side scripting, in particular using Asynchronous JavaScript and XML (Ajax) to produce Rich Internet Applications. Steve Faulkner and Gez Lemon on behalf of The Paciello Group (TPG) have collaborated in an effort to come up with techniques to make Ajax and other client-side scripting techniques accessible to assistive technology.

Unobtrusive Javascript - www.onlinetools.org/articles/unobtrusivejavascript/

We only use JavaScript to enhance a functionality that is already given, we don't rely on it. JavaScript can be turned off or filtered out by proxies or firewalls of security aware companies. We can never take it for granted.

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.

Epilogue

AJAX is an immature technology, and so more information and guidance is emerging every day. If you have a link or an article that can contribute to this over-view (Pro or Con), please let me know and it will be added to the list. Last updated: Dec. 13, 2006

Unless indicated otherwise, this work is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.