Ajax, accessibility and assistive technology

I’ve been worrying about Ajax accessibility for a while now, so I was delighted to read two very interesting items of research on Ajax accessibility which were published last week. Brothercake ran some tests and wrote,

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. (Source)

Meanwhile, Joe Clark found what appears at first sight to contradict Brothercake’s research, when he tested a real-life Ajax application:

Everybody could do everything. It just wasn’t all that convenient. (Source)

Actually, these aren’t contradictory at all. Making Ajax apps accessible is a brand new endeavour. So there aren’t any hard and fast rules about what works and what doesn’t. Paraphrasing PAS 78 (because Christopher Okonjo at the British Standards Institution told me not to quote it):

Test your pages, you wanker. With assistive technologies. And real disabled people. Or you’re a bigger nob than you look.

Even when you’re sure of your assumptions, a bit of testing works wonders. And with Ajax, any assumptions seem destined to be proved wrong by testing.

Accommodating Ajax – a joint responsibility

In a comment on a WaSP post calling for vendors to support Ajax, Dan Champion writes,

A standard for ajax/whatever needs to be produced and widely adopted before we can expect AT vendors to invest in supporting it fully. In the meantime the responsibility falls squarely on developers to make sure that they accommodate users of ATs. (Source)

I don’t know what standard can be used (the XMLHttpRequest isn’t (yet) a Standard) but I repeat my call for Hijax to be adopted as the standard Ajax development methodology because Ajax isn’t going anywhere; it’s just too useful and sexy for developers to put down, and it’s vital that we accessibility advocates aren’t once again seen as holding back the vanguard of Web development. The good thing with hijax is that if the basic pre-ajaxified app is accessible, there’s a fighting chance that the assistive technologies will be able to work with it in the future, even if they can’t now. It gives us wiggle room.

But what do we want Assistive Technologies to do with Ajax? Beep and say “alert: something changed, hit x to focus on changed item”? If that one item of change were a single cell in a table, would that give you enough context? Should the screenreader tell you what it the old value was and what it now is so you can compare? There should be a keystroke to “get you abck to where you were” before the alert, shouldn’t there? Should there be an option to say “only alert me every x minutes” so your concentration isn’t disrupted repeatedly? Presumably, there should be a “turn off Ajax” setting (that tells the browser “below” the screenreader to turn off JavaScript?). We need screenreader users to tell us what they need to hear.

I agree with a poster on Brothercake’s original article who says,

I’m sympathetic to the needs of visually impaired users, but sympathy to a small segment of users won’t stop developers from advancing the state of the art in interface design. Nor should it. If things are going to get better for these disabled users I think the burden has to fall on the vendors of screen reader software. To be honest, I think they’ve become too complacent with what is, in effect, a captive audience for their products. It’s time for them to serve their customers the same way that the rest of us take for granted with our web browsers. And maybe it’s time for a concerted effort to develop a free, more reliable, and standards-based open source alternative. (Source)

Finally, from Blind Confidential, the blog of Chris Hofstater, who used to be a high-up in Freedom Scientific (the manufacturer of JAWS):

A group of blind hackers in India are working on an open source screen reader project of their own … If people in India cannot afford a major screen reader, making their own makes sense. (source)

Let’s be honest. Screenreaders are the Netscape 4 of assistive technologies. The main ones lurk on top of MSAA, which is going to be “end-of-lifed” and replaced in Windows Vista. They ignore lots of perfectly nice bits of the HTML spec (like ins and del). They need to drag themselves, or be dragged into the twenty-first century, and if a fully featured, cross-platform open-source screenreader did the dragging, I’d be all for it.

15 May 2006: fascinating post on blind confidential on the difficulties of making screenreaders work with standards.

13 Responses to “ Ajax, accessibility and assistive technology ”

Comment by Lloydi

Y’see, this is *exactly* the kind of documentation style that’s needed. Never mind your fancy-pants W3C sober academic approach, simply call someone a ‘knob’ for not validating. That’ll soon sort things out, eh Bruce? No need for pussyfootin’ around the issue

Comment by Joe Clark

Yes, but, Bruce, no matter what BSI tells you, you have legal rights to excerpt copyrighted works, like PAS 78, for review and criticism. BSI may enjoy the frisson it gets from telling you what to do, but that doesn’t mean they have a case, or that they are not, in fact, knobs and/or wankers.


Comment by Bruce

Heh, thanks Joe. To be honest, I wanted to name and shame them as copyright fascists. I’ve no intention of letting them bully me.


Comment by bex

Why obsess about the blind panther party? Haven’t you seen Fire Vox?


Its an open-source firefox based screen reader!

Nuts to the standards… I say AJAX hackers should chip in and make Fire Vox rock. Then at least we have a chance to make things easier for our blind customers.

Comment by Eric

Maybe the accessibility question should be tried in a larger context, in that AJAX is bringing new interactivity to the web. How do visually impaired users use other interactive desktop applications?

Comment by uk gambling

glad to hear something can be done to make ajax accessible- I had ajax stuff on one of my sites but ditched it due to concerns about users using a variety of assistive devices & Readers.. Good also to hear of an open source screen-reader – many are prohibitively priced..

Comment by Lachesis

Follow up to what bex mentioned earlier:
Has anyone else here tried Fire Vox ?

I just downloaded the latest incarnation and Fire Vox already supports AJAX live regions that are tagged! I think the Fire Vox guy needs to add support for cases that aren’t tagged, but this is still a really good start. Guess it means I should start using tags with my AJAX…

Comment by Kim

I think this is one situation where I wish Microsoft would include software with their OS to monopolize a market: the screen readers market. MS should destroy the existing screen reader market. They are too expensive an non-standardized. If there was a good quality screen reader included in Windows that recognized standard Javascript events and handled them appropriately, so many people would benefit! And MS would benefit too for the PR.

Windows currently has Narrator, but I think even in Windows 7, it does not read web pages…! Am I really right about that? Mac OS has VoiceOver which works with Safari, and I think around 10% of screen reader users use VoiceOver.

Comment by Jason Bratcher

I’m a totally blind user of both the Jaws screen reader and an open sourced alternate named NVDA (NonVisual Desktop Access).
The latter is beautiful in FireFox with the AJax support and tagged elements on the page.
From what i’ve played with on another site, authors can literally force live regions to nest in each other, and only update the region that matters.
Best part?
I will only hear the region that just got updated and i never will hear any of the other live regions.
Also, a “Polite” or “Assertive” tag to a live region goes a long way, especially on news websites with live feeds.
Try to steer clear of the “Rude” tags, unless a majorly important news storythat requires immediate attention needs my focus;
The “Rude” tag forces its live region not just to update, but force speech to cut off and say the new update.