Aren’t Microformats Supposed To Be Accessible?

I have been working on a plugin for WordPress recently that involves the use of custom fields to store data on events and output them on your blog in the hCalendar microformat. I am a big fan of microformats, I look forward to being able to use a program to retrieve contact details, event details or other bits of information solely from a well marked up web page and that is why I wanted to contribute with a plugin that helps people use them.

I am also a big fan of accessibility on the Internet too, so try to imagine my surprise when I came across Bruce Lawson and James Craig’s article on the Web Standards Project about hCalendar’s inaccessible dates. Two movements on the web are now working against each other? Are we pushing in opposite directions and still trying to achieve the same result? Here’s my opinion.

Not As Bad As It Sounds

Alright, I am being a bit dramatic (I am still learning how to write to attract readers, welcome if you are new and the first two paragraphs have worked so far). James and Bruce’s article picked out one problem amongst a number of microformats that are intricately planned out in order to make it both easy to mark up data semantically and allow that information to be found and shared. So why am I writing this post? Not because I was surprised that there was a conflict, but because I was surprised that the hCalendar was set up to fall like this.

hCalendar’s Problem

hCalendar is used to mark up events, giving them a summary, a location, a start and end time/date and other useful bits of data. The date has turned out to be the issue in this case.

Why? Because the specification instructs that you use the <abbr> element to surround the date, giving it a title attribute of the ISO 8601 representation of the date. This causes a problem because, although the text of the date may well be an abbreviation of the full representation, the ISO standard, that same standard is meant for machines to read, not humans. When it comes to screen reading technology, the standards say that the title of the <abbr> should be read out, but the ISO dates are unrecognisable.

My Interpretation Of hCalendar

My surprise was born out of the need to use the <abbr> element for the date. As far as I was concerned, the title attribute of an element is used to give extra detail about the text contained in the element. In the case of a date, the machine standard is extra information and shouldn’t be necessary for humans to read.

As I started to work with the hCalendar, I found myself using a <span> with the ISO date in the title attribute without even thinking. This is one of the proposed solutions from the article. It saves an unnecessary empty element as suggested in the last proposal, it saves using the buggy (in Internet Explorer and Safari) <object> element and it saves using an extra <span> to fix those bugs. It seems ideal.

Conclusions

I am actually pretty lost now! This article has pointed out that my implementation of hCalendar was incorrect, but that maybe it should be the right way. Whatever happens the spec guides the consumers of this data as well as publishers, so it has to match up. But, I don’t want to compromise on accessibility by using the current spec (of which the datetime-design pattern even admits it fails the (not yet recommended) WCAG 2.0) either. I only hope that someone more qualified than me can invoke a solution to this. There has already been a lot of discussion over this and I hope that a conclusion is forthcoming. I will be watching and waiting, ready to release my correct and accessible plugin.

If you enjoyed this post, why not subscribe to Unintentionally Blank

Posted in Accessibility, Web Standards | Trackback | Leave a comment