HOWTO: Fix the hCalendar and hCard accessibility and i18n problems

Written February 19. 2008, at 08:08 GMT.

As a veteran HTML builder and accessibility designer, I am a bit disappointed by the current state of things in the land of Microformats.

The thing bothering me is the abbr-design-pattern and the problems it causes in terms of accessibility and internationalization (i18n) of web-content. (See here: 1, 2 and 3, for more background)

(Also, the address- and telephone-type pattern fails the KISS principle, and causes unnecessary markup-bloat -- although that's a far lesser concern.)

Unfortunately, none of these (what I would call) obvious design-flaws, seem to have been fully acknowledged as such by the spec authors - although they quite clearly fail the stated principle of "design for humans first, machines second".

Some quotes, though not from the spec authors, nicely illustrate the general attitude:

"Using class names for the "type" of a tel or adr was attempted, and failed in many situations. In addition, the "type" information is actual data, not just a property name, and thus deserves to be in the visible markup."
-- Source

...

"One makes use of a slight loosening of the semantics of the abbr element"
-- Source

At the risk of offending those involved: These sorts of arguments seem to me like a superficial brush-off of real issues raised by concerned professionals.

No real examples are provided as to how class-names for type "failed" - except that they failed to appeal to the authors' tastes.

As for the (in)accessibility of computer-readable for date and location data, and the spec requiring "visible" English text in the page - ignoring these problems won't make them go away.

...

Fortunately, he happy fact remains that these issues are very easy to fix - if only the spec authors are willing to address them seriously.

Where there's will, there's a way.

Simple solutions:

Below I'll illustrate how the Microformat markup-patterns can be remedied.

The solutions are simple and easy to implement. They make the HTML more human-readable, while keeping it unambiguous and easily parsed by software applications.

For dates the change needed is minuscule.

Before:

<abbr class="bday" title="1987-09-27T08:30:00-06:00">
  Sept 9, 1987
</abbr>

After:

<span class="bday" title="1987-09-27T08:30:00-06:00">
  Sept 9, 1987
</span>

Instead of <abbr>, use any other element instead that does not have a strictly defined accessibility semantics for it's title attribute. (For instance, this makes <a> a bad choice). In most cases, a simple <span> will do just fine.

For parsing software there is no ambiguity there:

For an element with class="bday" the title attribute should always be assumed to be a machine readable version of the contained date.

Same goes for other date/time class-names (dtstart, dtend, duration, rdate) as well as for the geo location class-name...

Before:

<abbr class="geo" title="37.386013;-122.082932">
  Mountain View, CA
</abbr>

After:

<span class="geo" title="37.386013;-122.082932">
  Mountain View, CA
</span>

Result: Same machine-readability -- improved human-accessibility.

...

For address types the change is slightly more dramatic.

Before:

<div class="adr">
 <abbr class="type" title="dom">US</abbr>
 <span class="type">home</span> address, for
 <abbr class="type" title="postal">mail</abbr> and
 <abbr class="type" title="parcel">shipments</abbr>:
 <span class="street-address">123 Main Street</span>,
 <span class="locality">Any Town</span>,
 <span class="region">CA</span>, 
 <span class="postal-code">91921-1234</span>
</div>

After:

<div class="adr adr-dom adr-home adr-postal adr-parcel">
 US home address, for mail and shipments:
 <span class="street-address">123 Main Street</span>,
 <span class="locality">Any Town</span>,
 <span class="region">CA</span>, 
 <span class="postal-code">91921-1234</span>
</div>

The rule is simple: Any element classified as adr, may have zero or more additional class-names starting with adr- where the remaining characters are interpreted as a "type" token value.

For telephone numbers the same sort of system works fine.

Before:

<span class="tel">
  <abbr class="type" title="work">Vinnu</abbr>
  <abbr class="type" title="cell">farsími</abbr>:
  <span class="value">+354 689-3265</span>
</span>

After:

Vinnu farsími:
  <span class="tel tel-work tel-cell">+354 689-3265</span>

(See how nicely this pattern avoids the language mix-up problem?)

Benefits

In all of the above cases the semantic meaning of the content remains completely unchanged, while there are obvious gains to be made:

1. Controversial use of <abbr> is not needed (nor any other ugly workarounds), which gives us these nice Benefits:

   • Accessibility crowd is happy.
   • I18N crowd is happy.

2. Significant reduction of markup cruft, which gives us these nice benefits:

   • Faster, more mobile-friendly pages.
   • Code is more human-readable.
   • Webmasters less frustrated by weird markup requirements.

And best of all: There's no collision with any of the microformatted content already deployed on the web. It's all 100% backwards-compatible.

Moving forwards

First off, the Microformat specs would need to be updated to reflect (and encourage the use of) these new and improved markup-patterns.

Then Microformat parsing software would have to update to accept the new patterns.

Finally, to ensure 100% backwards-compatibility: The abbr-design-pattern, along with the current address-and telephone-type markup pattern, should continue to be defined as valid (albeit depricated) markup alternatives.

End note

As a great fan of Microformats as a concept, I'd hate to see them take off as internationally accepted standards, with such serious accessibility and i18n problems unresolved.

This article is written as an attempt to raise public awareness of these issues, and push towards an intelligent, undogmatic, practical solution -- before it's too late.

...because where there's will, there's a way.

---

More like this: English Entries, Accessibility, Forritun, HTML/CSS.