BBC Rejects hCalendar Microformat Because Of Accessibility Concerns

By James Edwards

The BBC have announced that they’ll be removing hCalendar microformats from their online programme listings, because of the accessibility issues with the ABBR design pattern.

To summarise the problem: some microformats use the title attribute of an <abbr> element to store ISO format dates, as machine-readable expansions of dates written in natural language, for example:

Meeting to be held on 
<abbr class="dtstart" title="1998-03-12T08:30:00-05:00">
	12 March 1998 from 8:30am EST

However this can have a serious impact on blind users who have their screenreader set to expand abbreviations, because what the screenreader says is essentially gibberish to the user. For example, Window Eyes at its maximum verbosity setting will say this:

Meeting to be held on one nine nine eight zero three one two T eight three zero zero zero zero zero five zero zero zero

This similarly impacts on users with a cognitive disability, who look at the data in a tooltip and are faced with equally incomprehensible information. A date is not an abbreviation, and an ISO formatted date is not an expansion; the ABBR design pattern is both conceptually and demonstrably broken, period.

Unfortunately, the microformats community have not been taking this issue seriously, despite considerable debate and alternatives being offered (albeit, less than perfect alternatives).

I’ve personally avoided weighing heavily into the debate, but I have kept abreast of it via the work that Bruce Lawson and James Craig have been doing at the Web Standards Project, trying to find and propose other design patterns; or at least to get the early-adopters within the microformats community to take the issue seriously enough to look for real alternatives, rather than dismissing the whole debate as chicken littling, or the screenreaders’ problem. One can only hope that this decision by such a high-profile organisation will re-invigorate the debate.

Personally, I think that microformats are a victim of their own simplicity. I’m all for making things as simple as possible, but not at the expense of accessibility — making developers’ lives easier at the expense of user experience is not acceptable.

I think that it was foolish to introduce a system like this which so clearly begs for namespaces, without using namespaces. A clearly namespaced microformat would have no possibility of conflicting with existing implementations, and is easily machine-readable without any chance of ambiguity. So in that sense, I’ll be rooting for RDFa as a better path to a more semantic web, in which human-readable and machine-readable data can co-exist in peace.

And to take a step back to a more general issue — perhaps, if it hadn’t been for Hixie’s iconic anti-XHTML missive (which, in my opinion, is wrong in every important respect) we might all be using XHTML now, and namespaced information would be trivial to introduce. It’s only because so many developers insist on sticking with HTML 4 that namespaces can’t be used, and why we have this problem in the first place.

  • Tyssen

    I think RDFa is probably the way forward too so am looking forward to the developments in that space.

  • AutisticCuckoo

    Lots of people agree with you that Hixie is wrong (he isn’t), and that is the main reason we’re not using XHTML today – and that we probably never will.

    Pretend-XHTML is just invalid HTML, and HTML doesn’t support namespaces. If, instead of using pretend-XHTML, authors had put pressure on browser vendors (one in particular, you know who) to support real XHTML, then we might have been able to use XML namespaces by now.

    Anyway, isn’t it a bit ironic that proponents of microformats (who claim to care about semantics) so blatantly disregard semantics in abusing abbr this way?

  • RyanR

    AutisticCuckoo is correct, faux XHTML (sent as text/html) is invalid HTML not XHTML. So a namespace would be useless.

    However people are free to use true XHTML as XML, but they don’t because IE can’t handle it (not to mention the error handling).

  • Stormrider

    “If, instead of using pretend-XHTML, authors had put pressure on browser vendors (one in particular, you know who) to support real XHTM”

    The whole point though is that maybe if more people did use ‘pretend XHTML’, it would cause the browser manufacturers to but proper XHTML support higher up on their priority list, so it isn’t entirely useless.

  • RyanR


    How would that help, you’re not using any XML features so the browser vendors would carry on as normal. If people used proper XHTML as XML then maybe that would have changed things, but due to IE and the excessive XML error handling people won’t go near proper XHTML.

  • AutisticCuckoo

    The whole point though is that maybe if more people did use ‘pretend XHTML’, it would cause the browser manufacturers to but proper XHTML support higher up on their priority list, so it isn’t entirely useless.

    Why would they? Pretend-XHTML doesn’t benefit from XHTML support, since it’s HTML.

    Just look at the millions of pretend-XHTML sites on the ‘Net today. They don’t seem to have swayed Microsoft into making an effort, have they?

    Now, if lots of important sites were to use real XHTML, thus barring IE users from access, that might provide an incentive for Mr Ballmer et al. But of course that’s not going to happen. Catch-22. Chicken and egg.

  • brothercake

    Agreed – pretend XHTML is just HTML, so no advantage over HTML. But real XHTML is XML, and can use namespaces.

    And it’s the same markup.

    It is worth using XHTML, even if it’s only error-handled HTML for some browsers, because for other browsers it can be used as XML.

    And even where it’s only HTML, namespaced information can still be set and extracted programatically (albeit in a mangled way); as a principle, that appears to be working nicely for ARIA, don’t see why it couldn’t work for UF too. And even if the bottom line is semantic information that IE can’t use, I still think that’s better than what’s happening now.

  • PatrickSamphire

    Excellent post. I’ve been frustrated about hCalendar over this issue for ages. I would love to use the hCalendar microformat, but not when it inconveniences some of my users. That the microformat community hasn’t bothered to deal with this serious issue that has been known for a long time is undermining what is basically a fantastic idea.

Because We Like You
Free Ebooks!

Grab SitePoint's top 10 web dev and design ebooks, completely free!

Get the latest in Front-end, once a week, for free.