ARIA, feature detection, and the lowest common denominator

For the past couple of months I've been doing a lot of work with accessibility.  Parts of the design of the website I'm working on are very dynamic, with ajax and inline changes and dialogs.  It's relatively easy to get these things to be keyboard accessible (though that has its difficulties, too, perhaps that's another blog post), but the big challenge is getting it to be comprehensible to those who interact with the site with screen readers.

One example of something I've done is a list with delete buttons.  When a user clicks the delete button, the item it belongs to disappears and a message appears informing the user that the item has been deleted and asking if they want to undo that action.

It used to be safe to assume (or so we thought, anyway) that screen reader users would have javascript turned off.  So as long as a site had a non-javascript fallback, it was "accessible."  Users with screen readers would get a new page, and their screen reader would read all of it including whatever changed, others would get something fancier like an in-page reload. So in the example above, screen reader users could get a completely new page with a shorter list and the success message at the top, everyone else would have the item removed inline.

But the WebAIM 2009 screen reader survey says that the "vast majority of screen reader respondents encounter scripted content".  Only 10% of those surveyed said they turned off javascript, 75% said they didn't, and 15% didn't know.  If 75-90% of screen reader users are getting the javascript version, just having a non-javascript fallback isn't going to cut it anymore. That means that in my list example most screen reader users would push the delete button, the inline removal and status message would appear, and the screen reader would not tell the user either that the item has disappeared or that a status message has appeared without further work by the developer.

Announcing new content with focus control

One method for getting a screen reader to announce new content is by controlling focus. When you click on items or tab through the links you change the focus, and every time the focus changes the screen reader announces the newly focused item.  Javascript can also cause the focus to change, and thus get the reader to announce something new.

This technique is limited in several ways.  First, only interactive elements cannot be focused in older browsers--in other words, the paragraph explaining that the item has been deleting cannot be focused (or announced), but the undo button can be. It's not a great experience, but it's probably better than a full page reload or no feedback at all.

Second, changing the focus also moves the screen reader's position in the page. If the user is in the middle of a list and the announcement is at the beginning, now they've got to move all the way through the list. The screen reader probably has hotkeys to let them do it quickly, but still it would be nice if they didn't have to do that.

Finally, it's just hard to get this to work reliably in all browsers (this is web development, what did you expect?! ;)).  Sometimes the focus just disappears unless you add a timer to wait before focusing. What it focuses on when you hit tab at that point varies widely, sometimes within the same browser. I even got firefox to decide that tab meant select the next line of text, or to say one thing and highlight another, or to just have the screen reader announce "Unknown object" or nothing at all.  Sometimes the presence or absence of a screen reader affects whether it works or not. All in all it's a pain in the butt.

Announcing new content with ARIA

A newer alternative to using focus is ARIA Live Regions. (If you're new to ARIA and accessibility, I highly recommend the design pattern section of the ARIA author guide, it's very helpful not only for the ARIA properties but for keyboard control and other accessibility best practices) ARIA live regions allow the screen reader to announce changed content or all content of a given section of a page whenever something is added, removed, or changed.

ARIA is still a spec, however, and not fully supported anywhere. And the wrinkle with using it is that it must be supported both by the browser and by the screen reader or you're back at the no accessibility at all state.

Since it is still a spec, I imagine there are a lot of screen reader users with browser/reader pairs that don't support it yet (if someone has real numbers on that I'd would seriously love to have them), so I tried to combat that by using both aria and focus.  Theoretically, ARIA-enabled users would have the entire "Item X has been deleted. [Undo]" message read to them, non-ARIA users would have just "[Undo]", and everyone else wouldn't notice anything.

That is not what happens. In some ARIA-enabled browser/screen reader combos, the reader will begin to read the status message, then get interruped and just read "[Undo]". This is actually worse than not adding ARIA at all.

The need for feature detection

This is actually a classic problem for web development. Theoretically, a site can be designed so it works well for the lowest common denominator, and is progressivly enhanced for newer and newer browsers. However, in practice the browsers that fall between no support and full support frequently implement only some of the required features, or they implement them badly or incompletely, making the experience much worse than the no support scenario. But we can detect which features are available, or sometimes check how they're implemented (e.g. IE6's box model) to figure out if the experience needs to be degraded to the next tier down or otherwise altered in some way.

The list example would be a great place to use feature detection--if there's no ARIA support, focus the button, otherwise don't.  Unfortunately, so far as I can tell there's no way to detect if there's a screen reader at all, let alone anything about ARIA support, which leaves me with the following options:

  1. Remove javascript, provide a worse experience for non-screenreader--users (most of them) but a semi-accessible one to the screen reader users
  2. Give up on the new stuff, just use focus--most users will not notice a difference, some screen reader users will have a worse experience than they could have but it will be semi-accessible for all of them
  3. Design for the future, expect users with old screenreader/browser combos will eventually upgrade to a much better experience--users without screen readers again won't notice a difference, users with screen readers and ARIA will have a pretty nice experience, for everyone else it's inaccessible (but it's a decreasing number....)
  4. Provide a second site without javascript
  5. Give up on the whole accessibility thing entirely, it's just too hard

I don't like any of those options, but I need some help from browsers and screen readers to make good compromises possible.

I have heard people argue against just what I'm asking for, or screen reader detection in general (and I appologize that I can't find links to the arguments). The people who don't want it worry that web developers will misuse the power, and we'll have sites that say "Sorry, you can't see this site because you're not using Jaws forWindows" when in fact the user has a browser that's perfectly capable of handling it.

The thing is, though, we've already done that and learned it was a bad idea. I remember sites I couldn't access for not using Netscape 3 when I was using IE 5 (back when that was a good browser). We know better now, and I think those of us who know enough to create an accessible site in the first place can handle the responsibility of screen reader feature detection.

It is possible that you will see sites that are alternative versions specifically tailored to screen reader users. And some people seem to think that's a problem, too, but personally I wonder if it's really that bad. Alternative versions don't mean less or different content, they usually mean different presentation. Mobile users get alternate versions all the time because the full-size desktop version just isn't a good experience on a mobile device for all sorts of reasons, but the developer can provide something better.  I wonder if maybe that's ok here, too.

And let's not forget, some sites already have alternate, "accessible" versions of their sites (option 4 above) because getting the original working is just too hard.  Feature detection might actually make it easier for them to consolidate by making it easier to make the original accessible for all users in the first place.

Comments