accessible.ie

The issue of rich media and accessibility has been raised many times on accessible.ie. Many of the same accessibility issues that blighted Flash and Shockwave content for years are now applicable to Ajax.

At present, sites built with Ajax are deemed inaccessible to any user using assistive technologies. Considering the work that was done to popularise the standards based approach, the fact that many sites are now deviating from it in order to offer dynamic, responsive content to users is worrying. Is there a middle ground that can be reached between best practice XHTML/CSS and Ajax-powered online applications? Better still, can Ajax eventually become an accessible technology?

“Ajax techniques cannot be considered accessible”

Writing for sitepoint.com, freelance web developer James Edwards carried out a number of tests with leading screen-readers to see how they deal with the events and actions of an Ajax environment. Because Ajax works asynchronously, there are major issues updating the screen-reader to either read out the new content, or even acknowledge and realise that the page has been updated. Unfortunately, Edwards had no luck finding solutions to these issues. He writes:

“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.”

In the June 2006 issue of Computer World magazine, in an article entitled “Accessibility issue comes to a head, Jeff Bishop, an application systems analyst at the University of Arizona, was interviewed about the move from straightforward XHTML/CSS to D-HTML (Dynamic HTML) Ajax-powered applications. Bishop is blind and uses a screen-reader to browse the web. He is concerned that more and more developers and corporations are disregarding people with disabilities.

“Before, so what? You had a missing [alternative-text] tag, but at least you knew there was an image. You could click on it, and maybe you could figure out what it was. Now, you don’t even know where to click. You don’t know how to interact.”

Can Ajax be of benefit to some disabled users?

It is interesting to note, however, that Ajax in its current form may actually have benefits for some users with access problems. In his research piece, Is Ajax accessible? At all?, accessibility expert Joe Clark concedes Ajax offers assistance to some users that XHTML/CSS can not. He writes, “users with cognitive disabilities, such as dyslexia, can benefit greatly” from the use of Ajax.

Clark considers the idea of having expanding text options that would make a page less text-heavy, something that is of potential benefit to those with cognitive disabilities who may not interact well with large amounts of text. Ajax can be used to implement a slider to “expand text” to increase the amount of text on the page, an approach that can be seen on the item descriptions page on the shopping.live.com site, part of Microsoft’s Ajax-powered assault on the Web 2.0 market. The site implements a dynamic slider that allows the user to choose variations of image or text based presentations for its item descriptions.

It is interesting to consider the example of the slider alongside that of Live Search, which we discussed in detail in the first Ajax article here on accessible.ie. One of the main selling points developers use when promoting Ajax is its ability to create a more fluid user experience, something that is well demonstrated by both the slider and the live search. Unfortunately, this user-enhancement tends to come at a very worrying cost, a loss of accessibility. This contradicts a main aim of the standards based approach where accessibility and usability should co-exist with equal importance.

Implementation

At present, the accessibility-conscious developer has the dilemma of whether to embrace Ajax or avoid it completely. At present, the framework that Ajax uses means that featuring it prominently on your site will almost certainly prevent your page from validating. The developer has 3 choices on how to implement Ajax.

Implement Ajax from the start and disregard accessibility

If you use Ajax on your site as a main part of the architecture, it’s almost certain that your pages will be inaccessible and won’t “transform gracefully” to different browsers and platforms.

Offer an accessible version alongside your dynamic version.

Google offer their users the option of a HTML version of its Ajax-powered Gmail application. Two versions of a site guarantee an accessible version of your content but goes against the ideals of the standards based approach.

These two options are both against the W3C’s recommendations for creating accessible web content. Right now, and until a workable framework is developed, Ajax cannot be considered accessible. While some pages with Ajax perform well in the W3C validator, it’s their poor interaction with screen-readers that deem them inaccessible. If a developer decides they must use some Ajax, they should choose the third option outlined below. It accommodates users with screen-readers by informing them what is happening.

Tell the user

that the page is updated dynamically and requires Javascript to be enabled in their browser. Make sure your user knows when information has been updated by using alerts that are read by screen readers and are displayed together with a sound. [standards-schmandards]

Tags: accessibility, ajax

This entry was posted on Friday, July 14th, 2006 at 11:51 am and is filed under accessibility, standards, usability. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.