microformatique - a blog about microformats and “data at the edges”

Sadly, NetNewsWire, the excellent Mac (and now iPhone) RSS feed reader, which implemented microformats support with version 3 last year, has now removed these for the upcoming 3.2. Well see if they return as microformats become increasingly popular (but I wonder how many folks were putting microformats in their RSS and Atom?)

Tom Taylor has a very cool little Google Maps based geo microformats maker. Just drag a pin to create the code.

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.

2007-02-06T13:45-07:00

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.

Want to get up to speed with microformats and RDFa quickly? Then head over to Digital Bazaar, and check out these video casts by Manu Sporny on “practical web semantics”.

As mentioned a few weeks back, in a couple of weeks I’ll be speaking in Tokyo at a number of events.

I’ll be doing two microformats related presentations, as well as a CSS 3 and experimental CSS presentation.

First up, on June 13, I’ll be speaking at this vent at Mitsue-Links. It’s free, but places are limited, and it will be conducted in a combination of Japanese, and English (which will be translated into Japanese). It’s to help celebrate the launch of my microformats book in Japanese!

Then, on June 14th, I’ll be speaking at the Apple Store in Ginza, on the experimental CSS you can find in Opera, Mozilla, and of course Safari/Webkit, as well as some aspects of CSS3 which are starting to get more widespread adoption. I’ll also be showing off an unreleased version of Style Master 5, which has support for a lot of these features of CSS. “CSS Reloaded” is from 6.30pm to 8.00pm, and free, though places are limited to get there a bit early. It will be in english, but very visual and code oriented, so hopefully very intelligible to those with CSS knowledge.

Finally, the big event is on Saturday June 16th, “SwapSkills for the Happy Web Weekend” (no, I’m not 100% sure what it means either but it is going to rock!)

It’s a one day mini-conference, where I’ll be speaking both on microformats, and on “the web beyond the desktop”. Also on the bill is Michael Smith from the W3C in Japan, who has enourmous experience with mobile applications and the web on mobile platforms. This runs all day, and costs just ¥12,000.

I look forward to meeting up with any readers out there. Also, feel free to leave advice about the most important etiquette issues for me as a non Japanese person, and suggestions of the types of Japanese words and phrases that would be most helpful while there.