In a recent posting here on The future of RDFa, I described some of the advantages of RDFa compared with some of the disadvantages of microformats. When Massachusetts Commonwealth Mass.gov Chief Technology Strategist Sarah Bourne posted a comment about problems that microformats present for website accessibility, I asked her to elaborate, and she was kind enough to put this together for me.

**If Massachusetts pursues enriching our content, RDFa seems a more likely candidate.**

Part of my job is investigating new technologies that we might want or need to support on the Mass.Gov portal. A colleague brought microformats to my attention a year or so ago. Although I found it alluring—re-using standard markup to provide richer content—there were troubling accessibility issues.

We are bound by a variety of state and federal laws to ensure content on Mass.Gov is fully usable when people are using assistive technologies (AT) to compensate for a wide range of disabilities. By far the most common AT is JAWS—screen reader software that converts the graphical Windows interface to sequential text, which is then rendered as spoken language, allowing the blind to use the same software as other Windows users.

I suspect that the problems with microformats lie in the fact that they are being developed by a voluntary group instead of an established standards body. The community structure certainly leads to quicker decisions, but they are not as well vetted with a broader audience. Conflicts may not appear until their decisions have been put into practice.

There are two areas where microformats run afoul of accessibility.

abbr design pattern

The first is the “abbr design pattern”. In this case, the abbr tag is used to provide machine-readable date and location information in a standardized format. There has been disagreement about the semantics of abbreviation. Is “March 12, 2007 at 5 PM, Central Standard Time” really an abbreviation of “20070312T1700-06”? Is “Austin, TX” really an abbreviation of “30.300474;-97.747247”? It really comes down to whether you are talking about people (for whom the answer in practical terms is “no”) or machines (that would answer affirmatively).

The problem is that JAWS reads the title of abbr tags, not the text that is enclosed. This is a very friendly behavior in normal use of abbr: it vocalizes “Central Standard Time” instead of “CST”. But the title of a microformat abbr is decidedly unfriendly: very few people would recognize “two zero zero seven zero three one two capital-tee one seven zero zero hyphen zero six” as a particular date and time.

The abbr design pattern is also used by some to provide translations. Unless someone wants to declare that there is a One True Language, this is not only problematic for people using AT, it not semantically defensible.

abbr design pattern for date:

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

abbr design pattern for location:

<abbr class="geo" title="30.300474;-97.747247">
Austin, TX
</abbr>

For additional information, see hAccessibility, by Bruce Lawson and James Craig.

include pattern

The second problem area is the use of empty href in the include pattern. These links are invisible to most people, but not to screen readers, which are often configured to read the link title, especially if there is no text enclosed in the a tag. Again, this means AT users are presented with mysterious content that was intended only for machines, while users of graphical browsers are shielded.

For additional information, see Configuring links in Screen readers, by Joe Clark Mike Davies.

Therefore…

There has been resistance from the microformats community to addressing these conflicts. This is dismaying since one their basic tenets is to give precedence to use “in the wild” and this is how AT products actually behave. There was a big hullaballoo about this in May 2007, but there has been no change since then. This leads me to believe that the microformats folks just do not care about accessibility to the extent that I need to.

If Massachusetts pursues enriching our content, RDFa seems a more likely candidate. We prefer to adopt things that have been created and promulgated by standards bodies: they are more stable, the deliberative process surfaces and resolves problems beforehand, and are the only reliable basis for interoperability.

7 Comments

By Alan Hogan on March 8, 2008 8:42 PM

I had no idea about JAWS’ policy. Thanks for the heads-up.

By Isofarro on March 9, 2008 8:31 AM

The blog post, Configuring links in screen readers wasn’t written by Joe Clark, it was written by me on my blog. See the homepage of the site, for example. More importantly, the argument against the anchor-based include pattern is the screenreader testing I did and published the results on Yahoo!s YUI blog, titled Empty links and screenreaders.

By Isofarro on March 9, 2008 2:13 PM

“This leads me to believe that the microformats folks just do not care about accessibility to the extent that I need to.”

The work I did testing how screen readers deal with empty links was as a result of microformat folks approaching me and asking for assistance.

My published findings made its way into the include pattern - this happened a month ago. The criticisms in this blog post about the include pattern are thus out of date.

From that alone, its clear that the microformats community are aware of, and do care about, the accessibility issues.

By Drew McLellan on March 9, 2008 2:29 PM

The issues highlighted here aren’t issues with microformats generally. If you have reservations about using the abbr or include patterns, there nothing is compelling you to use them. The use of microformats can be happily embraced without the need to use either pattern.

You say that there have been no changes since May 2007, yet you link to some recent research into the matter by members of the community. Work continues in this area, but as there are no simple answers (as with many issue surrounding accessibility and the truly awful user agents in that space), there are no quick fixes.

By Ben Ward on March 9, 2008 3:25 PM

A few things:

Your points on the include-pattern are incorrect, or at best out of date. At no time has the include pattern advocated an empty href attribute, it is always a local document reference. Furthermore, since February 12th 2008 the include-pattern has explicitly forbidden the use of hyperlinks without inner-text. This was following the excellent research into the behaviour of empty links in assistive technology that Mike Davies lead (not Joe Clark).

Further, whilst there are some truly outrageous misuses on the ABBR-pattern in the wild, you’ve drawn no distinction between techniques which are actually advocated by the microformats specifications, and techniques which are either brainstorms, or separate to microformats.org documentation. The use of ABBR in GEO that you cite, for example, is not part of the specification. It’s located on the geo-brainstorming page, not as a recommended part of the spec.

I hope I provide some indication that in fact the microformats community does care about fixing accessibility issues. The fact is that it’s a community of volunteers, and getting research done to support changes like this isn’t trivial. One of my priorities this year is to resolve the open accessibility issues, but it takes time.

To see a piece like this come out with such criticisms is not in itself a problem (we have open issues, after all). However, to see it draw conclusions and state ‘fact’ based on out-of-date or out-right incorrect information, and fail to link the issues raised back to the microformats documentation is extremely frustrating.

By Bob DuCharme on March 9, 2008 3:46 PM

Ben,

I must take some blame for anything in Sarah’s piece being out of date; she sent it to me February 25, so the revision to the include pattern documentation was less than two weeks old when she wrote that.

Also, wouldn’t the following use of abbr have the same problem when a JAWS reader reads the title value as the example she describes above?

<abbr class="dtstart" title="2007-10-05">October 5</abbr>

This is from the hcalendar specification at http://microformats.org/wiki/hcalendar, not a brainstorming or in-the-wild page.

By Sarah Bourne on March 11, 2008 12:52 PM

I am delighted to hear that the microformats community is working on accessibility issues. I have been trying to keep up on developments in this area, but had found nothing to assure me that any progress was being made. In particular, I’ve been watching the microformats.org Accessibilityand Accessibility Issues pages for updates. Alas, those pages do not yet show the updated information on the include pattern. (Not complaining, just making an observation!) I love the idea of developing new things with a group of bright and motivated people, like the microformats folks, but it’s hard for those of us on the outside to know who’s who, and where we should be looking to get authoritative information. And although some of us are pretty smart people, there are people who may not grasp the nuances they should.

Besides the legal imperative I mentioned, government sites have significant (ahem) “public relations” vulnerabilities. For instance:

• A local paper published an article claiming a site was not accessible; the basis was a claim from one person that they felt the ALT text wasn’t good enough on two images … on an 8,000 page site.
• We stopped using any client-side scripting on Mass.Gov, because we were spending too much time explaining how you really do accessibility testing to people telling us we had “failed Bobby”.
• Search the Internet for “ODF”, “accessibility” and “Massachusetts” in 2005…

Like Caesar’s wife, any technology we use must be above suspicion. This is the context “care about accessibility to the extent that I need to” should be taken. I need to care a lot.
\

@Isofarro: Please accept my apologies for the incorrect attribution. I rely heavily on folks like you who actually test things and share them with the rest of us; I am embarrassed that I screwed up giving you the credit you deserve. I’ve asked Bob to correct that for me.\