ABBR pattern accessibility

Posted in Accessibility.

microformats logo.I’d been meaning to post on the microformat-accessibility issue, but Patrick Lauke just posted a great sumary. As a sort of +1, I’d just like to share what I would prefer as an accessibility aware developer.

I’ve been using the hcal microformat for almost as long as it’s been around on the UKWA events pages, I even added it to the examples in the wild page. I just mean to point out that this is not an academic issue for me, I use it already.

I started with the recommended abbr pattern, but I’ve since moved to using span, for example:

<span class="dtstart" title="20080705">
   Jul 5</span>

This doesn’t actually get around all the issues, but in element-meaning terms, the span is not something that access technologies would need to read out the title of, but abbr definitely is. (It still doesn’t get around the mouse-over issue, but I don’t see a current solution to that, yet.)

Interestingly, the class has been proposed as a way of hiding the parsable data, for example:

<span class="dtstart data-20051010T10:10:10-0100">
   10 o'clock on the 10th</span>

This does not appear to have been embraced:

-1 Tantek. I’m vehemently opposed to putting data in the class attribute. We must find better alternatives. We must not go down the path of invisible (dark) (meta)data – IMHO that principle is inviolable for microformats.

I agree (with a point further up that page) that loading the class attribute is not a common method for this, although I can’t see how that is different from using the title attribute for machine parsable data, especially on an element aimed at people.

Tantek points to the principles, which include: design for humans first, machines second… be presentable and parsable, so I don’t really understand how this fits (or doesn’t) fit those principles. The data is (and should be) hidden from people browsing, but should be parsable by their user-agent.

I don’t see a current “best” solution. It has been circling for a year, and no-one has come up with anything that all are happy with. On a personal site I would rather use something from HTML5 that isn’t valid yet, for example:

<span class="dtstart" data-date="20080705">
   Jul 5</span>

Using an attribute (rather than an element as Lachlan Hunt suggested), feels like it would be less likely to cause compatibility issues in user agents, although I’m happy to be corrected on this.

The actual downside at the moment is that it wouldn’t be supported by anything that people would use to parse microformats.

Unfortunately I don’t have an answer, loading the class does get around the accessibility issues, but would have to be updated in parsers. Using a span element gets around the screen reader issue, in that there is no reason to read out titles on spans. However, it doesn’t get around the screen magnifier issue of incomprehensible tooltips, unless there’s a way of suppressing them in CSS?

The bottom line is that the BBC’s decision to ditch hCalendar is a reasonable one, and every UK/US organisation has to (by law) consider the accessibility of what they produce. For me it’s similar to the table accessibility issues with HTML5. Although using multiple layers of headings (and other ‘edge cases’) are difficult to do without more complex markup like header/ids, it has to be possible to achieve it accessibly. Even if it doesn’t pave a cow-path, or it is difficult for any regular developer, it has to be possible. Otherwise large organisations will have to look elsewhere when producing that type of content (e.g. PDF).

23 contributions to “ABBR pattern accessibility”

  1. basically, tantek’s point – the way i understand it – is: the fact that the machine-readable part becomes visible to users (as a tooltip, as plain text when css is disabled, etc) is a desirable feature and not a problem, as it prevents the data going stale since inconsistencies with the marked-up “human” part would become immediately apparent. this principle wants to avoid data that gets stuffed in something like a meta element in a page’s head and then never maintained/updated/checked.

    by that rationale, even the invisible supplementary data idea would fail. so yeh, not quite sure where he draws his arbitrary line.

    not tested this, but: does your microformatted content using SPAN instead of ABBR actually get picked up by microformat-consuming tools like Operator and co.?

  2. Hmm, just tested it in operator and apparently not. I think it works in the Technorati events search, but I can’t swear to that (or find the ping for it anymore). The Technorati conversion feature was the main reason I started using Microformats, because producing an iCal file didn’t seem to work and Technorati had an easy conversion.

    It’s funny, the concept of it being human readable reminded me of the first thing our teacher did in Computer Studies (when I was 14, in 1990). He put up on the board:

    07091990

    And asked us what it was. No one knew. When he added slashes (07/09/1990) everyone knew. He then on to talk about garbage in garbage out, i.e. the computer might need that format, and it was ok that we didn’t understand it!

  3. Just tested in Brian Suda’s conversion tool, and got:

    BEGIN:VEVENT
LOCATION;LANGUAGE=en;CHARSET=utf-8:Hove lagoon
SUMMARY;LANGUAGE=en;CHARSET=utf-8:JP/Pryde Series 4
DTSTART;VALUE=DATE-TIME:Jul 5
DTEND;VALUE=DATE-TIME:6
END:VEVENT

    Which doesn’t work in Outlook at least (dropping the events into today). Shame, I guess I’ll have to pull them and do my own iCal.

  4. How come Celik’s point, as ably explained by Patrick, doesn’t apply to XFN, or other uses of @rel in microformats? A case of “do as I say”, not “do as I do”?

  5. I doubt that Andy, Tantek’s a very clever guy and having an internal inconsistency like that is unlikely.

    I’ve seen him speak a couple of times, and I’m more inclined to think that there is a facet of the argument I’m missing. (Not that I would necessarily agree with him if I did completely understand, but it’s the more likely scenario.)

    Interestingly Drew mentioned that abbr isn’t needed for hcalendar, but unfortunately at least two of the common parses do require it.

    His ideas along the lines of using the content to establish dates are quite interesting, kind of a reverse of PHP’s date formmating.

  6. Celik’s pronouncements and behaviour are riddled with inconsistencies (and of other ‘”do as I say”, not “do as I do”‘ examples); many of which I’ve documented previously on the microformats wiki and mailing list (many of the former he deleted).

    while ABBR is NOT required for hCalendar, and is NOT needed by any parser, the only alternative available is to publish dates (and times) in user unfriendly formats like 2008-06-25 or 2008-06-25T13:25+01:00

  7. while ABBR is NOT required for hCalendar, and is NOT needed by any parser

    So how come the XSL transform from Suda.co.uk and the Operator Firefox extension don’t recognise this?

    <span class="dtstart" title="20080705">Jul 5</span>

  8. <span class="dtstart" title="20080705">Jul 5</span>

    Because it's not allowed, by the spec.

    However, this is:

    <span class="dtstart">20080705</span>

    It's not elegant; it's not accessible; but it does NOT require ABBR.

  11. Not in the way I intended, which was to show “Jul 5”. Even with dashes an ISO date is not something I want to be showing to users.

    Given that I’d transposed the example to a data-table (and list markup elsewhere) successfully, I had thought any inline element would work for applying the date.

  13. Yep. The POE approach makes dramatically more sense. Tantek’s idea that the non human friendly format should be human visible, is, as you say, clearly missing something, to be coming from a smart chap. The class thing sort of works for me, but frankly I think all this will be (if its not already) the death of microformats.

    Most uses I’ve seen them put to are simply not abbreviations. Pivoting on the very wooly ‘paving of the cow paths’ argument, it holds no water IMO.

  14. The “POE” suggestion will not work, because it’s not readily available globally (internationalisation is another area where the microformats need to be more considerate).

    How is a parser writer to understand a microformat in a language, or even character set, with which they’re not familiar?

    How will it solve the issue of, say, exposed machine-readable coordinates, or hAudio’s duration: 3 minutes and 23 seconds ?

  15. How do PHP (and other programming languages) create output dates?

    Surely what ever process goes from computer readable to human readable (e.g. today “d F o” = “24 July 2008”), can recognise that format and reverse it?

    And if that is possible, surely the same forwards rules can be reversed for internationalisation purposes?

  16. The reverse of your “computer readable to human readable” example is impracticable, because of the number of languages, and permutations in languages, which the human readable date might be written in.

    And it *still* doesn’t solve the coordinates and duration examples.

    (The hAudio example in my last post was supposed to be [abbr class=”duration” title =”PT3M23S”]3 minutes and 23 seconds[/abbr])

  17. So you said, but without supporting it.

    It does work the other way around for PHP, which must in some form output suitable formats for different languages.

    Therefore a parser could detect the language (nearest lang attribute set up the DOM tree), and use the rules associated with that language.

    The other examples I haven’t looked into, but one thing at a time…

  18. “So you said, but without supporting it.”

    That’s because I can’t prove a negative. If you think you can prove that it can be done, feel free. You could start by pointing to the PHP code which does it in the easy direction, for *every* language…

    Why stick to “one thing at a time”, when there are already proposals which woudl fix this issue in all cases?

  19. The page above linked to English, most European languages, Russian, Japanese, and a whole load more that work but don’t have up to date translations of the manual.

    I assume the proposals you mention haven’t been accepted, otherwise we wouldn’t be here.

  20. But not all languages (“As of early 2007, there are 6,912 known living human languages” – Wikipedia); so thank you for conceding my point.

    That other proposals have not (yet) been accepted does not mean that they are not workable.

  21. Actually, I don’t concede that coding for all languages is even something you’d want or need to do.

    If you can cover the languages where people can automate the process of producing HTML content, that is more than enough.

  22. I see your point Andy. Its one worth making.

    But still, the only solution the makes any sense to me is using class attributes. I see no logical reason not to use them, yet ‘vehement’ opposition stands…

    What would clearly be wrong (IMO at least), is making something not human friendly human viewable.

  23. This is a problem which is causing me some angst, since I’m right now helping a friend with a calendar page for his website.

    It pains me to speak ill of the microformats community, because I highly regard both the concept of microformats and the effort they have put into specifying them. However, there’s no escaping the simple fact that using the <abbr> element in this context is beyond inappropriate.

    1. It disregards a recommendation in the HTML specification for the use of the title attribute in abbreviations:

      The content of the ABBR and ACRONYM elements specifies the abbreviated expression itself, as it would normally appear in running text. The title attribute of these elements may be used to provide the full or expanded form of the expression.

      The ISO date is emphatically not a “full or expanded form” of the actual English date. If anything, it is the opposite.

    2. It compromises one of the principles of microformats. By obeying the letter of the law (“visible data is much better for humans than invisible metadata”), it violates the spirit: “design for humans first, machines second[.]” ISO dates are predominantly consumed by machines, not humans.
    3. Despite Tantek’s protest above, no data is actually being hidden from human beings—who are, after all, the audience that matters—nor does rendering the ISO date visible confer any informational advantage on the human being who is reading your page. Its presence in your document is purely a convenience to mechanical parsers, not your readers (as evidenced by the above discussion about the programmatic difficulties of localisation); to them, the class attribute is no less “visible” than any other.
    4. Finally, it neglects the requirements of certain visually-impaired users by presenting them with an incomprehensible string of digits, letters and symbols in lieu of sensible information:

      Instead of getting the human friendly message of “half a minute”, a screen reader user with expanded abbreviations configured would get something like “two thousand and eight dash zero four dash twenty six tee six colon fifty two colon twenty plus one o’clock”. Not a particularly friendly or intuitive expansion. In fact, it is materially incorrect. The time stated is 06:52, not one o’clock.

      This happens when the screen reader’s verbosity settings are such that abbreviation titles are read aloud by default. The justification provided for permitting this disorienting scenario is that most screen reader users do not change their settings. However, such users do exist, and their expectations are reasonable; without representative statistics demonstrating that their numbers are negligible this statement is insufficiently compelling to allay my concerns.

      Again, referring to my second point, this sort of improvidence seems to contradict the basic principles of microformats.

    Something you said earlier, Alistair, reflects how I initially felt about this issue:

    Tantek’s a very clever guy and having an internal inconsistency like that is unlikely. […] I’m more inclined to think that there is a facet of [Tantek’s] argument I’m missing.

    Indeed, Tantek is a clever fellow, and his opinion will be firmly based on justifiable premises. However, microformats are a subtle concept—transparently transcending the semantic limitations of HTML without compromising the specification or real-world requirements—and what we are discussing is a particularly tricky issue. It is distinctly possible that there are no solutions which unambiguously satisfy all criteria.

    Even if there is no panacea to these conflicting requirements, I remain strongly opposed to the abbr design pattern. It is not ideal semantically; it is not ideal in principle; it is not ideal to users; and it is not ideal for accessibility. The class attribute is not an ideal solution in principle, but it is semantically justifiable and does not compromise usability or accessibility in any way whatsoever.\

Comments are closed.