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.
You can also choose to hyphenate these values to make them slightly easier to read.
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.
Creative accessibility solutions
Solving the specific problems that people with disabilities face when accessing web content has always involved workarounds and creative solutions from web designers and developers.
You might have expected that web browser and screen-reader vendors would have taken the lead in web accessibility. Instead it has been outside accessibility specialists and web professionals that have worked around accessibility problems by listening to, and watching, people with disabilities use the web and from there developing best practices for the ways that we write markup and style pages using CSS.
Web professionals have plugged the holes left by web browser and screen-reader vendors, even when accessibility was not their problem. Why else would accessibility conscious developers litter their markup with skip to content links?
I think that it is time to use that same creative approach and design ways around the apparent conflict caused by the abbr design pattern in general and hCalendar in particular.
I may be naive, but to me working on web accessibility involves three stages.
- Planning for accessibility from the beginning
- Providing usability enhancements for people with disabilities where possible
- Thinking about alternative scenarios and proving alternative forms of content
If you consider accessibility and include it in your planning and design process, you then help to enhance a person's experience by adding extra usability features and finally you provide alternative forms of content to cover most needs and situations, you've already gone a long way to help people with disabilities.
It's obvious that the abbr design pattern causes some people either annoyance or hampers their use of microformat content. But it's also obvious that many more people can benefit from it. As with all aspects of accessibility, the solution should come from a balance of the two.
Finding a third way
I have started to approach the problem by providing both microformat rich content with an alternative, plain version and combining this approach with familiar skip links. For example, if you are marking up a
vevent using an unordered list such as:
<ul> <li class="vevent"> [...] <abbr title="2008-11-20" class="dtstart">November 20th 2008</abbr> </li> </ul>
You can precede the list with a link to a non-microformat alternative.
<a href="events/plain/" class="skip">Using a screen-reader?</a>
If your events are presented using a
<table>, you could use the
<caption> element for the same purpose.
<table> <caption><a href="events/plain/" class="skip">Using a screen-reader?</a></caption> <tr class="vevent"> <td>[...]</td> <td><abbr title="2008-11-20" class="dtstart">November 20th 2008</abbr></td> </tr> </table>
This is as simple as writing a modified template without microformats, all of five minutes work. You could choose to hide these skip links from sight in conventional ways using CSS.
title attributes from elements that have
bday applied. Dynamically removing these from the DOM would prevent users of screen-readers from hearing the output from the
titles. (I would love to see someone create a script or jQuery plugin.)
This approach degrades gracefully as it provides meaningful content in the form of an alternative page (as opposed to a
# link) with the added benefits and improved usability that scripting, when available, provides.
Three years is long enough
One side of this seemingly entrenched argument believes that accessibility concerns outweigh the wider opportunities offered by microformats. The other has spent three years discussing the severity of the problem and possible alternative semantics for the date design pattern. I don't believe that we can wait for a consensus between accessibility specialists and microformats enthusiasts. We should be designing solutions to the problem.
I am keen to see both accessibility best practice techniques and microformats continue to develop and I hope that as web professionals have done in the past, we can find creative solutions and workarounds that keep everybody happy.