James Craig and Bruce Lawson have raised an issue on the Web Standards Project blog today that I’ve been meaning to blog about for a while: accessibility issues raised by the use of abbr elements in the Datetime Design Pattern to provide machine-readable representations of dates in microformats.
In their blog entry, hAccessibility, James and Bruce explain my thoughts on it very well – it saves me writing it all up! It’s well worth a read if you’re into microformats.
To summarise my thoughts…
Basically, I think the expansion of an abbreviation should be human-readable. Inspired by an e-mail from Jim O’Donnell, testing microformatted date and time with screen readers back in October demonstrated that an ISO date format is hardly nice to hear being read out by a screen reader.
Having said that, it’s worth bearing in mind that, if a screen reader user cannot understand what is being said, they may well go through the text character-by-character in order to understand it. If someone does this with an ISO formatted date, it may still not sound great, but might then be easier to understand.
More recently, after discussing this quite a bit with Jon Tan, I settled (at least, for now) on using span for microformat datetimes instead of abbr, which obviously means my microformatted dates may not get parsed correctly. I think it’s a far better solution than using abbr, at least until something better is decided upon.
Jon and I have discussed a couple of alternatives:
- Prepending the
titleattribute of anabbrelement with some human-readable text to give context to users, e.g. “ISO date format: YYYY-MM-DDTHH:MM:SS+ZZ:ZZ” - Although this may be a corruption of Web standards in itself, using the
langattribute to declare the date format being used, either following it by the formatted date or putting the formatted date in thetitleattribute.
Anyway, check out the discussion on the hAccessibility entry. I’m interested in seeing where it leads and to what solution.
Updates
29 April 2007
Following comments on hAccessibility, it was proposed that the datetime design pattern for microformats be extended to allow the use of the title attribute on a series of permitted elements, e.g. span, em, etc.
There are problems here:
- Losing the
abbrmeans that the “semantic tie” between the marked up text and formatted datetime is lost. We are no longer providing context to the datetime information. - The
titleattribute may be validly used to provide additional information to an element. As such, wherever atitleattribute is already in use on an element, that element cannot be used to also provide a formatted datetime. We don’t want the datetime to get in the way of any valid use of thetitleattribute. It could also make parsing unnecessarily complicated. Thespanelement is meant to be semantically neutral, so thetitleattribute on aspanis unlikely to carry something functional to users since there is no “semantic tie.”
This is just a cursory observation, but it seems we’re trying to use the title attribute to contain what is essentially metadata meant for machines. Other microformats design patterns have used the rel attribute for meta information. The problem is that rel always contains the context for a (usually human-readable) value specified elsewhere, e.g. the name of a person marked up with XFN is given context by the value of the rel.
What we need is a mechanism by which we can specify a “meta value” – a value that is not appropriate within the context of normal page flow – as you might with meta elements in the head. XHTML 2 adds support for this kind of thing, but what can we do now? Unfortunately, there’s no other attribute more appropriate for this use than the title attribute. The datetime attribute is only permitted on ins and del. If only we could do something like <span class="dtstart" rel="datetime:YYYYMMDDTHHMMSS+HHMM">!
The discussion continues on the microformats discuss mailing list.
30 April 2007
I knew I’d read about this before! Accessify Forum: Use of <abbr> in microformats
Leave Your Response