switching from ABBR to a humble SPAN would alleviate the problem - it solves the screen reader issue anyway. simple and elegant…but doesn’t meet with the approval of some microformateers and is therefore rejected.

your third way seems quite over-engineered, to be honest.

also, if a script removes the title etc dynamically, i believe extensions like Operator and any similar “in-browser” solutions (bookmarklets, favelets, etc) will also be affected, as you’re pulling the DOM carpet from under their feet.

Very interesting idea. Personally, I tend to agree with Patrick regarding the WaSP’s proposed SPAN alternative.

However, refreshing to see someone thinking about the problem and suggesting solutions, rather than the current (not to mention ridiculous and unacceptable) state of stagnation on this issue.

“Applying this approach to dates and times seems very logical.”

I’ve always thought it illogical because the title attribute of <abbr> is supposed to expand the content of the tag, whereas the date design pattern in most cases is a contraction of the content of the tag, so I think Patrick’s solution is the best.

But as you say, it could be some time before a final solution is found, so much as you suggested for ways to use HTML5 semantics via classnames now rather than waiting, a little bit of extra markup might be necessary to satisfy as many people as possible.

The abbr date design pattern is clever, but the semantics of it seem backwards at first glance. If the point of an abbr’s title attribute is to provide an expanded version of the abbreviated content, then saying that “2009-11-20” is short for “November 20, 2009” seems backwards to me. I’d be very interested to hear your thoughts on that. Thanks!

I think it’s great that we are finally thinking about working round this issue. Never been entirely taken with the idea that the current implementation of vEvent is the best - locking a microformat to a particular HTML element and even then one that is perhaps stretching the boundaries of semantic markup (an ISO time may be an abbreviation but only in the sense that my National Insurance Number is an abbreviation for my name - i.e. technically related but pushing the semantics association a wee bit).

Anyway, onto your approach. Not entirely in agreement but that is mainly because it is addressing an issue with how microformats are currently implemented rather suggesting how they might be (or could better have been) structured in the first place. To me this solution is saying “this code is inaccessible, do you want to avoid it” rather than attempting to make the microformat accessible in the first place.  However, completely understand what you are proposing is a workaround for the current situation and its potential limitations.

Still, great these things are being thought about and discussed outwith the often confined discussions of the microformat and accessibility communities.

Microformats are also an evolutionary process. HTML5 offers us the datetime attribute. Microformats are designed to work in HTML4 and up, but as new technologies such as HTML5 offer potentially better solutions those will be explored and used when possible.

The perceived issues with the date-time pattern should not be a barrier to adoption. As time progresses better solutions will become available depending on capabilities.

This is also an opportunity to take the opposite approach. Instead of casting stones and saying things like ‘If screen readers do X then we shouldn’t do Y’ we should try to invert the issue. We are doing Y, can we lobby screen readers to change the way they do X?

Offering semantic information in HTML is a benefit for screen readers. Imaging if they were microformats aware and would announce “There are 3 heading, 6 links and 2 events on this page”.

We should look to promote good semantic behaviours and educate older technologies and browsers to take advantage of them.

additionally @Jeremy “Patrick, the issue with using span or any other element is that the title attribute has a different semantic meaning on those elements (as per the HTML spec)”

and this is the crux of the argument…the staunch belief that it *has* to be ABBR or nothing else. that nothing else approaches the perfect semantic purity of the ABBR pattern, even in the face of noted problems and sensible potential alternatives (title pattern). it’s this fundamental chasm that we’ll never manage to cross…until screenreaders/AT cave in and adapt microformats’ “more better semantic” way.

Andy, sure…we can try and find ways around the problem, but it’ll always be a suboptimal bandaid compared with actually solving the problem itself. And it’s infuriating that the problem could be removed or at least mitigated quite easily if the microformats community stepped out of the ABBR-semantics-trench, rather than ignoring the issue, denying the issue, or basically saying that they’re right and all screenreaders/AT should follow *their* reasoning.

Anyway, I’ve said my piece again for this year, and I’ll exit stage left until same time next year.

// uFtoggle plugin v1.0 - toggle microformatted dates
(function($){
    $.fn.uftoggle = function() {
        var state = 0; // titles on
        var els = $(".dtstart,.dtend,.bday");
        els.each(function(){
            $(this).attr("ufdata",$(this).attr("title")); // storage
        });
        $(this).click(function(){
            if ( state == 0 ) {
                els.removeAttr("title");
                state = 1;
            } else {
                els.each(function(){ $(this).attr("title",$(this).attr("ufdata")); });
                state = 0;
            }
        });
    }
})(jQuery);

// Usage
// $("a.uf-toggle").uftoggle();
//
// <a class="uf-toggle" href="#">Using a screen reader? (Toggle microformatted dates on/off)</a>


// uFoff snippet v1.0 - remove microformatted dates
$("a.uf-off").click(function(){
    $(".dtstart,.dtend,.bday").removeAttr("title");
});

// Usage
// $("a.uf-off").ufoff();
//
// <a class="uf-off" href="#">Using a screen reader?</a>

That was fun - the first one could probably be done better but what the heck.

@ Jeremy Keith: “Just to clarify, the BBC didn’t abandon hCalendar because of screen reader concerns, they abandoned it because of the tool tip.” I’m pretty sure it’s possible to suppress the browser’s default title display when you hover on a link or abbr tag using javascript. I’ll post again if I find out.

Good article Andy :)

1.  Is it allowable to preface the ISO datatime data with an indication of what it is, to help with both the screenreader issue and the tooltip issue.  So we’d have title=“Datetime:YYDDMMTHH:MM:SS”.  If it’s destined to be parsed by a machine, it’s trivial for the machine to remove the beginning string.  I also realize it is not trivial for people to change exisiting microformats,, but at least it would be a step forward.  I would think that the tooltip issue is more of a problem in sheer numbers than the a11y issue.

2. Trying to guess how screenreader users use their software is a losing battle, so unless someone surveys screenreader users and gets hard numbers, the question of how many people are affected like by this is really unknown, isn’t it?  The vendors don’t release any data as far as I can tell.  I’d like to see some sort of usage stats collected and published by those vendors that tell us WHAT options people turn on and off in JAWS and other readers.  Let users opt in/out as they want, but give us some hard data saying X out of Y people use their reader with these options: optionA, optionB….....  Or publish some sort of profile database that could be analyzed.

3. 3 years is a ridiculous amount of time for any problem like this to persist.  So any effort at a solution is a good thing, but I am not a fan of creating separate content unless there is no other way for someone to get to the original content.  In this case, it’s more of an annoyance (I would guess, and that’s only a guess) that a real inability to get to the information.  I’ve only got ‘access’ to one person who uses a screenreader, so I’m going to ask and see what he says about this.  I’ll try to post back if he’s able to give me an opinion.

You’re right, Andy. Who said what when is immaterial. And yes, there is much too much ideology.

But ideology is the only reason that the span title=“big fat ISO date” isn’t adopted by the microformat people. *Nothing* is lost by doing that, except tooltips and potential problems for screenreader users who have set their software to expand abbreviations.

The suggested abbr workaround for Microformats is extra work, but is not the ultimate solution for the problem. My suggestion: a ‘transitional version’ of Microformats.

To me, Microformats are a useful mechanism to add machine-readable meaning to information on websites. The way it uses attributes is ingenious and has brought the use HTML to a higher level. The use of the abbr tag is an example of overstretching the usefulness.
Despite its ingenuity, I’ve always considered Microformats as a ‘temporary workaround spec’; to be used until something better comes along.

Since October 2008, RDFa is a W3C recommendation. It can do everything that can be done with Microformats, and more. In theory, that is.

[I know I’m risking a ‘de jure’  vs. ‘de facto’ standards dispute here, but I suggest it anyway]
Hasn’t the time come to start a transition to RDFa? And to develop a ‘transitional version’ of Microformats, to ensure the interoperability with other Semantic Web initiatives that will hit the web front-end in the near future? It’s better to join forces than to fight about who’s right and who isn’t.
In practice, especially governments will pick de jure over de facto when choices have to made and will certainly not choose both.

Some interesting additions to this topic on the question I posted to stack overflow this morning.

Christoph mentions using the <var> tag to supply an alternative form of the date as per the specs:

VAR:

Indicates an instance of a variable or program argument.

Check the link above for his full suggestion.

s/Removing the title attribute defeats/Removing the title with JavaScript attribute defeats/

Lets just clarify something. Microformats help people by semantically marking up content. The conventions for datetime pattern already preface the title expansion with class names .dtstart, .dtend, .bday.

Striclty speaking, unless a screen reader understands that a grouping of numbers is in fact a date or time, it will not know how to read this in a sensible way. For instance, 01/19/2009 is no better than the ISO format 2009-01-19.

What Microformats does is provide a standard way for machines, as well as people, understand what this is. If the makers of screenreaders would adopt support for Microformats, the could easily swap the expansion of datetime elements with the user defined format. In the end, this is the only means by which you overcome accessibility issues with both unfriendly number strings and localization. Looking to the Microformats community to fix this alone, is not that feasible. Regardless of expansion of abbr, a user using a screenreader is still subject to the authors localized datetime format.

For those who think it is wrong for developers to push browser makers and screenreader makers to change their way of doing things, where have you been for the last 20 years? That’s how it’s always been. Take Web Standards for instance.

So, completely separate to this blog post there has been active work on this. After a fairly intense bout of work, I’ve put together a test that we need assistance with.

The test is documented in full here, complete with introduction, sample tests, pattern documentation and so on. I’ve gone out of my way to try and ensure this is the only wiki page you need to get up to speed on this mark-up pattern, justifications and parsing rules, and the tests of course. I want it to be as accessible as possible to everyone, rather than needing to cross-reference multiple pages:

http://microformats.org/wiki/value-excerption-value-title-test

Please, take a look and contribute if you can spare a little time.

We had discussions last year about specifying the full parsing rules of value excerption from hCard into a more generic pattern (it’s already supported as such in some µf parsers). As part of that specification process we can do something that offers a solution to the inclusion of required machine formats like ISO dates and duration, and keywords like ‘cell’ and ‘fax’ in the telephone ‘types’ enumeration.

I regard all of that as part of the same problem; where sometimes it’s just not feasible to mark-up just the text content in the page, be it translation into other languages or the variance of writing style and formatting.

Now, because the impact of this pattern is so substantial and offers alternatives to such ‘popular’ issues like this, I’ve put together a testing effort beyond anything we’ve tried before. I’ve had feedback on similar mark-up being tested already by various people in the accessibility community, so I’m confident, but this an attempt to do as big a test in public as possible. I’d like to see results for all sorts of weird and wonderful combinations of browsers, assistive technology and publishing tools.

If you think you can help us out with a little bit of time to run some tests, I for one would be tremendously grateful.

I know it looks pretty bad that it’s taken so long to offer new options, but please don’t dismiss that some of us have poured a lot of effort into the problem at various points.

@patrick h. lauke “but i thought microformats were meant for the here and now, and not for some hypothetical future”

They are indeed. My point is not that the current datetime pattern does not present issues in the here and now. It does, hence Andy’s proposed workaround.

My point is, the accessibility concerns around dates are not uniquely tied to Microformats and with this proposed workaround and the addition of the javascript workaround @Robert O’Rourke proposed, the Microformat datetime pattern wouldn’t present any access concerns outside of those presented by dates and times themselves. Moreover, the semantics of Microformats provides an opportunity for browser makers and screenreader makers to better serve their users, by adopting Microformats.

I would also like to mention that my reference to localized time formats was geared towards screenreaders, not normal browsers. User having a date read to them by a screenreader, as apposed to reading it themselves, would benefit more from being able to set a localization preference. Or at least that would be my assumption. Adopting Microformat support would allow for this.

Lastly, I would like to point out that there is a new proposal on the table, to address this concern. I encourage anyone who is seriously interested to check it out. While it doesn’t sit with me as well, on a strictly semantic front, it does seem to solve the concerns we all have.

http://microformats.org/wiki/value-excerption-value-title-test