Friday, May 26th, 2006

Ajax and Screen Readers

Category: Accessibility, Articles

“What about accessibility?”

The #1 or #2 question that we got at The Ajax Experience and other shows (“What framework should I use?” is the other one).

Gez Lemon and Steve Faulkner have spent the time to write about Making Ajax Work with Screen Readers:

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 of Vision Australia and founder member of the Web Accessibility Tools Consortium (WAT-C) and myself 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.

The Web Accessibility Initiative’s Protocols and Formats working group directly address the issue of making rich Internet applications accessible, and we borrow some of their concepts to investigate methods of ensuring that Ajax applications work with leading assistive technology products. The bad news is that it isn’t possible to make Ajax work in every known assistive technology, in the same way that it isn’t possible to get Ajax to work with older browsers, but we explain the fundamental issues; how to inform users of assistive technology that a change has taken place, and how they can interact with the content. To illustrate our findings, we summarise the behaviour of popular screen readers.

They even have good examples of screen-reader friendly ajax:

Posted by Dion Almaer at 9:59 am

4.2 rating from 24 votes


Comments feed TrackBack URI

Interesting article and the examples work as advertised, but I wonder if this problem with AJAX and accessibility isn’t best solved by having those companies that create screen readers work with browser developers to allow screen readers to view updated content naturally without having to send the web developers through these extra steps. This whole debate (i.e. Target/Southwest story earlier this week) seems like a small group of people are willing to hinder the web’s progress because the technology they use is out of date, and instead of demanding that browsers and screen readers work more in harmony their taking it out on the content developers instead. Sort of like demanding a tire manufacturer to remanufacture their products to make up for a flaw in the car’s suspension.

Comment by Sean Fousheé — May 26, 2006

The ideal solution is to have fully degradeable pages across your site. The problem with this is that you have to duplicate your rendering abilities on client and server. In the corporate world, duplicate effort means $$$ and longer time to market. Thus it tends to get a lower priority or dropped.

Is it possible to make all pages ajax enabled and still fully accessible? certainly

Is it possible to do that without duplicating all of your rendering code and/or writing custom functionality to support each instance? certainly

Are there any large scale platforms to support this? not that I know of (but I don’t claim to know much)

A few things that screen reader manufacturers (and standards groups) could do that would be of great benefit to accessibility and coder support for it (sorry if this repeats things previously mentioned):

1) have a browser level flag that marks it as ajax/runtime update enabled. That way they could get the advantage of dynamically generated content (document.write) but scripts could easily check whether to make ajax calls for updates or refresh the page.

2) Add a type of label attribute for tags that is not used by normal browsers and a notification function that can then alert the user to change. (<div id=”section3″ acclabel=”Section 3″></div> ….. on ajax update, script calls document.readNotify(‘section3’)…. the reader then calls out “Section 3 has been updated, would you like to hear the changes?”).

With both things, scripts could quickly and easily be written to support all screen readers with a simple if{} at the start.

Comment by Bart Melton — May 26, 2006

Here’s the email I got a while back from Freedom Scientific, makers of the popular JAWS screen reader, on the topic (see below). Perhaps an invitation to the Open Ajax Alliance is in order for them, alternatively, I’d suggest others inquiring on the topic with Freedom Scientific so that they understand the market demand for this. If they tackle it, it’ll result in a whole upgrade market for them to sell their solution into giving them $$$ incentive to do so, while making all of us (and our customers) much happier.

From: Freedom Scientific Technical Support []
Sent: Friday, April 28, 2006 7:39 AM
To: Kevin Hakman
Subject: Re: AJAX?

Friday, April 28, 2006

Dear Mr. Hakman:

Thank you for contacting Freedom Scientific Technical Support. The JAWS screen reader is scheduled to support the AJAX style of web site design in our up coming release of JAWS 7.10.

If you have any additional questions regarding this or any other issue, please don’t hesitate to contact us.

If replying to this message, Be sure to include all previous correspondence pertaining to this matter so that we might better assist you.


Dennis G. Godin
Technical Support Specialist
Freedom Scientific Blind/Low Vision Group
Phone support: 727 803 8600

Our Mission:
To develop, manufacture and market innovative technology-based products and services that those with vision impairments and learning disabilities use to change their world.

At 4/28/2006 08:42 AM, you wrote:

—–Original Message—–
Sent: Thursday, April 27, 2006 8:45 PM
To: Support
Subject: AJAX?, From:
Technical Support – Software

Name is = Kevin Hakman
E-mail address is =

Product =
Serial Number =
Address =

User subject description is = AJAX?

Comment or suggestion = What is the current support for AJAX type
websites and functionality when using JAWS?

* * * End of document * * *


Dennis G. Godin
Technical Support Specialist
Freedom Scientific
Phone Support: 727 803 8600

Our Mission:
To develop, manufacture and market innovative technology-based products and services that those with vision impairments and learning disabilities use to change their world.

Comment by Kevin Hakman — May 26, 2006

[…] Hat tip: Ajaxian. […]

Pingback by Salamis Software » Screen Readers and Ajax — May 27, 2006

MB Technologies is proud to announce Bindows 2.0 – the first Ajax framework to provide advanced Section 508 accessibility support for building Ajax and Web 2.0 applications.

The Bindows framework now leads the market by enabling the fastest time to market for Ajax and Web 2.0 applications that work with leading screen readers, such as JAWS, without requiring any download or installation (zero-footprint).

We spent over a year on this development project and worked closely with The Paciello Group (TPG), international experts in the field of accessible interface design. We’re glad to see that you are highlighting this issue. It’s of major importance to our customers that need a zero-footprint solution with accessibility support for the government and international markets.

Please contact me if you have any questions at

Comment by Ran Meriaz — June 12, 2006

[referring to comment #1] While saying screen reader vendors should work with browser makers to ensure harmony sounds nice, actually getting results in a timely manner is impractical. If it takes Microsoft 3 years to come out with tabbed browsing what makes you think they will work with screen reader vendor with any more alacrity?
In addition, I am concerned with the comment that a few users are holding back the web. 70 million US citizens is not a few people, and adding alternative methods and accessibility structure is in no way holding back normal modes of operations for your “elite” users without disabilities.

Comment by Jonathan Avila — October 19, 2006


I’m sorry, but I can’t let your “70 million” comment go unchallenged. I believe most would agree that when speaking about Ajax (or Web 2.0) and accessibility, we are almost always speaking of it’s use by the blind or visually impaired.

Using some information from the AFB ( I came up with these numbers for Americans.

Blind or visually impaired: 10,000,000
Legally Blind: 13% of total
Over 65: 55% of total
Computer Users: 15%

Generally, the over 65 crowd either don’t or won’t use the Internet, though there use will grow over time as some of the younger generations get older, but we’re not there yet. If my understanding of the “visually impaired” qualification is correct, then I believe a good portion of them can still see well enough to use a computer, maybe with some assistance (larger screens, software that zooms in on portions of the screen, etc…) and maybe not. So we’re really talking about the “legally blind” as well as a component of people in the “visually impaired” category that must use screen readers to access the web.

So if we say 25% percent of the total blind/visually impaired population are visually impaired enough to need a screen reader, plus the 13% legally blind, we’re talking about 3.8 million. Except that at least 55% of them are over 65, but some of them do use the Internet so I’ll go with 50%. That reduces the total number to 1.7 million. Pretty close to the 1.5 million computer users AFB lists. By no means am I saying this is accurate but I imagine it is a pretty good estimate.

Now I am totally for making the web as accessible as possible for as many people as possible no matter their disability. I just don’t think it helps for anyone to say that 70 million Americans (23% of the total population) can’t use Ajax (web 2.0) applications when that is absolutely not true.

Sorry if I sound a little grumpy about this. I just had a conversation with a co-worker about why we can’t deploy any Ajax or Web 2.0 applications for our users. Something about it being a requirement that those who are disabled MUST have the same web experience as those who are not, and providing alternatives MIGHT not be good enough. So yes, in this case it might be said that a small group of the population is preventing the larger community from benefitting from some of the new “cool” features we would like to provide.

Comment by Matt — October 20, 2006

Not only is equal access a right for us (blind and visually impaired) according to several laws in the United States and much of the rest of the developed world, but our jobs and perhaps, someday, our very lives may ultimately depend upon having access to technology. I almost lost my job last year over this stuff! Sean and matt, hmm, well, just appreciate the fact that you apparently don’t have any disabilities, dawn those glad rags and change your attitudes about insuring equal accessibility for all. Screen readers should do more. Mainstream developers should do their level best to make sure they’re accessible. I don’t want to hold back any cool, whiz-bang features or technologies, but, all the same, I am simply not willing to be held back or left behind by others without appropriate consideration and reasonable accomodations.

Comment by Darrell Shandrow — January 13, 2007

I agree that accommodations are important. I have two questions – 1) where does the burden lie, 2) clarity of definition and purpose

The burden is either on the software that is to be compatible with assistive technology or on the assistive technology itself. If developers are expected to produce content that is cross-browser compatible and universally accessible, the browser and screen reader interfaces could be more accommodating to us. I’m sure that if it were easy and inexpensive for programmers to deal with cross browser issues and assistive technology, developers would be happy to bring their content to the widest range of users. But we all know this isn’t so. In the case of browser compatibility, it is general standards compliance and improved standards that together make it feasible to generate cross-browser apps. The same is true for accessibility. We need updated standards and updated technology. This is not a fight against accessibility, it’s a defense against outmoded specifications. Section 508 is in the process of being updated with the help of the w3c, and rightly so. If the standards are improved along with compatible screen readers, perhaps the task of developing accessible, rich applications will become more more mainstream.

The other question pertains to how we characterize this problem. When we ask that a rich app be accessible, this is not really correct. What we really mean is that the content and services behind the rich app are accessible. If the rich features fronting data and services impute higher usability for unimpaired users, then we’re really talking about a presentation level interface issue. If we are clear and consistent and clear about this, then we shouldn’t be trying to make a rich app accessible but rather provide accessibility to the content and services through assistive interfaces.

For instance, the services of a federal building need to be accessible to wheelchair users, but the stairs do not. The stairs are a usability interface to the building to access services. However, a ramp is typically provided so that a wheelchair bound person can use assistive technology (i.e. the wheelchair) to access the services via an interface (the ramp) that is compatible with said assistive technology. The stairs don’t and can’t be made compatible. That doesn’t really make sense.

In some cases, the lines between services and the mode of delivery become blurred. If the two are coupled, then equivalent facilitation may not be possible. For instance, an interactive online pool game or a simple streaming video are both content services that deliver an experience that cannot be separate from its delivery vehicle (i.e. mode of presentation). Therefore, a blind person simply cannot watch a movie or enjoy an interactive online pool game. In fact, this doesn’t make sense. Should a flower shop stop selling roses because some people have no sense of smell? There really is no alternative interface that provides equivalent facilitation. Is it possible to create a device that samples the air and computes mappings for some input device that can be delivered directly to the brain… possibly… but that’s not an appropriate concern of the florist. However, should such a device be created, should the florist also sell device-compatible sprays… perhaps.

Likewise, rich applications have purpose that is tailored to a regular user (not an elite user). If my sense of smell is unimpaired, am I elite? Assistive technology in the form of screen readers is meant for certain types of interfaces and content, especially those meant to be read, such as text documents. Some usability experiences associated with rich apps are simply not convertible to a screen reader interface, and if they can’t, they shouldn’t be expected to. That’s simply illogical.

My conclusions:

1. improve standards and technology
2. improve awareness for all concerned
3. don’t expect all apps to be universally available
4. continue to work toward greater accessiblity of content and services where it makes sense
5. take pains to be very clear about the problems, and the discussion from problem to solution
6. continue to sell lots of nice smelling flowers

Comment by Joe Hanink — February 18, 2007

Very good points Joe. It is always important to improve standards and technology.

Do they have any more source codes available at all for AJax?

Comment by William — February 27, 2007

I am a student studying IT and have come across the issues associated with accessibility for the disabled and can appreciate the complexity the ajax experience face. good luck!

Comment by Redditch — August 2, 2007

Leave a comment

You must be logged in to post a comment.