Working together for standards The Web Standards Project

Thanks to Sebastian Snopek from the International Liaison Group (WaSP ILG), this post is also available in Polish: Wtórny hAccessibility?.

Fanning the fires of the ABBR pattern debate, the developers at BBC Radio Labs announced today that they’ll be removing the hCalendar microformat from their programmes listing pages, pending further accessibility testing or the establishment of a more accessible alternative.

Unfortunately there have been a number of concerns over hCalendar’s use of the abbreviation design pattern. [...] Until these issues are resolved the BBC semantic markup standards have been updated to prevent the use of non-human-readable text in abbreviations.

As with the debate over a year ago, the concerns raised are not about microformats as a whole being inaccessible. They’re not even strictly about the hCalendar microformat itself. The concerns are purely centred around the (mis)use of the ABBR design pattern.

Call me naive, but — for me at least — the problem seems to boil down to a few simple points:

• microformats are extremely useful, and, if implemented in an accessible way, can yield massive usability improvements for all users
• the ABBR design pattern is demonstrably broken — no ifs, no buts, no “it’s an edge case”, no playing the numbers
• a handful of alternatives to the use of the ABBR pattern already exist — for instance, the BBC could quite happily carry on using hCalendar, avoid ABBR altogether, and instead opt to have machine-readable information present in the page as a piece of invisible supplementary data; however, this seems to be a rather inelegant (and not well publicised) implementation
• further alternatives to ABBR have been discussed at length (such as proposals to put machine-readable data inside the class attribute), but no real consensus has yet been reached — meaning that current microformat-consuming tools and services are unlikely to support them.

In many discussions, the problem of microformats and accessibility is often miscast as an either/or proposition. Retorts of “if you have accessibility concerns, don’t use microformats” or “if you don’t want to mark up dates in a machine readable format, don’t use microformats” are a classic reductio ad absurdum, and do nothing to move the issue forward. Why should the desire to provide machine-readable data for tools necessarily be antithetical to the desire not to thrust the gibberish of something like the full ISO 8601 date/time in the face of end-users (as expanded ABBR title that’s read out by screen readers under certain conditions, visually presented as a tooltip to sighted mouse users, or clearly present as clear text in the markup when CSS is unavailable)?

Here’s hoping that high-profile announcements like the BBC’s (and those less public, but nonetheless significant ones) will help create some momentum and a concerted effort to find a robust substitute for ABBR. And, once that’s happened, can we finally take this flawed design pattern out of circulation, educate the early adopters of microformats about the new and improved pattern(s), and move on to bigger and better things?

Your Replies

#1 On June 23rd, 2008 7:19 pm Andy Mabbett replied:

“invisible supplementary data” is ignored by some parsers, most notably the Operator exetnsion for Firefox.

#2 On June 23rd, 2008 8:35 pm Sarven Capadisli replied:

What is so “gibberish” about this article’s date “2008-06-23″ ? What would be a more accessible alternative?

#3 On June 24th, 2008 12:49 am Ben Boyle replied:

Well the time element in the HTML5 draft will do nicely.

The question is when to start using it… guess that depends on microformat parser support and authors comfort with using a draft recommendation (or an invalid element within their otherwise valid pages). Personally when compared with the issues around abbr, I like the time element.

http://dev.w3.org/html5/spec/Overview.html#the-time

#4 On June 24th, 2008 1:54 am Andy Mabbett replied:

See also Griffin Caprio’s comment:

“I’m not sure I have enough faith in the Microformats community to come to an agreement on this topic. In my short time following the various Microformats mailing lists, I quickly became disillusioned with the community and administrators. I witnessed several instances of heavy handed administration, including the banning of users. Frequently, no real reason was given and I was left w/ the impression that it wasn’t much of a community after all.”

#5 On June 24th, 2008 3:15 am Jonathan Kahn replied:

Patrick,

I agree with your argument, but it seems to me that there’s another option to add to your list, which so far I’ve not heard mentioned.

When we talk about “machine-readable” dates, we seen to assume that only human-hostile date formats can be understood by machines. But what about smarter algorithms, e.g. that behind the strtotime() function or OS X Leopard’s Mail.app?

If I specify a date as, e.g. “Tuesday 24 June 2008, 8pm”, and demarcate it properly, why can’t a parser understand it?

#6 On June 24th, 2008 4:18 am Frankie Roberto replied:

Nice post. This issue has been known about for a while now, so I hope that these high-profile posts will hurry along a decent solution!

#7 On June 24th, 2008 6:49 am Lachlan Hunt replied:

HTML5 already has a solution to this problem. The time element has been in the spec for quite a while now. People could use and implement that. The only problem is that they would either have to start using HTML5 or accept the validation error if they use HTML4/XHTML1 DOCTYPEs, both of which are viable alternatives.

#8 On June 24th, 2008 12:18 pm Jeremy Keith replied:

I think you’ve stated the situation nice and clearly here, Patrick. As you say, this is an issue with one combination of patterns: ABBR with datetime (though not date, in my opinion). Personally, my concerns are less to do with accessibility (as I haven’t come across any real-world problems); I’m more concernced with the semantics of using ABBR to represent full ISO datetimes.

Like I say, I don’t see any problem in using ABBR to represent a date (YYYY-MM-DD) as that is entirely human-readable (more so than many cultural conventions) but for the situation at the BBC where programme schedules need to indicate start and end *times*, the full ISO datetime is overkill.

Rather than find some alternate element or attribute to stuff the datetime into (a short-term solution, at best), I’m hoping that a solution will be found that involves splitting the date and time portions into separate parts. This would also reflect the publishing behaviour — most schedules have the date and time portions in separate elements. After all, if YYYY-MM-DD is human-readable and HH:mm is human-readable, I think it’s fair enough to ask parsers to convert those separate portions on the fly into YYYY-MM-DDTHH:mm:ss (presumably defaulting the seconds to zero).

The trick will be coming up with a robust optimization pattern for this. That’s where I’ll be concentrating my efforts on the microformats mailing lists and wiki.

#9 On June 24th, 2008 12:46 pm Billee D. replied:

I love microformats for all the benefits that they bring to the table, but the hCalendar’s ABBR pattern really confused the heck out of me at first. My initial response was something along the lines of “what the **** were they thinking?” And then the accessibility issues started cropping up followed by the heated debate…

I still use the hCalendar on most of my sites as-is and keep hoping that the Microformats crew will devise something more elegant, but I have seen nothing but the arguments that were noted here; “this is an edge case” rings of plain old laziness. We obviously need to rethink the whole ABBR design pattern and come up with something that works as intended.

Thanks for the article and here is to hoping that we come to some kind of resolution soon lest the masses reject something that really can help us embed useful meta data into our markup.

#10 On June 24th, 2008 2:04 pm Nick Fitzsimons replied:

It really is time that the microformats community just accepted that the <abbr> pattern is broken and moved on in search of a viable solution. There seems to be an unwillingness among some to admit that it was a flawed concept from the start.

+1 for hoping that some progress can finally be made in abandoning this mistake and finding a way forward.

#11 On June 24th, 2008 2:10 pm Andy Mabbett replied:

Still more denial from the microformats cabal:

http://rbach.priv.at/Microformats/IRC/2008-06-24#T124055

#12 On June 24th, 2008 3:15 pm WaSP Member plauke replied:

sorry folks, all comments were awaiting moderation and i only now got around to doing some admin duties…

serven: “2008-06-23″ isn’t gibberish, but the full ISO “2008-06-23T01:30:22+00:00″ is…

#13 On June 24th, 2008 3:34 pm WaSP Member plauke replied:

andy, in fairness drew’s comment (“it doesn’t sound like he really understands the issue”) was aimed at mike over at the bbc. and indeed, as i point out above, hCalendar itself isn’t really at fault, just the use of ABBR, which is not necessary (but yes, alternatives are not well developed, supported, or desirable just now either, so a catch-22).

on the other hand, as noted above, saying that the full ISO is the opposite from gibberish http://rbach.priv.at/Microformats/IRC/2008-06-24#T123503 to a normal human being is…wishful thinking. otherwise, why don’t we human beings, in normal human conversation, use full ISO date/time? why don’t we start talking in binary as well, while we’re at it? ideally with redundancy for error correction…

the same argument can be had about marking up locations (e.g. “Salford”) as geo location with long/lat and then claiming that saying 53.483541 and -2.270666 is not gibberish because it’s more unambiguous. yes, if this was a geocaching site, perhaps…but for normal humans it’s just that, a random string of meaningless numbers.

#14 On June 24th, 2008 3:56 pm Andy Mabbett replied:

“2008-06-23″ might not be gibberish; but it’s not really /accessible/ to people with cognitive difficulties. Likewise “18:00″ for “6pm”.

Then there is *still* the “dtend” issue, where “2008-01-01″ is used as the title attribute of the abbreviation (sic) 31 December 2007.

@Patrick: Yes, I know who “it doesn’t’t sound like he really understands the issue” was aimed at. I don’t believe that Michael was saying that “hCalendar itself [is] at fault”.

Note that today’s developments suggest that accessibility is still not understood by the microformats cabal.

#15 On June 25th, 2008 6:01 am Andy Mabbett replied:

The BBC have posted a follow-up:

http://www.bbc.co.uk/blogs/radiolabs/2008/06/microformats_and_rdfa_and_rdf.shtml

#16 On June 25th, 2008 7:36 am Richard Rutter replied:

To all those people bashing the Microformats community with the term cabal: give it a rest. It’s not constructive, and is not exactly going to engender a feeling of sympathy towards your point of view.

Neither is it accurate: there’s nothing secret or cliquish about Microformats. Get on the wiki and the mailing lists, contribute to the discussion and suggest some alternatives.

#17 On June 25th, 2008 9:35 am Andy Mabbett replied:

@Richard Rutter: Exeprience shows otherwise; though the term “cabal” is not being used to describe the so-called “community”, but the unelected clique who actually run things. We don’t even know who they all are; their mailing list is not public and even mention that it exists was removed from the microformats wiki:

http://microformats.org/wiki?title=mailing-lists&diff=14391&oldid=14389#General_guidelines

#18 On June 25th, 2008 11:05 am WaSP Member plauke replied:

oh for heaven’s sake …

“the abbr-date-pattern not only does not have accessibility problems, it actually may *help* accessbility”

http://rbach.priv.at/Microformats/IRC/2008-06-25#T001752

see, it’s this stubbornness by the microformats “leadership” that is holding up any real progress and trying to simply smother any sensible discussion…

#19 On June 25th, 2008 11:54 am Sarven Capadisli replied:

@WaSP Member plauke:

My name is “Sarven”, not “serven”.

It is misleading to think or to suggest that full ISO8601 date must be used. It is improper to generalise that the whole thing is gibberish in every context just because the full ISO8601 doesn’t fit well into BBC’s case.

@Andy Mabbett:

Indeed it is not true that YYYY-MM-DD is the best date format for every person, however, it is accessible to most.

Splitting the date and time (and timezone) is a partially a response to minimising readability of full ISO8601. It is certainly not full proof nor meant to be.

#20 On June 25th, 2008 6:19 pm Andy Mabbett replied:

@Sarven Capadisli Accessibility is *fundamentally* not about settling for what is “accessible to most”.

How do you suggest that we mark up “3pm on 27th June 2008″, without using an ISO8601 date?

#21 On June 25th, 2008 7:03 pm ritchielee replied:

@plauke, in defence, the “the abbr-date-pattern not only does not have accessibility problems” quote was part of a much wider conversation between members. You’ll now see that they are acting and putting a lot of thought into the issue, as they have previously.

Abbr wasn’t picked on a whim. Yes semantics are questionable, but it fits well given we’re working with html, just as we ‘abuse’ definition lists. Jeremy has already pointed out that the title attribute was a good fit. As for screen readers, comment can only be made from testing. Is it really a showstopper?

Also, an aim was to be machine readable; to provide a standard we could work off, and it succeeded.

#22 On June 26th, 2008 5:06 pm Andy Mabbett replied:

It’s important not to overlook the fact that this isn’t just about hCalendar dates.

A similar pattern is used for publication dates in hAtom and hAudio.

The latter also uses this gem of a pattern for the duration of mp3 files and the like (referring in this example from the hAudio spec on the microformat wiki to 5 minutes and 48 seconds):

[abbr class="duration" title="PT5M48S"]5:48[/abbr]

#23 On June 29th, 2008 6:39 am WaSP Member plauke replied:

cute… http://diveintomark.org/archives/2008/06/29/microformats-accessibility

#24 On June 29th, 2008 12:46 pm André Luís replied:

@plauke (#18):

I don’t mean to come out defending anyone, but the abbr-design-pattern and the datetime-design-pattern are two different things.

I can use an abbr to specify a certain property of a microformat without hindering accessibility. Abbreviating a name [abbr title="André Luís"]André[/abbr], for example.

The problem lies in the datetime, like he said on the line after that… we can all agree on that.

#25 On June 29th, 2008 1:39 pm Ben Ward replied:

Just to clarify a few points.

The list of community admins at microformats.org is clearly documented here: http://microformats.org/about/people/ — comments suggesting that this group operates in secret are entirely false.

We do have a microformats-admin mailing list. It is never, ever used for the development of microformats. I’ll happily tell you the last active thread there concerned last month’s upgrade of the microformats.org blog to WordPress 2.5, and asked whether we wanted to switch categories to tags for our posts there.

I emphasise as well that this group are community admins, not the ‘owners’ of microformats. It happens, of course, that those who are prepared to put in the time to help admin the community are also people who have time to put into developing microformats as well.

If you ever feel that any individual within the community — admin or otherwise — is acting inappropriately, bypassing the process or ignoring the work of others in favour of their own preferred solution regardless of merit, you should call them on it. That, ultimately, is how a community has to work. Throwing stones in blog comments from outside doesn’t really help the situation (for one, you can’t rely on them being noticed). I refer, of course, only to the stone throwing comments.

Work on this issue has been sporadic; it’s a volunteer community, after all. Not that I’m saying to huge timescale of non-resolution is in any way acceptable (it isn’t, in my view, I’m just trying to give some take on why). Currently things are moving quite well, with a number of different tracks approaching the core issues. See:

• machine-data
• datetime-design-pattern#other_proposals

Additionally, the invisible supplementary data pattern mentioned in this post is just one proposed solution (within the limits of valid HTML4), hence the lack of parser support. The wiki page in question emphasises that it shouldn’t be used in publishing yet. The open issues for that pattern are now wrapped up in the value-excerption-pattern-issues documentation.

Thanks,

Ben (on that list of microformats admins)

#26 On June 29th, 2008 4:22 pm Andy Mabbett replied:

@André Luís: No, it’s not just about datetime, it applies also to coordinates and to duration (in hAudio) for example; and to mis-use of abbreviation for the the internationalisation of types of tel(ephone) and e-mail properties (e.g. in a French page [abbr title="work"]Travais[/abbr])

@Ben Ward: It has previously been stated that that list is incomplete. Are you now saying that that is not the case?

If the admins do not act in secret, where are the archives of their mailing list available?

I’m not aware that anyone has claimed that that mailing list is being used for the development of microformats; that’s a straw-man. But it is, is it not, used to determine the rules by which the microformats “community” wiki, mailing list and IRC channel are governed? And discussion of those methods of governance are prohibited on those fora, is it not?.

As for “calling” people on their acting inappropriately, I asked, over a year ago, what was happening to the money paid for the T-shirts sold via the microformats wiki:

http://microformats.org/discuss/mail/microformats-discuss/2007-June/009902.html

As yet, no-one has answered me. Complaints about the actions of some of the admins on the list you cite has also been loudly ignored (or “not ignored, just not answered”, as one of them once defended similar such aloofness.).

I’d gladly “throw stones”, as you choose to describe making legitimate criticism, from inside the community, rather than outside it. But that’s not allowed either, is it?

You have my e-mail address; I’m quite happy to discuss this with you 1-1.

#27 On June 29th, 2008 8:56 pm WaSP Member plauke replied:

More good discussion initiated by John Allsopp BBC drops hCalendar for programme listings, citing accessibility concerns

#28 On July 4th, 2008 4:06 pm WaSP Member plauke replied:

Jonathan Hassel and Jake Archibald have a nice round-up of the discussion so far over at the BBC Internet blog: Why the BBC removed microformat DateTime patterns from bbc.co.uk…

#29 On July 30th, 2008 4:08 pm Andy Mabbett replied:

If the comments added (and previous comments removed) in this 30 July edit to the microformats wiki are anything to go by, theuisseu has stil not been understood, or accepted, by the microformats cabal.

#30 On August 18th, 2008 7:21 am Microformats and accessibility: the soap opera that never ends | AUTO JET replied:

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

Post a Reply

Comments are closed.