I’m at a cosy little conference in London with the grandious title of Accessibility 2.0: A Million Flowers Bloom. I’ve just finished delivering the opening keynote which I tried to make as pretentious as the conference title.
Now the mighty Steve Faulkner is up to deliver a talk called Making Twitter Tweet. He’s being introduced by Robin Christopherson and is getting a round of applause for being the guy who created the Web Accessibility Toolbar. Steve begins by clarifying that the Web Accessibility Toolbar was very much a team effort.
Steve will be talking about Ajax, using Twitter as a case study. But this is not an exercise in Twitter bashing. Also, remember that accessibility is not just about blind people even though that’s what Steve is focusing on today. By the way, he’s stevefaulkner on Twitter.
There are some issues with bad or no
Ooh, he’s going to talk about the use of the
abbr element in microformats. He’s talking FUD about human vs. machine readable data and I’m rolling my eyes. He’s showing suggested alternatives (which have equal misuse of the
title attribute). Now he’s saying that the microformats community don’t seem to want to take them on board. He’s talking complete bollocks in other words. Firstly, he’s damning microformats when in fact he has an issue with one part of one microformat (the abbr pattern in hCalendar). Secondly, there is a heck of a lot of discussion and testing work going on in the mailing lists and on the wiki with WaSP collaboration. By the way, Robin — who is sitting two seats away from me — was recently brought in to test BBC listings which had been marked up with hCalendar. He described the feared accessibility problems as unfounded. Most screen reader users do not change their default settings for abbreviations and by default, abbreviations are not expanded. Besides, an internationalised way of writing a date is not just machine-readable data (I’m a human and I can read 2008-04-25 just fine). I’m not saying that the abbr pattern doesn’t have problems (it does but they are semantic in nature) but Steve is mischaracterising the current situation.
Anyway, back to Twitter. There are links (like the favouriting star) that should really be buttons. This is something I touched on briefly in my keynote: know when to use a link and when to use a form element. Steve suggests an
input type="image". Really, it’s a button with two states but HTML doesn’t really provide an element for that says Steve.
On to Ajax. There are two issues:
- Users having access to changed content.
- Users knowing that content has changed.
First there’s an explanation of how the virtual buffer in Jaws work. Updates to the buffer occur approximately 600 milliseconds after a control is pressed. So screenreaders don’t react to changes in the content, they react to user interaction. With the Twitter favouriting functionality, the time between pushing the button and the content being changed is the problem. Fire up Firebug to see how long the Ajax request takes. It’s about a second. That’s less than 600 milliseconds. We have a problem.
So, to start with, the browser view and the screen reader view is synchronised; the pseudo-button is off. The user clicks. The browser view is updated to see the selected state. The screen reader view still sees the old view. This isn’t just an Ajax issue but Ajax magnifies the problem because of the round-trip to the server.
Good news! JAWS 7.1 has effectively solved this issue. It doesn’t listen for user actions, it responds to changes in the DOM. But Window Eyes still has this problem.
A solution is to inform the user that content has changed. ARIA live regions will have this but we don’t have that yet. In the meantime you can try some other tricks. You could provide text hidden off screen that tells the user that “content updates occur frequently—if things aren’t working as you would expect, try refreshing the page” (triggering a re-read).
The second issue is letting users know that some content on a page has changed. Twitter provides the character countdown but users have to exit out of forms mode to get it. There are three possible solutions:
- Use alert boxes.
- Use WAI-ARIA live regions but that’s not yet supported.
Let’s move beyond Twitter and look at WAI-ARIA: Web Accessibility Initiative — Accessible Rich Internet Applications. Basically it allows you to add information to elements to describe their roles and their states. Here’s the main point: It’s easy! You just add a few attributes to your existing markup. Steve gives us some example markup. It looks pretty straightforward.
Now it’s question time. I think I should resist the urge to call him on his dissing of the microformats community and let other people ask questions about genuine accessibility problems instead.