Andy Mabbett reminded me that it’s been a year since James Craig and I published hAccessibility— a look at the accessibility problems inherent in some unsemantic design patterns used in some microformats.
The main problem is that the
title attribute of the
abbr element is misued to “hide” machine data, such as in this example.
<abbr class="dtstart" title="20070312T1700-06">
March 12, 2007 at 5 PM, Central Standard Time
For screenreader users who have elected to have their assistive technology expand abbreviations, the human date is replaced by the unintelligible string “Twenty million seventy-thousand three-hundred twelve tee seventeen-hundred dash zero six”, which makes it inaccessible.
We were accused of spreading fear and doubt, told we were wrong and we must prove our case to an openly hostile microformats crowd. The burden of proof was so great that we decided to have a life instead.
Mike “Isolani” Davis resurrected the issue this weekend. He takes issue with the microformatters’ assertion that the scenario I describe above is not a problem because most screen reader users do not change their default settings.
I agree with Mike about this (although I don’t think Jeremy is the bad guy).
Mike writes “there are no published studies or investigations available that document how most screen reader users have their screen readers configured”. The only study I know of that comes close is a 2003 paper called Guidelines for Accessible and Usable Web Sites: Observing Users Who Work With Screen Readers by Theofanos and Redish, who write
Many users do not know or use all the features of the software. Given the mental load of browser, Web site, and assistive device, it should not be surprising that many of our participants did not know all the features of the screen reader software
Most of our JAWS participants regularly used the Links List (Insert-F7). A few regularly checked the Window Title to see what page they were on (Insert-T). Only a few used the Headings List (Insert-F6) or moved from heading to heading by pressing H inside a document. No one used the JAWS command, N, to skip links. No one jumped directly to a form on a page. Only one of our participants, a JAWS trainer, used the Virtual Viewer (Insert-F1), a JAWS feature that displays a description of a Web page, so that the user can immediately find out how many headers, tables, links, and other screen elements are on a page.
While this might be taken as supporting the idea that no-one really configures a screenreader (extrapolating from the conclusion that few even know the out-of-the-box features, let alone buried configurationm options), note that the paper also suggests “to make screen readers read an acronym or abbreviation as letters rather than attempting to read it as a word, use the <ACRONYM> and <ABBR> tags”, although doesn’t mention the expansion of abbreviations.
To be perfectly frank, I’m sick of the whole subject now. Even if it is unlikely that someone expands abbreviations (and I don’t believe it is unlikely), it is still very possible that someone using an assistive technology in the wild might want to expand an abbreviation, and hence find a microformat inaccessible.
Some in the microformats community want to find a way round this and work to make hCalendar and associated specs useful to all. I applaud those people. James, Patrick and I are working with those people.
Yet there are others who I know genuinely care about webstandards and semantics, and who would never dream of laying out a page with tables, and yet who are are nevertheless entirely happy to risk inaccessible content rather than amend their specifications to completely remove that risk.
Why? It’s genuinely baffling to me.