Skip to content

BBC drops hCalendar for programme listings, citing accessibility concerns

The BBC has long been one of the most innovative large scale adopters of microformats, so it is a little sad to see that they are no longer serving up their programme listings using the hCalendar format. Their concern is around the accessibility of one aspect of the format, the abbr design pattern.

What’s the problem?

In a nutshell, the problem is as follows.

With the hCalendar format we need to be able to embed the unambiguous date/time data for an event in our HTML, along with the humanly friendly version. There is an ISO date/time standard, 8601. So, it makes sense to use it. But ISO 8601 date/times look like this.


Which is not very humanly friendly.

Tuesday Feb. 6th, or tomorrow at 1.45 are the kind of things we humans like to read. So, how can we reconcile the two? The ABBR design patter is an attempt to do this.

The abbr design pattern observes that in a sense, “tomorrow at 1.45″ is an abbreviation for “2007-02-06T13:45-07:00″, and HTML has the <abbr> element for abbrevations. So why don’t we use the following construct.

<abbr> title =”2007-02-06T13:45-07:00″;Tomorrow t 1.45</abbr>

It’s valid HTML. It cleverly falls within the definition of the abbr element, and so looks to be an abstruse, but acceptable use of HTML to embed the machine readable expansion of the humanly readable date.

Now some folks argue that this is too clever by half – that the ISO date/time for a date is not the expansion of an abbreviation. My response to that argument is we are entering the realm of the theological at this point – HTML is a pretty impoverished language when it comes to semantics, and this is at least a defensible use of the language, so let’s not quibble.

But, there is a practical problem, which is what prompted the BBC to stop using hCalendar fo rtheir listings. In some versions of some screen readers, there is an option (as far as I’m aware off by default) to enable the screen reader to read out the value of the title attribute of abbreviation elements.
I’ve no doubt that this is a genuine problem for some users of these screen readers (though in absolute terms I suspect the number of such users is by comparison even with folks familiar with microformats very small). But, I’d personally place this in the annoyances category – I doubt this makes such pages inaccessible, rather somewhat more annoying than some pages to use with a screen reader.

There’s also a secondary usability problem according to the BBC’s research, which from what I can glean, indicates that people are confused when then title of the abbe element appears as a tooltip in some browsers when the user moves their mouse over the element.

I’m not doubting that these are issues, and respect the BBC’s decision to do what they feel, with al the evidence at their disposal, to be the best thing by their users. But, I think the broader context needs to be considered as well, particularly when others come to making the same decision. While this might make sense for the BBC, does it generalize into the rule that one should not use the abbr design pattern, or hCalendars? Here are my thoughts on the issue.

If the use of the abbr design pattern made content inaccessible, even for a small number of users, in real world contexts. I’d say that’s the end of the matter. But, I’m not sure that this is the case. It seems that a small percentage of advanced users of a subset of screen readers have an annoying (admittedly it would seem very annoying) experience when using pages that use the abbr design pattern for date/time data. So, the question is, when it comes to you making a decision about your use of hCalendar in your sites, are the benefits conveyed outweighed by this usability concern (and the related tooltip usability concern for sighted users)?

What are the benefits exactly?

By adding a single link to your page, and using the X2V service, you can make the calendar content of that page downloadable as an iCal file, which can easily be added to a users desktop calendar app. Some of these apps even enable users to subscribe to a calendar at a URL, and synchronize the local calendar to the online one.
Users of the Firefox extension Operator can easily add events from the calendar to their desktop, Yahoo!, Google and other calendars, with no absolutely no effort on your part other than using hCalendar.
Yahoo! SearchMonkey now indexes hCalendar format, giving you potential SEO benefits down the track, as third party developers start building search applications on top of SearchMonkey.

Beyond this, there are a couple of issues.This will no doubt reopen, and then hopefully resolve debates about alternatives to the abbr pattern, which have been going on for over a year. I wonder whether that might have been in part behind BBC’s very public decision and rationale for it.
But the bigger issue, which I’ve addressed in previously articles and am currently in the process of writing a major article on is that this is a clear example we have pushed HTML beyond its capacity to enable the embedding of rich semantics in web documents. We will increasingly run into such problems as the small number of attributes and elements in the language are used for different purposes. In this case we have a conflict between using the abbr element for accessibility, and for embedding semantics. This will happen increasingly as we strive to enrich the semantics of the web using HTML as it stands. We are building bridges with lego bricks.

I’ll return the this issue in detail soon, in the promised article. In the meantime, I hope that simply because the BBC decided, probably rightly in their case, that hCalendar involves unacceptable usablity and accessibility tradeoffs, that people simple abandon it in droves. The situation is much more nuanced than that.

{ 12 } Comments

  1. Simon | June 25, 2008 at 6:12 am | Permalink

    Interesting. I’ve always had my doubts about the ABBR design pattern; it always seemed like somewhat of a hack (even moreso than other microformats). The title of an abbreviation is supposed to be an expansion; the date/time version isn’t, it’s almost less information; at best, just an alternative representation.

    I’ve never really understood what the point of making technically valid (as in passes a validator) HTML when it no longer really embraces the point of the language. The framework (SGML or XML depending on your version of HTML) provides a means to supply extra attributes (and tags). Browsers can deal with them appropriately (as in, ignore them).

    The datetime thing should have been implemented as an extra (new) attribute (and probably tag), not a hack of an old one. It wouldn’t be valid HTML anymore. But does that matter, really? Is it worth it over the corruption of the point of the language?

    Maybe it would encourage somebody to make a validator that allows for these exceptions, and then possibly the HTML standard might improve.

  2. john | June 25, 2008 at 6:27 pm | Permalink

    Hi Simon,

    in one sense, microformats are a hack – but hacks aren’t always a bad thing. They are a structured attempt to solve an important problem with the web of HTML, within the constraints of maintaining backwards, and forwards compatibility, using entirely valid current HTML.

    I think that at least a decent argument can be made that the ISO date time is the expansion of the human friendly version – it’s not simply alternate data, it’s a more detailed, exact version. Yes, it might be stretching matters, but it certainly adheres to the standard more closely than for example using the title attribute of a span element.

    Your suggestion of a new element or attribute is orthogonal to the issue – that is a future direction for the HTML language, not a solution today to the problem. That’s not what microformats are trying to do. But I agree, and that is the subject of my fuller article, as well as this series of detailed articles from about a year ago


  3. Isofarro | June 29, 2008 at 8:53 pm | Permalink

    “In some versions of some screen readers”

    That would be current versions as well as the previous version of both JAWS (from Freedom Scientific) and Window Eyes (from GW Micro). In usage terms, JAWS and Windows Eyes together are the totally dominant screen readers in the USA. In the UK, there is a ‘Opera-like slice’ of the market using Dolphin’s Supernova/Hal.

    “there is an option (as far as I’m aware off by default) to enable the screen reader to read out the value of the title attribute of abbreviation elements.”

    Why would people want to enable such an option? What circumstances could enabling it:

    1.) be possibly useful;
    2.) be of no use;
    3.) be a hinderance?

    Please give these two questions some serious thought and consideration. After that, maybe the rest of this comment may make more sense.

    “I’ve no doubt that this is a genuine problem for some users of these screen readers (though in absolute terms I suspect the number of such users is by comparison even with folks familiar with microformats very small).”

    Many countries in today’s world have legislation that protects minority groups, particularly from a majority group (natural or artificial) trodding over the rights of that minority. It’s part and parcel of guaranteeing the inalienable rights of all people to participate in society as equals.

    People with disabilities are one such minority group, and a group that has been marginalised purely because they are disabled. Legislation in the modern world helps protect their rights, and hopefully prevents the majority from just locking them out of society.

    Minorities have rights too, no matter how small a group they are, whether they are vocal or not – as long as they are legitimate members of our human-based society, they have rights, especially the right to participate as equals within society (both online and offline).

    “But, I’d personally place this in the annoyances category – I doubt this makes such pages inaccessible, rather somewhat more annoying than some pages to use with a screen reader.”

    The types of barriers that are created by a full ISO-timestamp are:

    1.) A sequence of numbers with no obvious clue as to how they should be interpreted.
    2.) The heuristics of a screen reader that identify certain data segments as formatted data.

    The more obvious problem of the two, the first one, is debatable whether its just an annoyance. The one point I will make on that note is this:

    Surely the expansion of an abbreviation should introduce more clarity, rather than less? If an abbreviation expansion hinders understandability, surely it’s better off semantically from not marking it up as an abbreviation in the first place? Otherwise, what’s the point?

    On the second scenario: In your example, the timezone segment is picked up at least two newish versions of JAWS as a time, so they read out something like ‘seven o’clock’.

    If the actual event time is 1:45pm, then hearing “seven o’clock” being read out could confuse people into believing the event starts at seven o’clock.

    To me this particular case isn’t just an ‘annoyance’, it’s offering up information in a confusable way, and in a way where the user can get the wrong information.

    This is the same problem as someone who marks up the text ‘BBC’ as an abbreviation and uses “Associated Press” as the title attribute of that abbreviation. Yes, it might annoy some people, but the overriding problem is that the expanded information is incorrect.

    Considering that the main configuration of expanding abbreviations is going to be to replace the abbreviation with the full expansion, most of the time, people are going to believe the expanded text that’s read out to them.

    Sure, I take the point that in the case of the abbr datetime pattern, that the best user experience is when abbreviations are not expanded.

    But, consider what that step actually means. Isn’t one of the bastions of microformats the desire to squeeze out as much benefit from structured and semantic markup? What’s the point of implementing microformats if the recommendation is for end-users not to benefit from it?

  4. Patrick H. Lauke | June 29, 2008 at 9:16 pm | Permalink

    Looking over the microformats’ principles and definitions, microformats should be “adapted to current behaviors and usage patterns” and “design[ed] for humans first, machines second”. Now, current user agent behaviour, in the presence of an ABBR element with a title attribute, is to expose that title attribute to the end user (either as tooltip, read out – if the option is enabled -, etc). Current user agents assume – because of the prevailing usage (cowpath?) – that the title information, as it is present in the markup, is human-readable information. So, it seems incongruous to squirt data in a machine-readable format (and please, no strawman arguments about “full ISO dates are actually *more* human readable”…if that were the case, we’d all be using full ISO in everyday communication, which we clearly don’t – and let’s not get started with geo microformats that use ABBR to put long/lat data as “abbreviation” for human-readable place names like “Manchester, UK”) into this attribute…incongruous, and apparently in violation of the ideas that the microformats community holds has enshrined in its mission statement.

    The other strawman here is the “but look at the benefits” part. Are you suggesting that these benefits are intrinsically tied to the (ab)use of the ABBR pattern’s use for date/time and things like geo coordinates? If an alternative solution was officially adopted, the ABBR pattern uses mentioned deprecated, and the handful of microformats-consuming tools updated, would those benefits be impossible to achieve?

    The idea of microformats, and the usability (and “usefulness”) improvements they can bring to users is not being disputed here.

    In fact, I can see how microformats, coupled with the right tools, can improve usability *particularly* for users with disabilities – instead of having to work their way through a page, or trying to understand some of the complex information presented, they can be given very clear and simple options (as you mention, adding things to their calendars etc).

    You seem to be making a clear distinction between *usability* and *accessibility*. I’d say that modern definitions of accessibility *encompass* usability, and that in fact accessibility is all about making web resources *usable* for all. Otherwise, we’re simply talking “technical accessibility”.

  5. john | June 29, 2008 at 9:18 pm | Permalink


    Thanks for the reasoned and detailed reply – that was precisely why I wrote this longish article – because right now there is a distinct lack of either in a lot of the discussion around this issue.

    Now, none of this article is to say we have the perfect solution to the problem in the abbr design pattern. My argument is that the BBC’s decision is no “lay down misere”. The argument is that the abbr design pattern (and often generalized to microformats) is inaccessibility. My point is that it is far more subtle than that, and that any decision made in the absence of understanding these subtleties is a poor decision. Now. I’m not arguing that the BBC made this decision in the absence of such understanding, but many other folks I’ve read abut this issue do lack those understandings.

    Additionally , my track record in supporting accessibility is pretty high – I am very aware of the practical, legal and ethical aspects of accessibility, and have worked for nearly a decade to have developers make accessibility a priority for their sites. My purpose was by no means to belittle or undermine the issues, but to question some of the extreme claims and observations some folks have made, and provide some nuance to the issue.

    The observation of “some versions of some screen readers” still stands. While the two readers you cite are highly dominant in market share, is that true of the versions of these readers with this particular feature as used widely? As far as I am aware, upgrading versions of screen readers is a lot less common than upgrading browsers, due to the significant cost of screen reader software. I’m happy to be proven wrong on this.

    I have no objection to folks turning on this option – I observe that it is turned off by default (as far as I am aware) – so we are starting to see a use base of a subset of the screen reader base (later versions of popular screen readers) and then folks using these who turn on a very specific feature.

    My central point here is the question – is this actually an accessibility, or is it a usability issue? I contend that it might best be characterised as a usability issue for folks using screen readers. To me, the threshold of accessibility versus usability is – is it not possible to access the information or services provided by a page by reasonable means. I guess this debate then comes down to whether listening to the ISO date time string is unreasonably annoying – afterall, for sighted and unsighted folks, there are many annoyances on the web. We make those tradeoffs all the time.

    The point around misread information and timezones is a far more compelling one – indeed, if it is misread, then that is a big accessibility issue. I’d need to take some time to see where the error is taking place – with the markup, or with the reader making an assumption.

    Thanks for help clarify the issue further. Aboveall, the value in this discussion is to help ensure the next generation of solutions to these problems learn from the the lessons that episodes like these teach us.


  6. john | June 29, 2008 at 9:27 pm | Permalink


    I think the tooltip use pattern you observe is a particularly strong observation. It predates the use of ABBR in this way, by possibly a decade in some cases, and is widely used.

    My response to the issue of the use or misuse of abbr argument is that it’s essentially a theological argument akin to the dancing of angles on the heads of pins. HTML is highly impoverished when it comes to semantic expressiveness, and we have needed to mine it for all its worth. To me this is simply not a particularly interesting question (the accessibility stuff is of course, just this part I find kinda pointless).

    I’m not particularly wedded to ABBR at all – that’s not been my point in this post and related comments. Rather, to address the issues around the issue in more clarity than some (but not all) have (both among the microformats community, and the critics of the pattern inside and less inside that community).

    My very personal, with no evidence at all, reading of the situation is this is an attempt by the BBC, or some folks there, to have what has seemed to be a stalemated issue addressed. And it appears to have worked. Now, let’s try and learn as much from the experience as possible ;-)


  7. Isofarro | June 30, 2008 at 2:27 am | Permalink

    John, thanks for the very constructive reply.

    “My central point here is the question – is this actually an accessibility, or is it a usability issue? I contend that it might best be characterised as a usability issue for folks using screen readers.”

    I think about accessibility, and the more I do, the more times I see parallels with usability. So I’d raise the question of whether this particular issue has to be one or the other – can it not be both?

    I’m particularly fond of the 4 principles of accessibility as outlined in the WCAG 2.0 document, which describes accessible content that is:

    1.) Perceivable
    2.) Operable
    3.) Understandable
    4.) Robust

    to people with disabilities. For the abbr date-time pattern, it is peceivable, it is operable (due to the fact that there’s nothing to operate), and it is robust (so people can work their way around it if it presents a problem).

    However, on the principle of understandable, there are issues like the two I’ve outlined in the previous comment. I think by these principles, the abbr datetime pattern can be classified as an accessibility issue, because it presents a problem of understandability of the content.

    I accept that WCAG 2.0 is just a Candidate Recommendation, and not yet a full recommendation. But it does better specify and outline the issues of accessibility far better and more accurately than WCAG 1.0. And in a few months, this will be a fully-fledged recommendation.

    So my answer is that this is most definitely an accessibility issue. Whether that’s a usability problem too, I don’t know. I suspect it might be, but that is just my opinion.

  8. Andy Mabbett | June 30, 2008 at 9:27 am | Permalink

    The BBC’s immediate concerns aside, this issue is not just about the datetime pattern, but all of microformat abuses of abbr; such as this example from hAudio (meaning 5 minutes and 48 seconds):

    [abbr class="duration" title="PT5M48S"]5:48[/abbr]

    or this method of marking up “”type” properties named English (in this case, “work”), in non-English pages (in this case, French):

    [div class="tel"]
    [abbr class="type" title="work"]Travail[/abbr] :
    [span class="value"]0321596224[/span]

    In fact, it’s not even just about that; the real problem is the apparent attitude of most, if not all, of the small number of people who run the microformats “community”, to both accessibility and internationalisation.

    The BBC case is just the tip of the iceberg.

  9. Andy Mabbett | June 30, 2008 at 9:42 am | Permalink

    I almost forgot this example:

    [abbr class="dtend" title="2009-01-01"]31 December 2008[/abbr]

    Is anyone prepared to defend that as accessible, or usable, or even sane?

    I first raised that issue on or before 20 January 2007, and proposed a simple resolution (albeit still using ABBR, at that point) in March of that year:

    So far, nothing further has been done.

  10. john | June 30, 2008 at 11:20 pm | Permalink


    agreed, issues around i8n and usability and accessibility do need addressing. I think the only robust, long term solutions will come with future iterations of HTML. I have some thoughts on that to be published shortly (if I find time to finish the article). In the meantime, we really have pushed HTML far past its designed capabilities – so these kinds of issues will show up increasingly commonly.


  11. Simon | July 1, 2008 at 6:22 am | Permalink

    Sorry for writing a comment on your article then not coming back — I thought there’d be an email or something for replies…

    I guess I agree with your points; hacks aren’t always bad, and it _could_ be argued that it isn’t misuse of the ABBR/title thing. (Although I do think it definitely is stretching things.)

    I do think, however, that inserting stuff designed for machines in tags or attributes designed for humans is a bad idea. The stuff that overloads the class attribute is okay because no-one is meant to read that. The title attribute is clearly intended to be human readable.

    I guess there’s just a wider issue of: why is it _that_ important to have valid HTML; perhaps if the microformats standards proposed breaking the HTML standard in a controlled and minimal way, that would be better for everyone. All that’s really needed here is to use a different attribute — preferably one that doesn’t already have a meaning.

    Then microformats wouldn’t be intruding, and people would still be happy. Adhering to standards that are holding back progress isn’t really useful for anyone, especially if the new bits don’t interfere with the old bits at all.

  12. Jordan Gray | July 8, 2008 at 6:49 pm | Permalink

    I strongly disagree that the <abbr> design pattern is merely an “annoyance” to screenreader users, John.

    The title for an event I’m attending tomorrow is “2008-07-08T9:00Z00″; normal users will read simply “9 a.m.,” but Windows Eyes users with maximum verbosity set will hear “two-zero-zero-eight-zero-seven-zero-eight-tee-nine-zero-zero-zee-zero-zero.” Most people don’t know the ISO date format, so I’d be very surprised if many blind users, hearing that read out, conclude: “Oh, so the rehearsal is tomorrow at nine!”

{ 1 } Trackback

  1. [...] BBC drops hCalendar for programme listings, citing accessibility concerns [...]

Post a Comment

Your email is never published nor shared. Required fields are marked *