The intersection of DOM Scripting and accessibility can be confusing. There are plenty of opinions, beliefs and myths circulating. What’s really needed are some hard facts backed up by good old-fashioned testing.
Part of the problem lies with the technology involved. Just as there are many different types and makes of web browsers, there is no one single screenreader application. And — just as with visual browsers — there can be enormous variation from version to version. Add to that the fact that screenreaders and speech browsers can be customised to a huge extent and you’ve got a situation that can make testing tricky.
In the past few days, two important papers of test results were released. James Edwards (AKA Brothercake) wrote some test cases and has summarised the findings of his tests on Sitepoint. James is trying to answer a fundamental question about screenreaders and the Document Object Model: how can we ensure that screenreader users are notified that part of the page has been updated?
Just to be clear, this isn’t specifically related to Ajax; the question arises with any client-side script that updates the DOM. It’s just that Ajax applications by definition will be updating the page, so the question has been given more urgency in recent times.
James’s findings don’t make for happy reading. In most situations, most screenreaders won’t exhibit the behaviour we’d like:
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.
But it isn’t all bad news. Joe Clark has been doing his own research. Where James was working with theoretical test cases, Joe was testing an application in the wild, namely Basecamp from 37 Signals. He fully expected the worst but things didn’t go quite as bad as they could have.
Sure enough, as per James’s research, screenreaders don’t behave as seamlessly or interact as intuitively as we’d like with an Ajax application like Basecamp. But that doesn’t necessarily mean that the application is completely inaccessible:
My results are easy to state: Everybody could do everything. It just wasn’t all that convenient.
That’s the thing: there’s rarely a yes/no answer to the question “is this accessible?”. Instead, there’s a continuum of difficulty. How far down that continuum an application goes depends on many factors from how the site was coded to what technology the visitor to the site is using.
So what’s the answer to the burning question, “Is Ajax accessible?” The answer is “define accessible.” In a well-coded Ajax application, screenreader users do have access to the same content as visual browsers. However, the users will probably have to seek out that updated content: the current technology offers little help in providing feedback to the user.
Fortunately, technology changes (though not usually as swiftly as we’d wish). I’m sure that screenreaders will improve but we’ll still have to support the current screenreader landscape for quite some time.
In the meantime, what developers really need are good solid real-world tests. James and Joe are doing a great job at getting the ball rolling. They aren’t doing it alone: Derek Featherstone, as always, is right at the forefront of JavaScript and accessibility testing. James, Derek, Mike Stenhouse and Bob Easton are doing fantastic work. We owe them all a debt of gratitude.
Posted by Jeremy on Monday, May 8th, 2006 at 7:41am
Comments
In terms of notification, would a very small SWF movie containing a single sound be a good work around? It could operate a similar conceptual way to the Yellow Fade Technique, except obviously in an aural way rather than a visual way.
On a practical level, defining and subsequently calling a JS function which passes a variable into Flash would be child’s play. Actionscript picks up the incoming name/value pair and initiates the movieclip containing the sound.
You could even supply a number of differing sounds to indicate what part of the page had been updated. Further you could tailor the page to ask a user if they want sounds or not and thus those who desire aural notifications get them and those that don’t, won’t.
It’s a two fold problem: on the one hand, DHTML developers do not always take programmatic considerations seriously, e.g. setting focus to an element versus emulating visual focus with CSS. No matter how smart a screen reader is, no feedback will be provided when an element claims to be in focus (visually), but not programmatically. The problem is similar to the one we have with desktop applications. On the other han, screen readers have been relying on system events exclusively for a long while and DOM events is something very new in the screen reader land. Unobtrusive scripting does resolve some of the accessibility problems, but far not all of them. Just a quick example: set of radiobuttons may be presented as set of hyperlinks which, when clicked on, reflect their selection status visually. Because there is no more information about the widget (its type, name etc), screen reader does not know whether the set of hyperlinks is a set of radiobuttons, list of options or simply bunch of links. Two solutions here: 1. Use standard HTML elements and CSS them; or, better yet, 2. http://www.mozilla.org/access/dhtml.
# Posted by Victor Tsaran on Monday, May 8th, 2006 at 6:08pm
Sorry. Comments are closed.