(Last Updated on )
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.
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
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.