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