Working together for standards The Web Standards Project

By Bruce Lawson and James Craig. (German translation)

Microformats are a great idea. They allow the embedding of parsable, semantic data (like contact information and event details) into regular web pages. With the right plug-in, that information can be saved directly to your calendar program or address book. Like Microformats, a portion of web accessibility is about making web pages more machine-readable, and by doing so, making them more usable to human beings.

Most of the time, Microformats and the principles of accessibility coexist harmoniously.

Abbreviations in Microformats

HTML has an abbr element used for abbreviations. This element is used by assistive technology, including the most popular screen readers, to expand abbreviations such as ADA and lbs. The benefit to disabled users is that, the screen reader can decipher what the abbreviation means and say the appropriate, expanded version. For example, when a sighted individual sees, “20 lbs,” he will think, “20 pounds.” A screen reader will either try to pronounce the phonemes literally, or spell it out, in this case as “el bee ess.” The abbr element is the method to give the additional information (“pounds”) that makes it more comprehensible to the person listening:

20 <abbr title="pounds">lbs</abbr>

Microformats recommends the use of an abbr-design-pattern which, in some circumstances, is completely in line with the proper use of the XHTML <abbr> element. The Microformat, hCard, can use the abbr-design-pattern to specify country codes as fully-expanded, country names.

<abbr class="country-name" title="Japan">JP</abbr>

In this use, the benefit of <abbr> is twofold: screen readers can speak the word, “Japan” to vision-impaired users, and Microformats parsers can understand the address is in the country of Japan. This is the intended use of <abbr>; it’s accessible, and it’s extendable as a Microformat design pattern.

And the creator(s) saw that it was good.

hCalendar’s Original Sin

The creators of Microformats strayed from their accessible, semantic intentions when they extended the abbr-design-pattern to the datetime-design-pattern. This idea, though paved with good intentions, was a workaround for a browser bug and, like many others, has unintended, harmful side effects.

The datetime-design-pattern is a way to show a readable date (such as “March 12, 2007 at 5 PM, Central Standard Time”) to humans and a machine-readable date (such as the ISO 8601 formatted “20070312T1700-06”) to the Microformat parsers. When crossed with the abbr-design-pattern, the result is this.

<abbr class="dtstart" title="20070312T1700-06">
 March 12, 2007 at 5 PM, Central Standard Time

As you may have guessed from the previous examples, screen readers expanding the abbreviation will try to read the title element. JAWS helpfully attempts to render numeric strings into human-readable numbers, so “1234” is spoken “one-thousand two-hundred thirty-four” instead of “one two three four.” Given a title value of “20070312T1700-06”, JAWS and Window Eyes both try to read an ISO date string never intended to assault human ears:

Twenty million seventy-thousand three-hundred twelve tee seventeen-hundred dash zero six. (JAWS 8 on IE7: MP3, Ogg)

Though it may sound silly, the screen readers’ behavior is implemented according to the HTML 4 specification.

The content of the ABBR and ACRONYM elements specifies the abbreviated expression itself, as it would normally appear in running text. The title attribute of these elements may be used to provide the full or expanded form of the expression. (HTML 4, ABBR)

Unlike the ISO date format, the “full or expanded form” is intended to be human-readable. Yes, machine-readable, but for the consumption of a human, and in this case, spoken literally to a human. The Web Content Accessibility Guidelines (WCAG) explicitly defines the expansion of abbreviations as an accessibility advantage, and the most popular screen readers do so.

If an abbreviation fell in the forest…

There are debates about the semantics of the <abbr> element, and everyone is entitled to his own opinion. Is it legitimate to say “5 PM on January 5th” is an abbreviation because it omits the year? Probably. Is “5 PM on January 5th 2006” an abbreviation because it omits the time zone? Perhaps. We don’t contest that those human-readable dates are “abbreviations for a full-qualified date and time.” We contest that, according to the HTML specification, an ISO date string is not a legitimate, human-consumable, expanded form of that date and time.

What isn’t in question though, is that the use of an ISO 8601 date in an <abbr> title attribute renders the content inaccessible to users of assistive technology.

Accessibility, “in the wild.”

The Microformats group is vehemently opposed to hypothetical situations as the basis for a Microformat change. Real-world examples are often requested, or as they commonly phrase it, examples “in the wild.”

We remind the Microformats group that real-world screen reader implementations existed, according to spec and “in the wild,” long before the Microformats design patterns, and we encourage the group to respect those real-world implementations, rather than focusing on hypothetical situations such as:

In the future one could imagine a CSS rule and perhaps a CSS property or two that would automatically transform and present such ISO8601 dates from ‘title’ attributes of <abbr> elements into whatever datetime format the user preferred… (source)

What’s the Alternative?

The point of this article is not to offer a solution, but to shed light on an inaccessible practice that must change. We encourage the Microformats group to consider the problem, whether or not they accept any of the following, proposed solutions. That said, we offer these ideas as carrots to accompany our cudgel.

Originally, we considered the datetime attribute, found only on <ins> and <del> elements, and wished that we could use the datetime attribute instead of a title on a span, except it would be invalid code. Some have proposed using custom attribute namespaces for Microformat data, but the Microformats group is strongly opposed to this, and for a simple and valid reason. Microformats are intended to be “simple conventions for embedding semantic markup in human-readable documents.” Opening the floodgates to custom DTDs and namespaces would quickly raise the complexity level of Microformats to that of RDF, greatly reducing its adoption and therefore its relevance.

So we went back to basics: the existing elements and attributes of plain old semantic HTML.

The datetime-design-pattern was initially proposed as a workaround for a browser bug where the object element and the data attribute were a more appropriate choice. The authors knew this, but could not determine a way to structure it without browser bugs.

We looked again and found a way for Microformats and accessibility to play nicely once more; a way inspired by Microformats’ own empty object include-pattern.

The Object Example

<span class="dtstart">
 March 12, 2007 at 5 PM, Central Standard Time
  <param name="value" value="20070312T1700-06" />

The markup is still fairly simple, it retains its semantic purity, and it’s accessible. But…

What’s the Catch?

The catch? Okay. Even when the browsers are instructed to hide the <object>, there are still some minor display bugs in Internet Explorer (screen shot) and Safari (screen shot). At the time of this writing, Internet Explorer (version 7) doesn’t honour the space characters in the text around the object, and Safari (WebKit nightly) adds extra line breaks.

Many developers could overlook these flaws. Most designers would not. It’s an easy CSS fix: wrap the object in one extra <span> element and hide it instead.

The Hacked (Ugly) Object Version

<span class="dtstart">
 March 12, 2007 at 5 PM, Central Standard Time
 <!-- the extra span element to be hidden -->
 <span style="display:none">
   <param name="value" value="20070312T1700-06" />

Unfortunately this code sample fails the “ugly” test and isn’t as rooted in simplicity as we’d prefer, so what about some other, simpler variations?

The Span Title Version

<span class="dtstart" title="20070312T1700-06">
 March 12, 2007 at 5 PM, Central Standard Time

The Empty Span Version

<span class="dtstart">
 March 12, 2007 at 5 PM, Central Standard Time
 <span class="value" title="20070312T1700-06"></span>

Like the abbr-design-pattern, both of the previous examples use the title attribute to store the ISO data. The second version just avoids GUI tool tips. With custom verbosity settings, it is possible that a screen reader user may hear the text spoken in either example, but that circumstance is much less likely than a fully-expanded ABBR.

We are not recommending the abolishment of the abbr-design-pattern, just its misuse. Again, we encourage the Microformats group to consider the problem, whether or not they accept any of the proposed solutions. All of the examples listed are more accessible than the abbr-design-pattern. Check the final examples for details.

Like we said, we like Microformats. Their simplicity and usefulness means that they’re on the verge of widespread acceptance. We urge the Microformats community to re-evaluate the accessibility of the specification now, before the technology goes mainstream and it’s too late.

This article was co-authored by Bruce Lawson and James Craig, and incorporates feedback from other members of the Accessibility Task Force.

(Added 13 February 2008) “Configuring links in Screen readers” by Mike Davis looks at the screenreader accessiiblity of the Microformat Include Pattern. (Bruce)

Your Replies

#1 On April 27th, 2007 5:36 am