A Blog Not Limited

to web design, standards & semantics

Microformats, hAccessibility & Moving Forward

Jan 26, 2009

Published in

Microformats

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>:

Abbr design pattern tooltip

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:emily@ablognotlimited.com">emily@ablognotlimited.com</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:emily@ablognotlimited.com">emily@ablognotlimited.com</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.

HTML5 Cookbook

Interested in HTML5?
Get the Cookbook!

I was a contributing author for HTML5 Cookbook, available for sale on Amazon! Get yours now! (I hear chapters 1, 4 and 5 are particularly good.)

P.S. Don't forget my book Microformats Made Simple is still for sale!

Tags:

Share the Love

Eileen Foster's Gravatar

Eileen Foster opines:

01/26/2009

Amen, Sister!

I, for one, will take your “advice” and shut-up and get to work on a trial of both Andy’s and Ben’s solutions.

Nice job of walking the talk. :)

Ian Pitts's Gravatar

Ian Pitts opines:

01/26/2009

Oh snap! She said fuck! (Wait, I did too…)

I love the passion around Microformats here and I also love that there’s a potential workaround (fix?) to the issue of tool-tips containing ISO dates.

I’m actually surprised that subjects like Microformats and Accessibility turned into an online dick measuring contest. Those things are usually left for lesser subjects like Flash and the real definition of “Web 2.0”.

Emily's Gravatar

Emily responds:

01/26/2009

@Eileen - Glad you approve. And I think it would be great if you did some testing of your own. Your perspective on accessibility, in particular, will be invaluable.

@Ian - Of course I dropped the fuckbomb. I’m actually pleased I kept the profanity to a minimum … didn’t want to dilute the message ;)

You are so right about the dick-measuring contest. That is the exact thing that comes to mind when I read/hear the arguments. I was even tempted to title this post Here’s the Ruler, Let’s Put an End to This.

Meitar Moscovitz's Gravatar

Meitar Moscovitz opines:

01/26/2009

When there’s a dick, there’s a…wait, no. That’s not how it goes.

Pragmatic and helpful post, Emily. Thanks for doing what you do best: getting stuff done!

Ben Ward's Gravatar

Ben Ward opines:

01/27/2009

Thank you for the support, Emily, and thank you for all the effort you’ve made in testing the new pattern. It’s absolutely invaluable!

B

Gary's Gravatar

Gary opines:

01/28/2009

Interesting read - I’ve been following this topic for a while now, and I’m glad a potential solution seems to be emerging. I agree that the BBC were right to drop their support for it, but the rest of us have the luxury of keeping going with the abbr pattern. It’s worth remembering that reading out title elements of abbreviations isn’t enabled by default in some popular screen readers (I think), and despite a bit of repetition of the content if the abbr element was a standard date, then there’s little loss of accessibility to those users. In return, you’re enabling a far wider (potentially) user group to benefit from the microformat markup and the parsing of the content that may come from it.

Great write-up too, thanks :)

Emily's Gravatar

Emily responds:

01/30/2009

@Meitar & @Ben - Thanks for the support and kind words. And an even bigger thanks to both of you for the work you do with microformats.

@Gary - You are correct: expanding the title values for <abbr> is not set by default in some screen reader. And in others, it isn’t even an option.

Regardless, when it is an enabled option, it is unbelievably annoying to deal with when using a screen reader (speaking from personal experience). Does this mean “inaccessible”? To me, not really … more a usability issue (like the tooltip). But these problems, however minor they may seem to you or I, lead to less support of microformats. Which I believe is simply unacceptable and far outweighs the arguments about which “side” is “right.”

Commenting is not available in this channel entry.

The Coolest Person I Know

Emily Lewis

Yeah, that would be me: .

I'm a freelance web designer of the standardista variety, which means I get excited about things like valid POSH, microformats and accessibility. I ply my trade from my one-person design studio in Albuquerque, New Mexico 87106 USA.

A Blog Not Limited is my personal blog where I pontificate about web design, web standards, semantics and whatever else strikes my fancy. Head on over to Emily Lewis Design if you'd like to see my work or, even better, hire me.

More

I Tweet, Therefore I Am

Follow @emilylewis on Twitter!