ABBR pattern accessibility

microformats logo.I'd been meaning to post on the microformat-accessibility issue, but Patrick Lauke just posted a great sumary. As a sort of +1, I'd just like to share what I would prefer as an accessibility aware developer.

I've been using the hcal microformat for almost as long as it's been around on the UKWA events pages, I even added it to the examples in the wild page. I just mean to point out that this is not an academic issue for me, I use it already.

I started with the recommended abbr pattern, but I've since moved to using span, for example:

<span class="dtstart" title="20080705">
   Jul 5</span>

This doesn't actually get around all the issues, but in element-meaning terms, the span is not something that access technologies would need to read out the title of, but abbr definitely is. (It still doesn't get around the mouse-over issue, but I don't see a current solution to that, yet.)

Interestingly, the class has been proposed as a way of hiding the parsable data, for example:

<span class="dtstart data-20051010T10:10:10-0100">
   10 o'clock on the 10th</span>

This does not appear to have been embraced:

-1 Tantek. I'm vehemently opposed to putting data in the class attribute. We must find better alternatives. We must not go down the path of invisible (dark) (meta)data - IMHO that principle is inviolable for microformats.

I agree (with a point further up that page) that loading the class attribute is not a common method for this, although I can't see how that is different from using the title attribute for machine parsable data, especially on an element aimed at people.

Tantek points to the principles, which include: design for humans first, machines second... be presentable and parsable, so I don't really understand how this fits (or doesn't) fit those principles. The data is (and should be) hidden from people browsing, but should be parsable by their user-agent.

I don't see a current "best" solution. It has been circling for a year, and no-one has come up with anything that all are happy with. On a personal site I would rather use something from HTML5 that isn't valid yet, for example:

<span class="dtstart" data-date="20080705">
   Jul 5</span>

Using an attribute (rather than an element as Lachlan Hunt suggested), feels like it would be less likely to cause compatibility issues in user agents, although I'm happy to be corrected on this.

The actual downside at the moment is that it wouldn't be supported by anything that people would use to parse microformats.

Unfortunately I don't have an answer, loading the class does get around the accessibility issues, but would have to be updated in parsers. Using a span element gets around the screen reader issue, in that there is no reason to read out titles on spans. However, it doesn't get around the screen magnifier issue of incomprehensible tooltips, unless there's a way of suppressing them in CSS?

The bottom line is that the BBC's decision to ditch hCalendar is a reasonable one, and every UK/US organisation has to (by law) consider the accessibility of what they produce. For me it's similar to the table accessibility issues with HTML5. Although using multiple layers of headings (and other 'edge cases') are difficult to do without more complex markup like header/ids, it has to be possible to achieve it accessibly. Even if it doesn't pave a cow-path, or it is difficult for any regular developer, it has to be possible. Otherwise large organisations will have to look elsewhere when producing that type of content (e.g. PDF).