![[duck with its head underwater]](http://wearehugh.com/public/2008/06/ducks-butt.jpg)
ducks butt © Dave Gough / CC
ducks butt © Dave Gough / CC
As far as I can tell, the only thing that leading accessibility experts agree on is that nobody listens to leading accessibility experts, especially not the microformats cabal, which has never cared about accessibility, has never bothered to test it, and has never acknowledged those who have tested it. In fact, the BBC recently removed one microformat from their site because one piece of it may be confusing to some screen reader users with a certain non-default configuration. This proves what leading accessibility experts have been saying all along, that all microformats are inaccessible, and we should all just use RDF.
Meanwhile, the devilish cabal is secretly solving the problem on their public wiki page, their public mailing list, and their public IRC channel. But will it be enough for the BBC? Be sure to tune in next week, when we’ll drown a leading accessibility expert to see if she’s a witch.
§
Can I help pick the expert?
— Anonymous 
All this Microformat, RDF, metadata stuff is too confusing for me. I’ll just leave it to you web nerds :)
— Bryce
I don’t know what amuses me more here:
1. That we’re still stuck in the mindset of teaching humans to write documents for computers instead of teaching computers how to read human documents, or
2. That there’s a solution to this problem based on nothing more than standard, non-screenreader-fucking-up, HTML.
Everyone concentrates on the datetime pattern’s fairly non-existent issue with screen readers. The actual issue is that the machine data ends up in human readable space via a tooltip. Also, semantically this is an abuse of the abbr element and title attribute.
— Anonymous
as ever, it’s endearing to see your biting wit focusing on one biased side of an issue.
yes, the microformats community has been aware of potential accessibility issues, but has - in over a year of them being generally publicised - done nothing visible to resolve them. yes, they’re now “secretly” solving the problem, but if you check the dates on the wiki work in earnest only started after the BBC announcement, which - as misguided as it may have been, generalising the problem of ABBR to being one of hCalendar, which is of course false - goes to show that only high-profile announcements like that seem to have any tangible effect.
but hey, glad it’s keeping you amused.
— Anonymous
So far as I’m aware, no “leading accessibility experts” have been saying that “all microformats are inaccessible”; just pointing out that some patterns used by some microformats, in some (sadly, too many) cases are inaccessible. Nor are they saying that “we should all use RDF”.
The cabal is not “solving the problem”, secretly or otherwise, but is running around like a bunch of headless chickens, oblivious to the real issues, and coming up with a bunch of irrelevant and unworkable attempts at solving the problem, many of which still include accessibility barriers.
They’re also spouting rubbish like “The accessibility concerns are considerably lessened, even eliminated when using the date-design-pattern, a subset of the datetime-design-pattern“.
As Alan Hogan has it: “We need to drop the egos involved and change the relevant microformats while they are still young. It’s not too late to make a better choice!”
Not bad. I like your definition of “meanwhile” for the novelty.
Simply use the aural profile of CSS and hide your mircoformats from screenreaders or use: speak:none;
— Anonymous
…And HTML5’s custom data- attribute proposel looks ever more appealing and ever more real-world.
“Simply use the aural profile of CSS and hide your mircoformats from screenreaders or use: speak:none;”
last time i checked, browser support for aural CSS ranged from minimal to non-existent, but thanks for the “simple” suggestion.
— Anonymous
“Simply use the aural profile of CSS and hide your mircoformats from screenreaders or use: speak:none;”
And when CSS is not available, or is disabled..?
Uhm. I’m not an accessibility expert, but … the secret resolution is to split the obscure string of numbers, hyphens, colons and a lonely “T” in to opaque string which are both not really locatable for nonISO-8601 languages?
Uhm … Mark?
— Anonymous
(Ok »locatable« is obviously not the right word, but I’m drunk, tired and not in my mother tongue. You get the gist. ;)
— Tim
Some thoughts here
http://microformatique.com/
In a nutshell - we have now pushed HTML past its capacity to solve the increasingly common problems we are trying to solve with it. So, we can wait for the next iteration of HTML to “solve” these problems (which doesn’t look promising with the way HTML5 is headed - geez, people think microformats is dysfunctional), or we can look for the least worst solution that works on today’s web, with today’s browsers, common developer skill sets, widely used tools, and so on. Nothing comes close to addressing the issue of how we embed richer semantics in *today’s* web than microformats.
What I find puzzling is the outpouring of largely overwrought and often highly emotional generalized criticisms of all microformats, and the microformats community (spelt “cabal”) apparently.
Yes, there is a challenge around the use of the abbr design pattern. It’s arguably a misuse of abbr element (but arguably an acceptable use - this is no lay down misere, and I’m not entirely sure why people are so het up about an arcane matter of definition), and it’s arguably an accessibility issue.
Hold on, arguably an accessibility issue? - yes. Because it’s instead arguably a *usability* issue for a possibly small percentage of screen reader users - it seems pretty annoying to have ISO date time string read aloud to you - but does that actually make the page and its content inaccessible?
Frankly little of the discussion around this issue has been particularly well informed, or edifying. But hopefully it highlights a serious problem with the web as it is - HTML lacks the flexibility and capacity to embed richer semantics even the most commonly used data formats on the web, such as events. This needs a solution, and sooner rather than later. So, where are we going to get that solution from?
John, as noted elsewhere, it’s not *just* a problem concerning screenreader users. And yes, if we want to split hairs, it’s a usability issue (though the modern definition of accessibility would, in my mind, encompass usability as well). Heck, you could argue that something like a javascript function that redirects / auto-refreshes a page is “annoying”, but doesn’t make a page accessible … “just turn off javascript”. Or hey, IE doesn’t resize text sizes defined in pixels? “Switch to a better browser”.
Basically, the current (ab)use of ABBR is throwing speed bumps into the path of users, when there are other, less obstructive potential solutions.
Patrick,
I’d suggest the tooltip aspect is close to a trivial issue - how often do folks hover over a abbr, which is usually not styled any differently to surrounding text to see the expansion? Does the resultant ISO date time string elicit more than a HUH? I doubt it (but research on the issue may well prove me wrong). There is some reference to usability testing by the BBC on this issue - I’d be interested to see some of the results in more detail.
I don’t consider the accessibility stuff trivial at all. Hopefully this episode will help precipitate a move toward a less bad solution. But the point of my thoughts is to put in the table that this is not simply a good/bad issue. There are choices and compromises to be made, and will increasingly more so be as we push HTML even further past what it was designed to do. Hopefully those future choices and compromises can be informed by these, our past lessons.
and why’s there no discussion about the i18n problem with the address-type and telephone-type patterns?
— Már
I liked the Big A.
The ABBR element has a (fairly) clear purpose, and the micro-format use is NOT its purpose. The SPAN element seems to have a vague purpose or the OBJECT element that has a degrading ability, they would seem better targets.
Perhaps I’m missing something, it seems to me the ABBR element is used so the micro-format could be debugged by a human in a browser. Perhaps the examples are too simplistic. I can just about stretch ABBR of “tonight” (or “last Wednesday”) to the actual year-month-day[-hour-minute-second], but it might be the wrong way round - now I cannot decide:
an OBJECT with class of date-time with PARAM value YYYY-MM-DD and content “tonight”, or
an OBJECT (or SPAN) with class of human-date-time and with content YYYY-MM-DD?
I am no longer accepting public comments on this post, but you can use this form to contact me privately. (Your message will not be published.)
§
firehose ‧ code ‧ music ‧ planet
© 2001–8 Mark Pilgrim