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 an
abbrelement 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 the
Anyway, check out the discussion on the hAccessibility entry. I’m interested in seeing where it leads and to what solution.
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.
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.
titleattribute may be validly used to provide additional information to an element. As such, wherever a
titleattribute 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 the
titleattribute. It could also make parsing unnecessarily complicated. The
spanelement is meant to be semantically neutral, so the
titleattribute on a
spanis 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
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
del. If only we could do something like
<span class="dtstart" rel="datetime:YYYYMMDDTHHMMSS+HHMM">!
30 April 2007
I knew I’d read about this before! Accessify Forum: Use of <abbr> in microformats