JavaScript, accessibility, microformats
Last wednesday I was down in the Big Smoke, so went to the Web Standards Group JavaScript Meetup to see Steve Faulkner talk on De-Mystifying Screen readers. I’ve admired Steve’s work for a while, because he actually tests real examples on real screenreaders (which is a horrible job).
Here’s what I learned.
- Steve can swear admirably (but being Australian, it’s a national characteristic).
- American blind organisations estimate 65% of the market owned by JAWS, 35% by Window-Eyes.
- JAWS’ capacity to deal with JavaScript dynamically updating pages increased hugely in version 7.1 (version 8 is the latest).
- The main screenreaders have two modes. They generally take a copy of the web page into a buffer, and that’s what they read out. Therefore, if the webpage is updated but the buffer is not refreshed, no hope to the user of perceiving new content. There’s a way to force this to happen without the user needing to do it – see Improving Ajax applications for JAWS users by Steve and Gez Lemon.
- Forms mode is a one in which keystrokes are literally interpreted (rather than understood to be navigation commands. This mode interacts directly with the browser, so no latency with refresh but the screenreader only interacts with focussable content. Need to think more deeply about the ramifications of that …
- Screenreaders behave differently with Firefox and Internet Explorer. (And soon Opera will support screenreaders too).
- All this behaviour is undocumented by manufacturers. Sigh.
I was also glad I stuck around for Christian’s talk (I was planning to haul my arse home), as it was hilarious. And he bunged me a copy of his new book to review (after I’ve reviewed PPK on JavaScript and Matthew Eernisse’s Ajax book ..)
Also see Mike Davis’ detailed notes.
Microformats
One of the questions in the QA was a guy asking about the default behaviour of a screenreader when it encounters an abbr in a microformat. He seemed very relieved when Steve confirmed that it doesn’t expand the abbreviation.
I’m glad that our Web Standards Project article, hAccessibility is being read and thought about but no-one should feel relieved by this confirmation of JAWS’ default behaviour.
Just because the out-of-the-box setting is accessible shouldn’t lead to complacency. This is an assistive technology we’re talking about, and one of its options for extra accessibility is to expand abbreviatons, as recommended in WCAG 1.
In JAWS, you access this options from Utilities, Configuration Manager, HTML Options:
And thus, a power user gets extra help, unless you choose to break it by misusing the abbr element.
It’s like scrambling text if a user increases his font size, and saying it’s fine because the default settings were accessible.
Do you disbelieve that it breaks accessibility? Check out this Geo information, which is a shortened version from http://www.w3.org/People/Connolly/events/
which the microformats wiki links to as an example “in the wild”:
Let's go to <abbr class="geo" title="30.300474;-97.747247">Austin, TX</abbr>
With abbreviations expanded, it no longer says “Austin TX”, but instead it’s an incomprehensible string of numbers (mp3):
Thirty point three oh oh four seven four semi-colon minus ninety-seven point seven four seven two four seven
Is that accessible?
You didn’t come to the pub afterwards for a small shandy. Or perhaps a refreshing mineral water.