A Blog Not Limited

Last week, Andy Clarke posted a design solution for the hAccessibility issue in microformats. It's an interesting workaround, combining the current standard for marking up dates in microformats with the broadly-accepted use of skip links.

But Wait, What Is hAccessibility?

Before I get too far into this article, though, I should probably explain hAccessibility.

As I've mentioned previously, hAccessibility was coined by The Web Standards Project to describe an accessibility issue related to the use of the abbr design pattern when expressing dates in microformats.

Basically, the datetime design pattern for microformats currently requires the use of the <abbr> element to contain the date information displayed to the user. This <abbr> then has a title value that is the ISO 8601 date (intended for machine-readability). It looks like this:

<abbr class="dtstart" title="2009-01-26">January 26, 2009</abbr>

As it turns out, this approach isn't entirely accessible for some screen reader users. For these users, the machine-readable ISO 8601 date is read by the screen reader as "two zero zero nine dash zero one dash twenty six."

More Than Accessibility, Usability Too

Further complicating the use of the abbr design pattern, there are usability concerns. In fact, the BBC (which had adopted microformats early on) stopped using microformats that require the datetime design pattern.

In addition to the aforementioned accessibility concerns, the BBC took issue with the tooltip that displays the machine-readable date information when a user hovers over the content contained by the <abbr>:

These very arguments have caused some, like the BBC, to drop support of microformats all together.

Back to Andy's Design Solution

Enough of the history. Let's get back to Andy's suggestion, which is extremely simple.

All Andy suggests is adding a skip link before any microformats containing date information. This skip link can then redirect the user to a plain, non-microformatted version of the content:

"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."

He further suggests that JavaScript could be used for disabling the display of the tooltip:

"… why not go a stage further and use JavaScript to transform these links into triggers that remove the title attributes from elements that have class="dtstart", dtend or bday applied. Dynamically removing these from the DOM would prevent users of screen-readers from hearing the output from the titles."

Personally, this approach is more than I would prefer to do to work around hAccessibility. I don't care for the idea of maintaining two sets of content. But Andy is right, it would only take (maybe) five minutes of extra time.

And, ultimately, as Andy notes, this is a practical workaround for a problem that has yet to be resolved in almost two years:

"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."

More of the Same

Yet despite Andy's best of intentions and the reality that his is a viable workaround, his post seemed to resurrect the ideological arguments that surround hAccessibility.

The same arguments that raised their ugly little heads in the comments on The WaSP's post on hAccessibility.

It seems that the microformats and accessibility communities can't get past this issue. Hell, they can't even talk about it without getting into finger-pointing, generalizations and far too much ego.

I won't name names. All you have to do is read the comments from both Andy's post and the WaSP post to get a sense of what I'm talking about. And, at this point, I'm just pissed and frustrated about it.

I'm no expert in accessibility. I'm not even an expert in microformats. But I'm a fan of both. And I think all this ridiculous ideological posturing over the issue serves no one except the individual spouting off that they know better.

It doesn't matter who is right. Both communities have valid arguments. Both are "right." But the problem remains and will continue to remain as long as people are so wedded to their opinions that they can't get past them. And, meanwhile, both microformats and accessibility lose out.

Pragmatism, Not Ideology

I'm not interested in the arguments and the "reasons" why hAccessibility remains unresolved. I'm interested in practical solutions that move us past the arguments. Andy's solution is one to be considered.

But there is more.

Value Excerption Pattern

After the "debate" on Andy's post and some frustrated tweeting on my end, I got a tweet from Tantek advising me to follow Ben Ward on Twitter.

Upon following Ben, I discovered that he's one of the (many, I'm sure) folks behind the the value excerption pattern. He describes it as:

"… a pattern for structuring data values, so in the process we can extend it do something to offer solutions to some long standing accessibility and localisation complaints."

What this pattern proposes (and, make note, it is a proposed pattern) is replacing the abbr design pattern for date/time information with an empty <span> that contains the machine-readable ISO 8601 date.

The Markup

Here's an example of what it would look like for the dtstart date/time in an hCalendar:

1. <div class="vevent">
2.       <p>Our second event is a <span class="category">presentation</span> at <span class="location">Uptown Sports Bar and Grill</span> on Wednesday, <span class="dtstart"><span class="value-title" title="2009-02-04T18:30:00"></span>February 4, 2009, beginning at 6:30 pm</span>.</p>
3.       <p><a href="http://groups.adobe.com/posts/b8a157974a" class="url summary" title="Link opens off this site">Social Media Means Business</a> is is a chance to <span class="description">learn how to leverage social media for your business</span>.</p>
4. </div>

Note the <span> is assigned class="value-title" and the ISO 8601 is contained in the title.

This pattern is also proposed for data where, for example, a British-English keyword is needed, such as "mobile" for "cell" tel type in hCard:

1. <div class="vcard">
2.       <p class="fn n"><span class="given-name">Emily</span> <span class="additional-name">Paige</span> <span class="family-name">Lewis</span></p>
3.       <p><a class="email" href="mailto:[email protected]">[email protected]</a></p>
4.       <p class="tel"><span class="type"><span class="value-title" title="mobile"></span>cell</span>: <span class="value">800-555-1234</span></p>
5.       <p class="adr"><span class="locality">Albuquerque</span>, <abbr class="region" title="New Mexico">NM</abbr> <span class="postal-code">87106</span> <acronym class="country-name" title="United States of America">USA</acronym></p>
6.       <p><a href="http://www.ablognotlimited.com" rel="home me" class="url">A Blog Not Limited</a></p>
7. </div>

And this pattern does not require that the <span> be empty in situations where the resulting tooltip delivers useful (and usable) data. In the above example, I could easily argue that exposing "mobile" in the tooltip is usable. So the following would work well too:

1. <div class="vcard">
2.       <p class="fn n"><span class="given-name">Emily</span> <span class="additional-name">Paige</span> <span class="family-name">Lewis</span></p>
3.       <p><a class="email" href="mailto:[email protected]">[email protected]</a></p>
4.       <p class="tel"><span class="type"><span class="value-title" title="mobile">cell</span></span>: <span class="value">800-555-1234</span></p>
5.       <p class="adr"><span class="locality">Albuquerque</span>, <abbr class="region" title="New Mexico">NM</abbr> <span class="postal-code">87106</span> <acronym class="country-name" title="United States of America">USA</acronym></p>
6.       <p><a href="http://www.ablognotlimited.com" rel="home me" class="url">A Blog Not Limited</a></p>
7. </div>

I simply contained my tel type of "cell" with the <span class="title-value" title="mobile">.

Public Testing

If you know me, then you know how geekishly excited I got upon learning of this proposed pattern. Since Ben had called for public testing, I just had to get my hands on it. And that's exactly what I did.

I put together a bunch of testing scenarios: some using the current abbr design pattern (as a point of comparison), some using an empty <span> and some using a non-empty <span>.

And then I just started testing whatever occurred to me and was at my disposal:

• Does the tooltip display on web browsers?
• Does the tooltip display on mobile browsers?
• Do my browser add-ons for microformats work with the value excerption pattern?
• Does the markup validate?
• Do screen readers read the title value?

I listed the results of my (admittedly rudimentary) testing following each of the scenarios on my testing page. I then asked Ben for feedback, mostly curious to know if anything I had done would prove useful to his effort.

Turns out, it wasn't just an exercise for me to get geeky. Ben asked that I add the success tests for voice and tooltip to the wiki (which I've done), and requested I do a bit more testing with two scenarios that aren't currently documented on the wiki.

Apparently WYSIWYG editors and HTML-Tidy drop empty elements, but don't drop them if there's a space. So Ben also wanted to see results for a <span> containing a single space:

<span class="type"><span class="value-title" title="cell"> </span>mobile</span>: <span class="value">888-456-7890</span>

He also wanted to see results for this same scenario, but with another whitespace character immediately following the <span>:

<span class="type"><span class="value-title" title="cell"> </span> mobile</span>: <span class="value">888-456-7890</span>

These two additional scenarios where the <span> contains a single whitespace (11 and 12) are also listed on my testing page.

And in a matter of a few hours of markup and testing, I had made a small contribution to both the accessibility and microformats community. This immediately and effectively eliminated my frustration with the arguing, posturing and ego stroking.

Shut Your Mouth & Do Something

So, what's the point of this post? Obviously to call attention to hAccessibility and microformats. But also to call attention to the energy wasted by arguing about hAccessiblilty … energy much better spent on pragmatism.

Instead of trying to prove who is right in the argument, just shut the fuck up and do something about it. Come up with a solution. Try a new approach.

If you can't develop something new, be available to test the new ideas that other folks are envisioning.

If you can't bother to do that, then you have no business arguing anything.