June 25, 2008

hCalendar annoyances

Writing about web page http://www.bbc.co.uk/blogs/radiolabs/2008/06/removing_microformats_from_bbc.shtml

The BBC have announced that they’re going to stop using the hCalendar microformat in their markup, because of accessibility issues with the way that hCal uses the <abbr> HTML element.

Back up a minute. The what now?

hCalendar is a microformat; a way of embedding machine-readable data into HTML with a minimum of fuss.

So, I might start with a bit of HTML like this:

<div> 
<h2>Exciting Meeting</h2>
<span> July 12th, 10am-11am</span>
<span> Meeting room 3</span>
</div>

... and then I add a little bit of extra markup, which doesn’t affect the display of the element*, but just adds some supplementary information

* ahem. As we’ll see later.

<div class="vevent"> 
<h2 class="summary">Exciting Meeting</h2>
<span><abbr class="dtstart" title="2008-07-12T10:00:00+01:00"> July 12th, 10am</abbr>-<abbr class="dtstart" title="2008-07-12T11:00:00+01:00">11am</abbr></span>
<span class="location" > Meeting room 3</span>
</div>

Now, I’ve got something which can be machine-read and unambiguously converted into an event. There’s a nice little Firefox plugin called operator which can spot this kind of markup and offer to add it to google calendar (or other calendars). There are similar microformats for contact information, reviews, licenses, and a bunch of other stuff.

Now, this is exactly the kind of low-ceremony, small-s-semantic-web technology that I like. It’s easy to get into, and you can bung it onto all of your pages. It’s easy to consume; you can write parsers for it in a few lines of code. It doesn’t really matter if only a few people use it, because there’s almost no cost to implementing it.

Except…

The use of the <abbr> element to hold machine-readable dates is contentious, to say the least. It’s technically correct (or at least arguable) to say that “11am” is an abbreviation of “2008-07-12T11:00:00+01:00”, but there are two downsides; one big and one small.

The small downside is that most browsers will render the title attribute as a pop-up when you hover over the abbr . Since the content of the title is pretty much gibberish to your average user, this is unhelpful.
A much bigger deal, though, is that many screen readers will read out the title as a big string of numbers. Here’s the market leader, JAWS, on IE7 reading the markup

<abbr class="dtstart" title="20070312T1700-06">
 March 12, 2007 at 5 PM, Central Standard Time
</abbr>

(taken from hAccessibility )

- and this, AIUI, is what has driven the BBC away from hCalendar. Embedding hCal might be beneficial for the small number of users that have Operator installed, but for anyone using JAWS it’s a massive inconvenience.

Now, we use hCalendar ourselves; if you go to a Sitebuilder Calendar page (like this one) and choose “Agenda view” from the little drop-down on the RHS, you’ll see Operator spring into life and spot all the events.

“Why do I have to choose ‘Agenda View?’” I hear you ask – and this exposes another quirk of hCalendar. hCalendar is supposed to add markup to visible content, and since our grid-based calendars don’t display the date of an event (dur, that’s what the grid’s for) there’s not enough markup for Operator to latch onto. Annoyingly, there is complete hCalendar markup for each event in the page’s HTML, but it’s hidden (set to display:none) and only shows as a pop-up. Operator, by default, ignores non-visible markup, and isn’t smart enough to re-parse when it becomes visible. (There’s a preference setting to display hidden events, but it’s off by default).

So, I’m now asking myself: should we consider dropping our hCalendar support? I view the BBC’s web standards as a good measure of pragmatism vs. idealism, and since we’re both kind of in the same space (we’re both non-profit-making institutions, supposedly acting for the benefit of all), I generally hold that what’s good for them is good for us too. I’ve never had a complaint from a JAWS user that they couldn’t use our calendars, but then I’ve never had feedback from an Operator user that they loved our embedded hCal either. I personally find it very useful, but then if I designed all our systems only to meet my needs, they’d be rather different (and I’d be looking for a job…)

Hopefully, the microformats community will work out a suitable solution. This problem has been known about for well over a year now, and largely ignored, but perhaps the BBC’s stance will prove to be enough to bring about an improvement. If not, I fear that until HTML5 and the <time> element become widespread, hCalendar is not going to gain much acceptance :-(


- 2 comments by 1 or more people Not publicly viewable

  1. Andrew Ingram

    What I would do instead of putting the standard XML date representation in the title attribute:
    Dates have a standardised format for each country (I hope. I’d also hope there’s not a unique format for each country), so you can just put the date in that format along with the ISO country code for the format and you have given the machine parser enough information to work out the machiney version and keep the actual text JAWS-friendly.

    The other option is to put the burden on JAWS (and other browsers) itself. Consider the difference in date formatting between US and UK and that a lot of places that show date only show the numbers, there’s already an accessibility issue caused by page authors not being specific enough about the date (and not just for blind people), maybe the xml date formatting could be a standard attribute you can put in (lets say) a date tag so you can wrap the display format of any date/time with the full xml information. The browser would then be required to interpret this information and display it on hover/speech based on the browser’s locale setting.

    So, regardless of how a date is formatted on the page, I should be able to hover over it or read it through JAWS and have it conveyed to be clearly what the actual date is in terms meaningful to me.

    25 Jun 2008, 18:54

  2. Chris May

    When you say “standard XML date representation ” you mean ISO-8601 formatted date, right?
    I’m not so sure that dates have a standardised format per ISO country code. Canada, for instance, switches between French-style dd/mm/yy and American mm/dd/yy. Wikipedia has more info.

    I think that getting the browsers/screen-readers to do a bit more of the work is a laudable goal, but I speculate that it’s not going to happen any time soon; I reckon that the HTML5 [time] element will be here first.

    25 Jun 2008, 19:22


Add a comment

You are not allowed to comment on this entry as it has restricted commenting permissions.

Most recent entries

Loading…

Search this blog

on twitter...


    Tags

    Not signed in
    Sign in

    Powered by BlogBuilder
    © MMXXI