The title for an event I’m attending tomorrow is “2008-07-08T9:00Z00″; normal users will read simply “9 a.m.,” but Windows Eyes users with maximum verbosity set will hear “two-zero-zero-eight-zero-seven-zero-eight-tee-nine-zero-zero-zee-zero-zero.” Most people don’t know the ISO date format, so I’d be very surprised if many blind users, hearing that read out, conclude: “Oh, so the rehearsal is tomorrow at nine!”

I guess I agree with your points; hacks aren’t always bad, and it _could_ be argued that it isn’t misuse of the ABBR/title thing. (Although I do think it definitely is stretching things.)

I do think, however, that inserting stuff designed for machines in tags or attributes designed for humans is a bad idea. The stuff that overloads the class attribute is okay because no-one is meant to read that. The title attribute is clearly intended to be human readable.

I guess there’s just a wider issue of: why is it _that_ important to have valid HTML; perhaps if the microformats standards proposed breaking the HTML standard in a controlled and minimal way, that would be better for everyone. All that’s really needed here is to use a different attribute — preferably one that doesn’t already have a meaning.

Then microformats wouldn’t be intruding, and people would still be happy. Adhering to standards that are holding back progress isn’t really useful for anyone, especially if the new bits don’t interfere with the old bits at all.

agreed, issues around i8n and usability and accessibility do need addressing. I think the only robust, long term solutions will come with future iterations of HTML. I have some thoughts on that to be published shortly (if I find time to finish the article). In the meantime, we really have pushed HTML far past its designed capabilities - so these kinds of issues will show up increasingly commonly.

john

[abbr class=”dtend” title=”2009-01-01″]31 December 2008[/abbr]

Is anyone prepared to defend that as accessible, or usable, or even sane?

I first raised that issue on or before 20 January 2007, and proposed a simple resolution (albeit still using ABBR, at that point) in March of that year:

http://microformats.org/wiki/hcalendar-brainstorming#Simplification_of_date-end

So far, nothing further has been done.

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

or this method of marking up “”type” properties named English (in this case, “work”), in non-English pages (in this case, French):

[div class=”tel”]
[abbr class=”type” title=”work”]Travail[/abbr] :
[span class=”value”]0321596224[/span]
[/div]

In fact, it’s not even just about that; the real problem is the apparent attitude of most, if not all, of the small number of people who run the microformats “community”, to both accessibility and internationalisation.

The BBC case is just the tip of the iceberg.

“My central point here is the question - is this actually an accessibility, or is it a usability issue? I contend that it might best be characterised as a usability issue for folks using screen readers.”

I think about accessibility, and the more I do, the more times I see parallels with usability. So I’d raise the question of whether this particular issue has to be one or the other - can it not be both?

I’m particularly fond of the 4 principles of accessibility as outlined in the WCAG 2.0 document, which describes accessible content that is:

1.) Perceivable
2.) Operable
3.) Understandable
4.) Robust

to people with disabilities. For the abbr date-time pattern, it is peceivable, it is operable (due to the fact that there’s nothing to operate), and it is robust (so people can work their way around it if it presents a problem).

However, on the principle of understandable, there are issues like the two I’ve outlined in the previous comment. I think by these principles, the abbr datetime pattern can be classified as an accessibility issue, because it presents a problem of understandability of the content.

I accept that WCAG 2.0 is just a Candidate Recommendation, and not yet a full recommendation. But it does better specify and outline the issues of accessibility far better and more accurately than WCAG 1.0. And in a few months, this will be a fully-fledged recommendation.

So my answer is that this is most definitely an accessibility issue. Whether that’s a usability problem too, I don’t know. I suspect it might be, but that is just my opinion.

I think the tooltip use pattern you observe is a particularly strong observation. It predates the use of ABBR in this way, by possibly a decade in some cases, and is widely used.

My response to the issue of the use or misuse of abbr argument is that it’s essentially a theological argument akin to the dancing of angles on the heads of pins. HTML is highly impoverished when it comes to semantic expressiveness, and we have needed to mine it for all its worth. To me this is simply not a particularly interesting question (the accessibility stuff is of course, just this part I find kinda pointless).

I’m not particularly wedded to ABBR at all - that’s not been my point in this post and related comments. Rather, to address the issues around the issue in more clarity than some (but not all) have (both among the microformats community, and the critics of the pattern inside and less inside that community).

My very personal, with no evidence at all, reading of the situation is this is an attempt by the BBC, or some folks there, to have what has seemed to be a stalemated issue addressed. And it appears to have worked. Now, let’s try and learn as much from the experience as possible

john

Thanks for the reasoned and detailed reply - that was precisely why I wrote this longish article - because right now there is a distinct lack of either in a lot of the discussion around this issue.

Now, none of this article is to say we have the perfect solution to the problem in the abbr design pattern. My argument is that the BBC’s decision is no “lay down misere”. The argument is that the abbr design pattern (and often generalized to microformats) is inaccessibility. My point is that it is far more subtle than that, and that any decision made in the absence of understanding these subtleties is a poor decision. Now. I’m not arguing that the BBC made this decision in the absence of such understanding, but many other folks I’ve read abut this issue do lack those understandings.

Additionally , my track record in supporting accessibility is pretty high - I am very aware of the practical, legal and ethical aspects of accessibility, and have worked for nearly a decade to have developers make accessibility a priority for their sites. My purpose was by no means to belittle or undermine the issues, but to question some of the extreme claims and observations some folks have made, and provide some nuance to the issue.

The observation of “some versions of some screen readers” still stands. While the two readers you cite are highly dominant in market share, is that true of the versions of these readers with this particular feature as used widely? As far as I am aware, upgrading versions of screen readers is a lot less common than upgrading browsers, due to the significant cost of screen reader software. I’m happy to be proven wrong on this.

I have no objection to folks turning on this option - I observe that it is turned off by default (as far as I am aware) - so we are starting to see a use base of a subset of the screen reader base (later versions of popular screen readers) and then folks using these who turn on a very specific feature.

My central point here is the question - is this actually an accessibility, or is it a usability issue? I contend that it might best be characterised as a usability issue for folks using screen readers. To me, the threshold of accessibility versus usability is - is it not possible to access the information or services provided by a page by reasonable means. I guess this debate then comes down to whether listening to the ISO date time string is unreasonably annoying - afterall, for sighted and unsighted folks, there are many annoyances on the web. We make those tradeoffs all the time.

The point around misread information and timezones is a far more compelling one - indeed, if it is misread, then that is a big accessibility issue. I’d need to take some time to see where the error is taking place - with the markup, or with the reader making an assumption.

Thanks for help clarify the issue further. Aboveall, the value in this discussion is to help ensure the next generation of solutions to these problems learn from the the lessons that episodes like these teach us.

john

The other strawman here is the “but look at the benefits” part. Are you suggesting that these benefits are intrinsically tied to the (ab)use of the ABBR pattern’s use for date/time and things like geo coordinates? If an alternative solution was officially adopted, the ABBR pattern uses mentioned deprecated, and the handful of microformats-consuming tools updated, would those benefits be impossible to achieve?

The idea of microformats, and the usability (and “usefulness”) improvements they can bring to users is not being disputed here.

In fact, I can see how microformats, coupled with the right tools, can improve usability *particularly* for users with disabilities - instead of having to work their way through a page, or trying to understand some of the complex information presented, they can be given very clear and simple options (as you mention, adding things to their calendars etc).

You seem to be making a clear distinction between *usability* and *accessibility*. I’d say that modern definitions of accessibility *encompass* usability, and that in fact accessibility is all about making web resources *usable* for all. Otherwise, we’re simply talking “technical accessibility”.

That would be current versions as well as the previous version of both JAWS (from Freedom Scientific) and Window Eyes (from GW Micro). In usage terms, JAWS and Windows Eyes together are the totally dominant screen readers in the USA. In the UK, there is a ‘Opera-like slice’ of the market using Dolphin’s Supernova/Hal.

“there is an option (as far as I’m aware off by default) to enable the screen reader to read out the value of the title attribute of abbreviation elements.”

Why would people want to enable such an option? What circumstances could enabling it:

1.) be possibly useful;
2.) be of no use;
3.) be a hinderance?

Please give these two questions some serious thought and consideration. After that, maybe the rest of this comment may make more sense.

“I’ve no doubt that this is a genuine problem for some users of these screen readers (though in absolute terms I suspect the number of such users is by comparison even with folks familiar with microformats very small).”

Many countries in today’s world have legislation that protects minority groups, particularly from a majority group (natural or artificial) trodding over the rights of that minority. It’s part and parcel of guaranteeing the inalienable rights of all people to participate in society as equals.

People with disabilities are one such minority group, and a group that has been marginalised purely because they are disabled. Legislation in the modern world helps protect their rights, and hopefully prevents the majority from just locking them out of society.

Minorities have rights too, no matter how small a group they are, whether they are vocal or not - as long as they are legitimate members of our human-based society, they have rights, especially the right to participate as equals within society (both online and offline).

“But, I’d personally place this in the annoyances category - I doubt this makes such pages inaccessible, rather somewhat more annoying than some pages to use with a screen reader.”

The types of barriers that are created by a full ISO-timestamp are:

1.) A sequence of numbers with no obvious clue as to how they should be interpreted.
2.) The heuristics of a screen reader that identify certain data segments as formatted data.

The more obvious problem of the two, the first one, is debatable whether its just an annoyance. The one point I will make on that note is this:

Surely the expansion of an abbreviation should introduce more clarity, rather than less? If an abbreviation expansion hinders understandability, surely it’s better off semantically from not marking it up as an abbreviation in the first place? Otherwise, what’s the point?

On the second scenario: In your example, the timezone segment is picked up at least two newish versions of JAWS as a time, so they read out something like ’seven o’clock’.

If the actual event time is 1:45pm, then hearing “seven o’clock” being read out could confuse people into believing the event starts at seven o’clock.

To me this particular case isn’t just an ‘annoyance’, it’s offering up information in a confusable way, and in a way where the user can get the wrong information.

This is the same problem as someone who marks up the text ‘BBC’ as an abbreviation and uses “Associated Press” as the title attribute of that abbreviation. Yes, it might annoy some people, but the overriding problem is that the expanded information is incorrect.

Considering that the main configuration of expanding abbreviations is going to be to replace the abbreviation with the full expansion, most of the time, people are going to believe the expanded text that’s read out to them.

Sure, I take the point that in the case of the abbr datetime pattern, that the best user experience is when abbreviations are not expanded.

But, consider what that step actually means. Isn’t one of the bastions of microformats the desire to squeeze out as much benefit from structured and semantic markup? What’s the point of implementing microformats if the recommendation is for end-users not to benefit from it?