Jeremy Keith erupted into a hissy fit during the panel session of AbilityNet's Accessibility 2.0 conference yesterday. His venting revolved around earlier accessibility criticism of the microformat's adoption of the abbr element as a way of attaching machine-readable dates to written dates, for example in the calendar microformat.
Unfortunately, Jeremy dodged the real accessibility issues of the date-time microformat pattern, instead preferring to create a strawman, and boisterously batter it to smithereens with his wooden sword. That is his choice, but it doesn't help to alleviate the accessibility issues of the date-time microformat pattern.
Twitter and ISO-8601 date-times
In a brilliantly informative talk about Twitter and ARIA, Steve Faulkner of The Paciello Group, took the audience through the various features of Twitter that posed accessibility issues in screen readers. Each barrier was explained in detail, solutions using current technology discussed and implemented, and suprisingly, demonstrating practical solutions using ARIA.
One accessibility barrier Steve covered was Twitter's use of the abbr to add machine-readable ISO-8601 timestamps, which is decently summarised in W3C's Date and Time Note. Marking up the publish times of twitter messages as an abbreviation meant that screenreader users with configurations set to expand abbreviations instead of getting a human friendly date, they received something that wasn't human friendly. This is what was in the markup:
<abbr class="published"
title="2008-04-26T06:52:20+01:00">
half a minute</abbr>
Instead of getting the human friendly message of half a minute
, a screen reader user with expanded abbreviations configured would get something like two thousand and eight dash zero four dash twenty six tee six colon fifty two colon twenty plus one o'clock
. Not a particularly friendly or intuitive expansion. In fact, it is materially incorrect. The time stated is 06:52, not one o'clock.
Jeremy took issue with Steve's criticisms in his blog, accusing Steve, amongst other things, of FUD. What Jeremy fails to realise is that Steve Faulkner has a long track-record of basing his findings on thorough screen reader testing. And Steve knows screen readers. Much of what we know about making Ajax accessible to screen-reader users comes from the work of Steve Faulkner and Gez Lemon, in their trademark style of collaborative deep thinking, designing and implementing their ideas, and rigorously testing their ideas, and documenting their findings, and publishing them openly for peer-review. Hardly the foundation of fear, uncertainty and doubt.
Testing with screen reader users
The litmus test of accessibility is usability testing with people with disabilities. As it happens, some usability testing was done on the date-time pattern, as Jeremy Keith notes:
By the way, Robin [Christopherson] - 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.
It is encouraging that accessibility testing was done, kudos to the BBC. However the conclusion drawn is flawed. I'm very surprised the Microformats community accepted the justification as Jeremy describes it:
Most screen reader users do not change their default settings for abbreviations and by default, abbreviations are not expanded.
There are two issues with this justification:
First, to my knowledge, there are no published studies or investigations available that document how most screen reader users have their screen readers configured. That's something we in the accessibility circles wish we had access to, but not have the resources to fund such a study. If the Microformats community have this information, I urge them to share it publicly.
What strikes me as very odd is that three screen reader users I have worked with over the last few years have all got abbreviations configured to be expanded. Do we just ignore that as a statistical anomaly or insignificant?
Second, there's no indication from Jeremy's comments that the microformats community asked the pertinent question, Why don't most users have their screen readers configured to expand abbreviations?
(Surely the semantics of a properly marked up abbreviation offer value to a visitor?)
One major part of the reason is the lack of properly structured markup out on the real web. Screen reader users find very little benefit to having the configuration switched on because the reading of most pages is no noticeable improvement because there's hardly any abbreviations on the pages to actually expand. Why have a configuration turned on that adds practically no value?
Marking up abbreviations is part and parcel of building semantically structured documents. It is something espoused by microformats, especially Jeremy Keith, who takes special delight in semantic structure. It's ironic, then, that the justification for the date-time pattern as not being a barrier to screen reader users largely depends on screen reader users retaining the belief that there is no value in semantic markup, and thus it's not worthwhile for them to set their screen readers to expand abbreviations.
In short, the microformats community is doing itself, as well as screen reader users, a disservice by validating the predominant view that semantic structure has no value. If structured and semantic markup has no value, neither does microformats.
Readability of ISO-8601 timestamps
Jeremy goes on to claim that ISO-8601 timestamps are readable:
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.
Jeremy ignores Steve's actual example, and is actually being deceitful. He finds 2008-04-25
readable, but says nothing about the readability of 2008-04-25T17:33:52+01:00
. It is true that both sequences are valid ISO-8601 date-times. But it was the second, longer form of the date-time that Steve Faulkner raised as an issue - one that Jeremy quietly ignores (maybe hoping it will go away?). Jeremy plays the strawman argument, arguing that a shortened date format is readable, but ignoring Steve's actual example which is being used on Twitter.
The first form, that Jeremy prefers is only of use for all-day or multi-day events, not the events predominant of calendars (hour-long meetings), or publish times on Twitter. Its the second, longer, form that's going to be more common, and this is no "semantic in nature" problem, it is a barrier for screen reader users who have expanded abbreviations configured.
This is a poor show from Jeremy Keith. I hope its not reflective of the rest of the Microformats community.
Panel criticisms
Furthermore, Jeremy criticises me for not being specific about which microformats, and claims the issue I have is with the date-time abbreviation pattern. This is incorrect and misleading. I directly pointed out the initial handling of the empty link include pattern as an example of where accessibility hadn't really been thought through.
Jeremy then chides that I should practice what I preach, which means he is unaware of the screen reader testing I did to test the empty link include pattern, which was fed back to the Microformats community. My work is referenced and acknowledged in the include pattern microformat wiki page. The testing involved two full-time screen reader users, a set of repeatable tests, and an internal peer review of my findings and conclusions. Also, none of the findings and conclusions have been effectively challenged or refuted. I stand by my work.
The third criticism, a re-iteration of the strawman argument that Jeremy finds 2008-04-25
readable, still doesn't mention whether the typical date-time format that is most likely to be used is readable. Screen reader testing and documentation by Steve Faulkner (in his presentation) and Jon Gibbins has demonstrated there is an issue when screen readers have expand abbreviations configured. Both quote test examples involving the most typical date-time format.
The argument that most screenreaders don't have abbreviations set to expanded, and thus a human-unfriendly title attribute on an abbr is acceptable betrays microformats' commitment to semantic and structured data. What possible value is there to promoting semantic markup if the net result is that the perceivability and usability of a semantic feature (the expansion of abbreviations) is seriously degraded because of the presence of human unfriendly blob of data? The date-time pattern is, in its current state, a barrier to screen reader users taking advantage of the abbreviation expansion features of their software.
Essentially, Jeremy Keith's credibility in accessibility has taken a serious knock. The outburst in the panel discussion did not help alleviate the documented problems about the date-time abbreviation format, or show a willingness to tackle the issues raised. And this is a concern.
Update 15:19 Jeremy Keith says that he got upset he was hearing "Microformats are inaccessible". I didn't say that on the panel, and I don't recall Steve Faulkner saying that in his presentation.
]]>
