Stuff & Nonsense product and website design

Designing around hAccessibility

At the moment I’m writing a script for a DVD tutorial on microformats  that I will be recording for New Riders at the end of February. While designing some shiny new examples for the hCalendar event microformat, I’ve been revisiting the problems and discussions of accessibility that surround the date design pattern and thinking about possible design solutions.


For me the appeal of microformats is as much about their structured, consistent markup as it is the possibilities for their applications. I love the way that using microformats encourages people to think in more structured ways about markup. I love the consistency and conventions that they encourage too, particularly in relation to standardized class attribute values. I have rarely written a page over the last few years that doesn't contain at least one microformat.

I'm also passionate about accessibility because I believe that when you make your content available to the widest possible audience, you're doing the job of web design right. So the conflict of interest between microformats propagation and accessibility that the date design pattern raises has been bothering me.

What is the date design pattern?

The date design pattern (and datetime design pattern) is intended to allow you to publish dates and times that are human readable [and] also formally machine readable. It combines a human readable date with a machine readable equivalent using a combination of an <abbr> element containing the human readable information and a title attribute where the value is the machine readable equivalent.

<div class="vevent">?
<abbr title="2009-11-20">November 20th 2009</abbr>?
</div>

<abbr>> makes it clear that what the tags contain is abbreviated from something longer or more precise. By combining this with the title attribute, you provide a fuller, more precise equivalent. You've probably been doing this for years with code such as <abbr title="Portable Document Format">PDF</abbr>.

Applying this approach to dates and times seems very logical. After-all, however you choose to refer to a date, you are essentially abbreviating it in some way or another.

Where does the machine readable date format you're seeing in the title come from? The International Organization for Standardization's (ISO) standard format for dates and times. Year, month, day followed by time in hours, minutes and seconds.

YYYYMMDDThh:mm:ss

You can also choose to hyphenate these values to make them slightly easier to read.

YYYY-MM-DDThh:mm:ss

hAccessibility

Unfortunately this date design pattern doesn't come without a little controversy and accessibility specialists have expressed concerns over how the ISO formatted date is read to people who use some screen-readers. So strong are these accessibility concerns that last year the BBC dropped the hCalendar format from their their programme listings. Why? Well as John Allsopp explained,

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.

For example the screen-reader Jaws helpfully tries to expand the numeric strings in a title attribute into human readable numbers. 2009 is read not as two-thousand-and-none thirty-four but as two zero zero nine — hardly something that people listening to content read audibly would find easy to understand the meaning of without explanation.

Now try to imagine what it must be like to hear a complete ISO formatted date. two zero zero nine dash one one dash two zero.

In his article John asks.

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)?

This argument has raged among specialists in accessibility and microformats for almost three years and it shows no sign of abating. While microformats and accessibility enthusiasts discuss semantics, alternatives to <abbr>> and possible changes to hCalendar, I think that it is time for a little intelligent design to work around the problem.


Written by Andy Clarke .

Hire me. I’m available for coaching and to work on design projects.