A for Ajax, Part 3: Accessibility

“The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.” Sir Tim Berners-Lee

In Part 1 and 2, I reasoned why and how an Ajax enabled web application performs better than an application built the traditional way. So should we Ajax enable all our web applications? The answer is no.

A serious issue with Ajax enabled web applications is that of accessibility by persons with disabilities.

Most of the discussion center on visually impaired users who have embraced “the power of the web” through assistive technologies such as screen magnifiers and screen readers. The problem arises from the inability of Ajax enabled web applications to effectively communicate to assistive technology, especially screen readers, that a part of the page has been updated, and allow users to easily investigate those changes.

These articles detail the problem:
AJAX Accessibility Overview
AJAX and Screen Readers - Content Access Issues

James Edwards, presenting his findings on how screen readers dealt with Ajax enabled web applications [http://www.sitepoint.com/article/ajax-screenreaders-work], remarks: “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 nonscript alternative being offered to users up-front.”

In 2006, Freedom Scientific, the developers of JAWS, a widely used screen reader indicated that version 7.1 of the software would be designed to work with Ajax based applications:
Developers Working to Overcome AJAX Accessibility Issues

This 2007 article indicates that, though some improvements have been made, the current level of support for Ajax in screen readers leaves a lot to be desired:
Improving Ajax applications for JAWS users

With Ajax pushing the boundaries of technology on the Web, and screen readers still stuck on outdated technology, it is very frustrating for the innovative developer.

However, there are other areas of accessibility where the developer can be more attentive to his users: think of people with learning/cognitive disabilities, for example, people who can’t use a mouse: did you provide them with an alternative to that cool drag and drop feature? Do you really require that drag and drop feature?

Some initiatives are underway: Charles L. Chen and T.V Raman has come up with a JavaScript framework - AxsJAX - for enhancing the accessibility of AJAX applications. “The AxsJAX framework helps inject accessibility features into these applications so that users of adaptive technologies such as screen readers and self-voicing browsers experience the same level of interactivity that is now taken for granted by users of Web 2.0 applications.”

The W3C has begun working on a standard that “defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies.” This standard is currently a working draft. It will be a while before this is a recommendation, and developers and manufacturers of assistive technology understand and implement it.

Till then, if we have to develop a web application where accessibility is mandated, it is best to go the traditional route.

Further reading:
Accessibility Links
IBM Human Ability and Accessibility Center
Microsoft

Firefox extensions:
Fire Vox: a cross-platform self-voicing extension that includes early support for most of the leading edge features of W3C ARIA
Fangs: a screen reader emulator

A for Ajax, PART 2: Some data to substantiate claims made in Part 1

In Part 1 we discussed that an Ajax enabled application will perform better than a traditional web application. In this post we substantiate this claim with some data.

We compare a web application built the traditional way, in ASP.NET 3.0, with the same application built the AJAX way. Both application fetch data from the Northwind database using the same stored procedures. All the stored procedures have a wait period of 1 second to simulate delay.

We use Fiddler and Firebug to monitor the HTTP traffic, and the Web Application Stress Tool to load the sites with concurrent requests, and examine some of the data generated.

You can read the entire document here [http://docs.google.com/Doc?id=dcggqmtv_36c2tjrqg4].

The source code of the example applications, the Fiddler data used in this post, can be found here. The code is in C#, targets the .NET 3.5 Framework and developed using VS2008 SP1. The Northwind database is included in the download, you can either copy it to the App_Data folder of the applications, or attach them to SQL Server 2005. Rememeber to change to the appropriate connection string in the web.config.