KuraFire Network

With DOM Scripting and Remote Scripting making their way into standards-compliant web development, people are beginning to wonder what the effect of these techniques is in screenreaders and other assistive technologies. Kevin Leitch asked me and some others about AJAX and Accessibility. Since I couldn't quite remember seeing a post discussing this in a practical matter, I figured I might as well just write out my ideas myself. Important note: the following post is purely theoretical, and is not tested yet.

The example that Kevin asked about concerned reloading a list of content on the site without refreshing the page. A simple job for Remote Scripting indeed, but what about the accessibility aspects?

We already know that screenreaders have great difficulty with content generated on a page via DOM Scripting, something that causes us headaches but which can be used to our advantage after all. Let's explore that, shall we:

• screenreaders tend to not read generated content (it's been reported that they are very erratic in this, however);
• we want to cater to screenreader users as well, but the most popular one, JAWS, hooks in on browsers that generally have Javascript still enabled and that can use the xmlHttpRequest object, needed for Remote Scripting

What do we want to achieve? We want our list of content to be updated, and we want it to work under all these circumstances:

1. the user has Javascript disabled
2. the user has Javascript enabled, but lacks basic JS-functionality, needed for our task
3. the user has Javascript enabled, but no support for xmlHttpRequest, thus no AJAX
4. the user has a screenreader; Javascript can both be enabled and disabled in this case, both situations must work
5. the user is an ordinary, seeing user with a modern browser with full capabilities and Javascript enabled

So how do you cater to so many situations? Well, my theory consists of using the screenreaders' deficiencies to protect them from themselves. It goes a little something like this:

First, create the list of content:

<ul>
        <li>Foo</li>
        <li>Bar</li>
</ul>

What an amazing example. Moving on, we want users to refresh this list via a click event: a link that says something like "refresh list" and here it is:

<p><a href="">refresh list</a></p>

This covers the first goal already (an empty href attribute points to the current page, whatever page that may be), but the trick is to make this unobtrusive and work well with screenreaders.

Adding id attributes to both the list and the paragraph with the refresh-link, we can now play around with this through DOM scripting:

<p id="list-refresh"><a href="">refresh list</a></p>
<ul id="list-content">
        <li>Foo</li>
        <li>Bar</li>
</ul>

When Using Javascript for good, not evil, we cover situations 2 and 3 (Javascript enabled, necessary functionality lacking). Now comes the tricky one: screenreaders.

The concept is simple, but as indicated at the start, this post is theoretical so far, there is no test case yet. Here goes, anyway:

First, use unobtrusive Javascript to hide the existing refresh-link from visible eyes. Second, put a new link right in its place that has a text like "instant refresh" as the label, then add an onclick event with Javascript that does unobtrusive checks for functionality and, if all is well, goes ahead with AJAX-flavoured goodness (odd image for Dutchies) to add new content to the list and returning false on the link (preventing a refresh).

The crux of it is, screenreaders should not read out the generated link, which a blind user then cannot "click" on, meaning their link will be a normal page-refresh link. Only those who can see the generated link will get a link that invoke AJAX-magic.

A test case will be made for this, but I'm currently wondering how useful it will be. Of course, if initial testing proves that this method is flawed, that's one thing, but the truly reliable way of testing this is to use many different screenreaders on many different configurations, and then that's only the beginning. Real accessibility goes a long ways beyond that, still, but I do believe that the above situation would give the most accessible result with the least amount of hassle.

So the catch is to just generate a link for seeing users, add all necessary scripting to the generated link and having the original link behave in unobtrusive manners, the way it would with Javascript disabled. Now, if this approach does indeed work, it would apply to other things as well. Think form buttons for instant previewing and submitting of comments through AJAX magic. There's a lot of potential here, I believe, and I'm definitely going to look into it more as I find time for it.

Bookmark: Newsvine del.icio.us Digg