hAccessibility

By James Craig | April 27th, 2007 | Filed in Accessibility, Accessibility TF, Emerging Technology, Opinion, Web Standards (general)

Skip to comment form

By Bruce Lawson and James Craig. (German translation)

Microformats are a great idea. They allow the embedding of parsable, semantic data (like contact information and event details) into regular web pages. With the right plug-in, that information can be saved directly to your calendar program or address book. Like Microformats, a portion of web accessibility is about making web pages more machine-readable, and by doing so, making them more usable to human beings.

Most of the time, Microformats and the principles of accessibility coexist harmoniously.

Abbreviations in Microformats

HTML has an abbr element used for abbreviations. This element is used by assistive technology, including the most popular screen readers, to expand abbreviations such as ADA and lbs. The benefit to disabled users is that, the screen reader can decipher what the abbreviation means and say the appropriate, expanded version. For example, when a sighted individual sees, “20 lbs,” he will think, “20 pounds.” A screen reader will either try to pronounce the phonemes literally, or spell it out, in this case as “el bee ess.” The abbr element is the method to give the additional information (“pounds”) that makes it more comprehensible to the person listening:

20 <abbr title="pounds">lbs</abbr>

Microformats recommends the use of an abbr-design-pattern which, in some circumstances, is completely in line with the proper use of the XHTML <abbr> element. The Microformat, hCard, can use the abbr-design-pattern to specify country codes as fully-expanded, country names.

<abbr class="country-name" title="Japan">JP</abbr>

In this use, the benefit of <abbr> is twofold: screen readers can speak the word, “Japan” to vision-impaired users, and Microformats parsers can understand the address is in the country of Japan. This is the intended use of <abbr>; it’s accessible, and it’s extendable as a Microformat design pattern.

And the creator(s) saw that it was good.

hCalendar’s Original Sin

The creators of Microformats strayed from their accessible, semantic intentions when they extended the abbr-design-pattern to the datetime-design-pattern. This idea, though paved with good intentions, was a workaround for a browser bug and, like many others, has unintended, harmful side effects.

The datetime-design-pattern is a way to show a readable date (such as “March 12, 2007 at 5 PM, Central Standard Time”) to humans and a machine-readable date (such as the ISO 8601 formatted “20070312T1700-06”) to the Microformat parsers. When crossed with the abbr-design-pattern, the result is this.

<abbr class="dtstart" title="20070312T1700-06">
 March 12, 2007 at 5 PM, Central Standard Time
</abbr>

As you may have guessed from the previous examples, screen readers expanding the abbreviation will try to read the title element. JAWS helpfully attempts to render numeric strings into human-readable numbers, so “1234” is spoken “one-thousand two-hundred thirty-four” instead of “one two three four.” Given a title value of “20070312T1700-06”, JAWS and Window Eyes both try to read an ISO date string never intended to assault human ears:

Twenty million seventy-thousand three-hundred twelve tee seventeen-hundred dash zero six. (JAWS 8 on IE7: MP3, Ogg)

Though it may sound silly, the screen readers’ behavior is implemented according to the HTML 4 specification.

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. (HTML 4, ABBR)

Unlike the ISO date format, the “full or expanded form” is intended to be human-readable. Yes, machine-readable, but for the consumption of a human, and in this case, spoken literally to a human. The Web Content Accessibility Guidelines (WCAG) explicitly defines the expansion of abbreviations as an accessibility advantage, and the most popular screen readers do so.

If an abbreviation fell in the forest…

There are debates about the semantics of the <abbr> element, and everyone is entitled to his own opinion. Is it legitimate to say “5 PM on January 5th” is an abbreviation because it omits the year? Probably. Is “5 PM on January 5th 2006” an abbreviation because it omits the time zone? Perhaps. We don’t contest that those human-readable dates are “abbreviations for a full-qualified date and time.” We contest that, according to the HTML specification, an ISO date string is not a legitimate, human-consumable, expanded form of that date and time.

What isn’t in question though, is that the use of an ISO 8601 date in an <abbr> title attribute renders the content inaccessible to users of assistive technology.

Accessibility, “in the wild.”

The Microformats group is vehemently opposed to hypothetical situations as the basis for a Microformat change. Real-world examples are often requested, or as they commonly phrase it, examples “in the wild.”

We remind the Microformats group that real-world screen reader implementations existed, according to spec and “in the wild,” long before the Microformats design patterns, and we encourage the group to respect those real-world implementations, rather than focusing on hypothetical situations such as:

In the future one could imagine a CSS rule and perhaps a CSS property or two that would automatically transform and present such ISO8601 dates from ‘title’ attributes of <abbr> elements into whatever datetime format the user preferred… (source)

What’s the Alternative?

The point of this article is not to offer a solution, but to shed light on an inaccessible practice that must change. We encourage the Microformats group to consider the problem, whether or not they accept any of the following, proposed solutions. That said, we offer these ideas as carrots to accompany our cudgel.

Originally, we considered the datetime attribute, found only on <ins> and <del> elements, and wished that we could use the datetime attribute instead of a title on a span, except it would be invalid code. Some have proposed using custom attribute namespaces for Microformat data, but the Microformats group is strongly opposed to this, and for a simple and valid reason. Microformats are intended to be “simple conventions for embedding semantic markup in human-readable documents.” Opening the floodgates to custom DTDs and namespaces would quickly raise the complexity level of Microformats to that of RDF, greatly reducing its adoption and therefore its relevance.

So we went back to basics: the existing elements and attributes of plain old semantic HTML.

The datetime-design-pattern was initially proposed as a workaround for a browser bug where the object element and the data attribute were a more appropriate choice. The authors knew this, but could not determine a way to structure it without browser bugs.

We looked again and found a way for Microformats and accessibility to play nicely once more; a way inspired by Microformats’ own empty object include-pattern.

The Object Example

<span class="dtstart">
 March 12, 2007 at 5 PM, Central Standard Time
 <object>
  <param name="value" value="20070312T1700-06" />
 </object>
</span>

The markup is still fairly simple, it retains its semantic purity, and it’s accessible. But…

What’s the Catch?

The catch? Okay. Even when the browsers are instructed to hide the <object>, there are still some minor display bugs in Internet Explorer (screen shot) and Safari (screen shot). At the time of this writing, Internet Explorer (version 7) doesn’t honour the space characters in the text around the object, and Safari (WebKit nightly) adds extra line breaks.

Many developers could overlook these flaws. Most designers would not. It’s an easy CSS fix: wrap the object in one extra  element and hide it instead.

The Hacked (Ugly) Object Version

<span class="dtstart">
 March 12, 2007 at 5 PM, Central Standard Time
 <!-- the extra span element to be hidden -->
 <span style="display:none">
  <object>
   <param name="value" value="20070312T1700-06" />
  </object>
 </span>
</span>

Unfortunately this code sample fails the “ugly” test and isn’t as rooted in simplicity as we’d prefer, so what about some other, simpler variations?

The Span Title Version

<span class="dtstart" title="20070312T1700-06">
 March 12, 2007 at 5 PM, Central Standard Time
</span>

The Empty Span Version

<span class="dtstart">
 March 12, 2007 at 5 PM, Central Standard Time
 <span class="value" title="20070312T1700-06"></span>
</span>

Like the abbr-design-pattern, both of the previous examples use the title attribute to store the ISO data. The second version just avoids GUI tool tips. With custom verbosity settings, it is possible that a screen reader user may hear the text spoken in either example, but that circumstance is much less likely than a fully-expanded ABBR.

We are not recommending the abolishment of the abbr-design-pattern, just its misuse. Again, we encourage the Microformats group to consider the problem, whether or not they accept any of the proposed solutions. All of the examples listed are more accessible than the abbr-design-pattern. Check the final examples for details.

Like we said, we like Microformats. Their simplicity and usefulness means that they’re on the verge of widespread acceptance. We urge the Microformats community to re-evaluate the accessibility of the specification now, before the technology goes mainstream and it’s too late.

This article was co-authored by Bruce Lawson and James Craig, and incorporates feedback from other members of the Accessibility Task Force.

(Added 13 February 2008) “Configuring links in Screen readers” by Mike Davis looks at the screenreader accessiiblity of the Microformat Include Pattern. (Bruce)

Your Replies

#1 On April 27th, 2007 5:36 am WaSP Member adactio replied:

This is something that the microformats community is aware of and has been looking into.

However, I think it’s fair to say that microformats represent a golden opportunity for the manufacturers of assistive technology. The datetime abbreviation pattern uses an easily recognisable string to represent the time. In fact it’s an ISO standard so there’s plenty of documentation out there. It strikes me that it would be trivially easily for screenreaders to parse this data and read it back in a human-friendly manner.

Displaying dates is a preference usually set at the Operating System level. Wouldn’t it be great if assistive technology read this preference and used it to read back the contents of the title attribute of an abbr element that matches the datetime pattern?

#2 On April 27th, 2007 6:21 am Chris Hunt replied:

Hear Hear!

The microformats community may be aware of this, but what are they doing about it? It’s all very well saying that the assistive technology people have a golden opportunity to ignore the HTML standard and treat abbr elements differently if they have particular values in their class attribute, but is that likely to happen, and is it such a good idea anyway?

From what I’ve seen of the discussion, people seem particularly attached to using abbr in this way because it was Tantek’s idea. Well, he’s a smart guy, but he can still get things wrong. Rather than wait for new HTML standards and new versions of JAWS and whatever other deus-ex-machinas might come along and solve this issue, let’s do something simple and practical today (isn’t that what microformats are all about?).

Lots of microformat values can be attached to multiple elements, so why do dates have to be abbrs? Just free this up, and those who want to cling hard to the abbr dogma whatever its side effects can do so, whilst those of us that would rather be flexible to accommodate people instead of computers can use spans instead.

#3 On April 27th, 2007 6:33 am Bruce Lawson’s personal site : Microformats and accessibility replied:

[...] We jointly wrote up our results in a paper called “hAccessibility“, which James published today. [...]

#4 On April 27th, 2007 6:45 am Jon Tan replied:

Colleagues and I have been looking at this for a while too.

One interim thought was to prepend the title attribute value with something that added context to the ISO date. Suggestions were “ISO date: *”. However, “ISO” in itself is an abbreviation. Another was the more verbose “International Standards Organisation date: *”, but it’s verbose. However, as an interim it could help screen reader users identify what the stream of digits is? I’m not sure how this may effect microformats parsing though?

I like the idea of a fix from the assistive technology creators themselves because no matter what solution achieves consensus, the ISO standard date itself will never be particularly human readable even when you understand the notation.

#5 On April 27th, 2007 8:05 am Patrick Griffiths replied:

I’m a little surprised by Jeremy’s response to this, which reminds me of the newbie developer’s “well, I’m doing it right – it’s the browser’s problem, not mine”.

I have a more general problem with abbr and hCalendar, which I have had for years, which has prevented me from using the microformat. Unfortunately it is a philosophical rather than an “in the wild” practical problem, although that’s good enough for me to turn my back on that particular standard.

When I use times and dates, they’re not always abbreviations of a longer, full time date. If I have a time in a table column headed “7th June”, for example, when I write that time (such as 3pm) I only mean that time (3pm) – I don’t mean that time on that date (3pm, 7th June) because the date is provided by a table header cell (that’s why we have matrix tables – so we don’t have to write out everything every time). I’m all up for providing more information (and the abbr element in the right place), but using abbr to say “3pm, 7th June” is an expansion of “3pm” is simply misusing abbr, in this case.

That aside, I’m really glad to at least see the accessibility point raised, which is one I have raised myself with more than one prominent microformat community member in the past.

I’m also glad to hear it is “being looked in to”, although it’s taking some time!

As for the solution, adding extra content with an object just seems to miss so many points, especially when the content is already there – can’t we just use span? Like Chris said, free it up!

#6 On April 27th, 2007 8:14 am WaSP Member adactio replied:

Patrick, I’m not saying that the abbr pattern doesn’t need examining. I am certainly not saying “it’s not my problem.” I just wanted to point out that this situation while currently a proble for screenreader users *also* represents an opportunity for screenreader manufacturers to introduce benefits for users in the future.

I agree that the issues with the abbr pattern need to be addressed but I hope that it will be something along the a lines of introducing an alternate pattern qualified with “until user-agents…” with an eye to returning to the abbr pattern as-is in the future when the current accessibility issues caused by the current screenreaders have been ironed out.

#7 On April 27th, 2007 8:22 am Jon Gibbins replied:

I’ve long been meaning to blog about this very issue. I did a bit of testing with microformat’s datetime-design-pattern back in October while testing screen reader handling of dates.

While using the abbr element may provide some extra semantics to a date, the text date that you mark up with the datetime-design-pattern can be quite varied. In the end, you’re simply providing an alternative representation of a date, not necessarily an abbreviation of it. And I too believe that the content of the abbr title attribute should be human-readable. At the moment, I’ve been using span instead of abbr. The title attribute may be used to provide more detail on a link, so the title of the span gives more detail (a machine-readable date) on the date.

Ideally, I guess we’d have a ‘date’ element or an ‘alt’ attribute on some more appropriate element. But if we could do that, we wouldn’t need microformats.

#8 On April 27th, 2007 8:28 am Patrick Griffiths replied:

Jeremy – I certainly understand you’re not saying it’s not your problem. I think we need to find out how we as authors can solve the problem, though.

The main point I am making is that abbr can simply be the wrong element to use – it isn’t adequate in every case, such as the one I highlighted. Even if the accessibility problem were tackled with a stop-gap and an “until user-agents…” caveat, it doesn’t tackle the problem that a time or date is not always an abbreviation of a full time date stamp.

#9 On April 27th, 2007 8:59 am Joe Clark replied:

This abbr business provably isn’t working and shouldn’t be defended, W3C-style, by microformat zealots. The horse has bolted from the stable.

#10 On April 27th, 2007 9:28 am Daniel Morrison replied:

Joe Clark is right that abbr isn’t working.

Since Microformats are not “an attempt to get everyone to change their behavior and rewrite their tools” it is wrong to wait for screen readers to catch up. Instead, the community has a chance to be pragmatic and change. I’m certainly not excited about changing, but it would seem to be the right thing to do.

#11 On April 27th, 2007 9:44 am WaSP Member adactio replied:

Joe, it doesn’t add anything to discussion to label people as “zealots.” The otter has swum from the holt. The squirrel has scampered from whatever sort of domicile squirrels live in.

#12 On April 27th, 2007 9:59 am pauldwaite replied:

I could understand sticking with the abbreviation pattern if the screen readers were behaving contrary to the spec. From the excerpt above, I don’t think they are (happy to be corrected by someone with a closer knowledge of the spec though).

Whether the abbreviation element or a title attribute is more appropriate for supplying an ISO date seems like a judgment call upon which reasonable people could disagree. But seeing as this common screen reader behaviour has been noted, I’d favour the title-on-a-span solution.

Do the current microformats specs require an abbreviation attribute for the date? Or is the given class (e.g. dtstart) all that’s required?

#13 On April 27th, 2007 10:03 am Jon Gibbins replied:

Paul, microformats specify that datetimes be marked up with abbr elements and with the ISO formatted date as the content of the title attribute.

#14 On April 27th, 2007 10:03 am pauldwaite replied:

Oh, and apparently tree squirrels either live in “dreys” (bird-style nests built on a tree) or “dens” (a cavity within a tree).

http://www.squirrel-rehab.org/faq.html#eleven

#15 On April 27th, 2007 10:04 am pauldwaite replied:

Thanks Jon. I’ll have to contemplate why a supposed web professional such as myself is willing to look up squirrel habitats, but not microformat specs.

#16 On April 27th, 2007 10:11 am Jon Tan replied:

Jon: Not sure I agree with your interpretation of abbr in this case. It could be argued that the ISO date time as a standard in the title is the full version of an abbreviated regional notation on the page like “27/04/07″, or “04/27/07″ if you’re in the US.

Joe: I don’t see anyone defending the current problematic design pattern. Definitely no “zealots”. What are you ideas for a solution?

By the way, did you guys know that a baby echidna is called a puggle?

#17 On April 27th, 2007 10:37 am John Arthur replied:

As I understand it (though that could be a huge flag right there), one of the tenants of Microformats is that the content shouldn’t be hidden, or at least completely. The abbr tag encompasses a human-readable form AND the machine-readable definition. The Object model that Microformats suggests (or the one I skimmed before writing this) references contained information elsewhere on the page, so it still works.

I don’t like the object model suggested here, as well as the empty span, as the machine-readable content is “seperate” from the human-readable. The span-title method is much more in line with how I see the intention of Microformats. Just US$.02.

I know I’m looking ahead more than at the current situation, but am I reading the specs wrong, or will we be able to actually use the content attribute in a span element with XHTML2?

And I agree with Jeremy that it would be excellent if a way were developed for screen readers to read ISO format. This doesn’t mean the abbr element should be used, and I don’t think Jeremy intends that, either. But considering time zones, various methods of date representation (Y/M/D vs M/D/Y vs Month Day vs. …) this would be a great bit of functionality.

So, please tell me where I went wrong. Thanks.

#18 On April 27th, 2007 10:37 am Jon Gibbins replied:

Jon: I’m not necessarily against using the ISO date format in title attributes, only on an abbr, which in my view should be human-readable to aid accessibility, i.e. [in my pedant mode] used to expand proper grammatical abbreviations. We don’t go sticking ISO dates into our copy, do we?

#19 On April 27th, 2007 10:59 am John Lascurettes replied:

Though it might be a “golden opportunity” of assistive devices to recognize an ISO format, let’s not forget that their products are often prohibitively expensive. It’s not like the end users are able to upgrade with every incremental improvement like most of us do with our free browsers.

#20 On April 27th, 2007 11:02 am Martin replied:

Let’s not kid ourselves. There are definitely “zealots” or purists in this blog.

Microformats is just a standard and certainly it won’t please everyone nor does W3C standards.

#21 On April 27th, 2007 11:12 am Jon Tan replied:

Jon: That’s true but all regional date notations are conventions not rules. So, I might start using the ISO date time, if only to start the long lonely road to internationalisation!

Humour aside, the main issue here for me is the ISO date time is not human readable therefore shouldn’t be available without context. The abbr title attributes are wrongly used in the pattern but if an ISO date time is used – and users could display it in a tool tip or have it read out – context would still be needed to explain what to most people would be a weird set of numbers, letters and punctuation. Prepending the date time and use of a lang attribute to help agents in the future might do that.

#22 On April 27th, 2007 11:19 am Jon Gibbins replied:

Jon Tan: I agree – and as John Arthur commented – if microformatted content shouldn’t be hidden from users and an ISO date format is contained in a title attribute, it should definitely be given context in some way. I just don’t think abbr is the right element for the job.

Incidentally, JAWS (the screen reader) can be configured to read expansions provided in title attributes of abbreviations independently of other elements, so a title attribute on a span is not necessarily read out.

John Lascurettes: A good point. However – and it may be pessimistic of me – it seems to me that the main assistive software manufacturers are unlikely to make implementations to help here without there being substantial incentive for them. Take Aural CSS for example. It could be a really useful tool for accessibility, but support has not been implemented though the standards exist.

#23 On April 27th, 2007 11:31 am WaSP Member adactio replied:

I’d like to point out that the example used in this post is just one way of marking up the ISO date in the title attribute of an abbr element: title=”20070312T1700-06″ (actually this should include seconds and be: title=”20070312T170000-06″)

The abbr pattern also allows you to mark up the same date as: title=”2007-03-12T17:00:00-06″

James, Bruce, would I be right in thinking that screen readers are better at dealing with this format? In other words, what’s read aloud makes more sense? If you could repeat your tests using this format, that would be very helpful.

If, as I suspect, this formatting sounds more sensible, then I think that the microformats documentation should (and will) be updated to encourage the more verbose abbreviation (with dashes and colons) and discourage the condensed version.

Also, not that I want to keep nitpicking your specific example, but I feel it’s worth pointing out that most uses of the abbr pattern aren’t as fully-formed as yours. It’s quite common (and perfectly fine) to leave off the timezone and assume that the event is in the same timezone as the consumer: title=”20070312T170000″.
If that is reformulated as: title=”2007-03-12T17:00:00″, then wouldn’t you agree that the screen reader difficulties are significantly mitigated?

#24 On April 27th, 2007 11:45 am Jon Gibbins replied:

Jeremy: I already have results of testing that date format – I’d say it’s better, but still not ideal. Where I think the datetime deisgn pattern is lacking is in providing context to what is otherwise just a bunch of numbers.

#25 On April 27th, 2007 11:47 am Jon Gibbins replied:

I should say I have “part-results for that test” – see test 7e) on that page.

#26 On April 27th, 2007 11:56 am WaSP Member adactio replied:

Jon, those test results are very useful and, to my mind, very encouraging. I’m pleasantly surprised that Jaws reads 1998 as “nineteen ninety eight” rather than “one thousand nine hundred and ninety eight”.

I’ve raised the issue of discouraging the condensed version on the microformats-discuss list:
http://microformats.org/discuss/mail/microformats-discuss/2007-April/009350.html

#27 On April 27th, 2007 12:02 pm Patrick Griffiths replied:

As my point is being ignored, and there’s a waft of stubborn zeal in the air (I’ll stop short at using the term zealot ;) ), let me highlight the point as another accessibility problem:

Even if a screen reader *does* read out the abbreviation title accurately, let’s say you have a day-long event schedule in a table, which is quite common mark up for such a situation.

In one column you have the times of the sessions throughout the day. If you’re making your way through this with a screen reader, do you want to hear “2007-03-12T[insert time]” *every* time you start a new row? Of course you don’t – it’s stupidly repetitive. It’s as stupid as writing out the full date in every cell. And what if they’re coupled with scope or header on top of that?

How about getting around the screen reader problem by not bothering it at all? Frankly, there doesn’t need to be a problem. If the date or time is there as human readable content in the first place why would you want to offer different or extended information just to screen reader users?

Seriously, what’s the hang up about abbr? No one seems to have answered that yet. Why is it so important?

#28 On April 27th, 2007 12:23 pm patrick h. lauke replied:

i remember raising this issue quite a while ago with regards to geo microformats. here, the semantics of using ABBR would be very stretched when doing things like

[abbr class="geo" title="30.300474;-97.747247"]Austin, Texas[/abbr]

here, using something like a SPAN seems far more preferable to me…ditch the ABBR pattern of that monster above.

#29 On April 27th, 2007 12:26 pm patrick h. lauke replied:

oh and yes, screenreader output for the above geo example would certainly drive users to insanity and beyond…

#30 On April 27th, 2007 12:28 pm John Arthur replied:

Patrick, the purpose of offering that repetitve information is not so much for the user of a screen reader, but rather for the parsing of the information by a secondary application, or at least that’s why I would use Microformats. Otherwise, we wouldn’t “hide” the boring bits, we’d either leave them out completely, or put them right along with the good parts.

If I wanted to pull info off of specific sessions, would I get the proper and complete information? I’m sure there could be a workaround for your suggestion using headers/scope, but I would imagine it’s much easier to get the teeming masses to do one step right (Full ISO in one place) vs. a set of steps correct (header/scope), especially when hearders/scopes are as obscure as they are (not a good thing, but how it is). Make the standards as simple as possible for those not wanting to code their entire life. Plus, what if I want to list my sessions in a list? Which solution is more universal.

As for abbr, I can’t say. Could it be that this just never occurred to anyone, and just because the spec says “abbr” doesn’t mean that it was intended to be “abbr and only abbr”? What would everyone say if I were to start using span titles? I know the current plug-ins wouldn’t recognize it (probably), but would it be the right path to initiate change if we just started trying it? Would it break/violate anything more than the Microformat?

#31 On April 27th, 2007 12:29 pm WaSP Member adactio replied:

Patrick, what you’re saying is basically “don’t use microformats” which is fine but then you’re going to lose out on the benefits outlined so succinctly in the first paragraph of this very blog post:

“They allow the embedding of parsable, semantic data (like contact information and event details) into regular web pages. With the right plug-in, that information can be saved directly to your calendar program or address book.”

That’s the “hang up” right there.

Now what we need to do in the case of the datetime pattern is work together to come up with a compromise that allows for the embedding of parsable data (a timestamp) without adversely affecting the readability of the content.

Of course it’s always a judgement call as to whether you want to implement hCalendar or not and, in the situation you’re describing, it makes perfect sense to decide that the disadvantages outweigh the benefits. However, I would say that it’s probably an edge case and microformats deliberately don’t attempt to solve every possible occurrence: getting 80% of the use cases is good enough. The situation you’re describing might well fall into the other 20%.

But this is all tangential to the main issue of the abbr pattern (and the datetime pattern in particular). It would probably be best if we kept the bigger questions separate (like why and where to use microformats).

#32 On April 27th, 2007 12:52 pm Patrick Griffiths replied:

Come on Jeremy, I know what microformats are and what they’re good for! I don’t know where you got that I said “don’t use microformats”. I want to use them. I’m all for supplying more information so that it can be used (which I hope also answers your response, Jonh) by whatever application, but my point is specifically about the highly problematic abbr element.

You’re still not answering the question – why is abbr so important? Take *it* (or rather its necessity) away and all of these problems disappear.

#33 On April 27th, 2007 12:59 pm hAccesibility da Davide Bocci in… replied:

[...] I Microformati sono una grande idea e coesistono armoniosamente con l’accessibilità. [...]

#34 On April 27th, 2007 1:02 pm WaSP Member adactio replied:

Ah, I see. Sorry Patrick, I was misunderstanding your problem.

The reason why the abbr element is specifically chosen as the carrier for the datetime design pattern is that, in the case of the abbr element, the title attribute has a different semantic meaning than a title attribute on other elements. For most elements, the title attribute “offers advisory information about the element for which it is set.” For the abbr element, it offers an expanded version of the contents contained between the opening and closing tags.

So semantically speaking, abbr is the right element to use (though of course that’s also open to interpretation and discussion as we’ve seen). It wouldn’t be as semantically correct to use the datetime pattern in the title attribute of any other element.

However, I think that in this case the practical implications of the screen reader problems may outweigh the semantic correctness. This is the solution outlined by James and Bruce in proposing the span element (though I don’t think it should be restricted to span). I’ve raised the issue on the microformats-discuss list:
http://microformats.org/discuss/mail/microformats-discuss/2007-April/009349.html

That’s probably going to be the best place to weigh in on the pros and cons of this proposal.

Anyway, I hope that clears things up WRT the question of “why is abbr so important?”

#35 On April 27th, 2007 1:21 pm Jon Gibbins replied:

The title attribute can be used to “provide more information” about an element, correct? The advantage of using abbr was/is that it provides context to the contents of the title attribute. What is needed then, as suggested earlier, is a means of providing that context that doesn’t impact on accessibility (or anything else for that matter) yet can be machine parsed.

I’ve updated my notes that I linked to earlier with some results from testing using JAWS 8.0 (slightly different) and details of how screen reader users may typically access title attributes, specifically those on abbreviations. To expand on that (no pun intended), it’s only really abbr and acronym that are going to have specific accessibility connotations from using its title attribute in this way – or as far as I can tell. The only other usage I can think of is with title attributes on links – not really appropriate to this discussion.

#36 On April 27th, 2007 1:34 pm Danny replied:

The problem you describe sounds like we’re between a rock and a hard place. I wonder what WAI have to say..?

While DTDs and namespaces probably wouldn’t be appropriate here, as a fan of both microformats and RDF, I find this gratuitous and misinformed: “Opening the floodgates to custom DTDs and namespaces would quickly raise the complexity level of Microformats to that of RDF, greatly reducing its adoption and therefore its relevance.”.

The kind of problem you describe here is related to the representation of data in a human- and machine-readable form. RDF is essentially a data model, the view is a separate issue (microformats and eRDF/RDFa both work pretty well for certain kinds of RDF). Take a look at the examples of marked up dates you provide, and compare with this statement for giving the date of this page (in Turtle RDF):

<> dc:date “2007-03-12″ .

#37 On April 27th, 2007 1:35 pm John Arthur replied:

Sorry Patrick, as I was slightly misunderstanding things as well. I thought you were asking two separate questions, and thought you were literally asking “Why spell date/time out completely?” as something not related to “What’s so cool about abbr, anyway?” And I didn’t mean to say you didn’t want to supply info, I just used a (rather poor) metaphor to advocate verbosity.

#38 On April 27th, 2007 1:39 pm Patrick Griffiths replied:

Jeremy – it does clear it up – thanks :)

I have to say (I’ll attempt to shut up soon) that it still strikes me that even if you were right (as you point out, there are those who could disagree with you), snipping the *necessity* of that specific element’s use would be easy and solve all of the problems highlighted in this article and discussion.

It would mean that those concerned about the issues in this article could happily apply the microformat, people in my situation (hey, 20%’s still a pretty fat percentage!), or anyone uncomfortable with marking up something they don’t believe to be an abbreviation as an abbreviation can use hCalendar with semantically correct code, and those who still prefer abbr as the semantic dog’s bollocks can still use abbr!

Surely you still get that juicy extra embedded parsable, semantic data in all cases!

#39 On April 27th, 2007 1:41 pm Accessify: latest news / microformats’ ABBR design pattern raises accessibility concerns replied:

[...] The discussion is already in full swing, with some good arguments on either side of the fence…so head on over to read the full article hAccessibility and join the debate. [...]

#40 On April 27th, 2007 2:01 pm Lenny replied:

There’s also the HTML5 construct <time datetime="2007-04-27">Today&lt/time>.

#41 On April 27th, 2007 2:13 pm WaSP Member jcraig replied:

@Jeremy Keith: You wrote, “It strikes me that it would be trivially easily for screen readers to parse this data and read it back in a human-friendly manner.” (#1)

I tried to address that hypothetical situation in the part of the article titled, “Accessibility, in the wild.” Perhaps Daniel Morrison explained it better by quoting the Microformats wiki: Microformats are not “an attempt to get everyone to change their behavior and rewrite their tools.” (#10) I’d also like the note the sentence immediately following… Microformats are not “a whole new approach that throws away what already works today.”

#42 On April 27th, 2007 2:13 pm WaSP Member jcraig replied:

@Jon Tan: I don’t believe a title prefix, such as “ISO date” (#4), is the right way to go. Even if you effectively chose a phrase such as, “Ignore the following gibberish,” it would have to be different in each language translation. Microformat parsers would need to isolate and parse arbitrary substrings of the title attributes. I realize and ISO date is an easily-matched pattern, but the abbr-design-pattern is also commonly misused for RFC 2426 type values in hCard. Not impossible, but it significantly raises the complexity of the parsing.

Also, I thought a puggle was a Pug/Poodle mix. *grin*

#43 On April 27th, 2007 2:13 pm WaSP Member jcraig replied:

@John Arthur: You wrote, “one of the tenants of Microformats is that the content shouldn’t be hidden, or at least [not] completely.” (#17)

I agree with this, but ISO dates are only intended for machines, not humans, so I believe it should be hidden. The idea that machine-readable values should be visible has led to an i18n issue with Microformats. The RFC values–home, work, etc.–happen to be both machine-readable and human-readable, but only in English. There is no way to mark up these values in other languages other than to continue abusing abbr-design-pattern.

#44 On April 27th, 2007 2:14 pm WaSP Member jcraig replied:

@Jon Gibbins: You wrote, “JAWS can be configured to read expansions provided in title attributes of abbreviations independently of other elements, so a title attribute on a span is not necessarily read out.” (#22)

Good point. The reason we mentioned the use of a span title is because it is much less likely to be read than an abbr title. Most screen reader users can customize their verbosity settings: to read all title attributes, no title attributes, or some title attributes. Common settings on other screen readers often speak abbr titles, but rarely speak span titles.

#45 On April 27th, 2007 2:14 pm WaSP Member jcraig replied:

@Jeremy Keith: You wrote: “If that is reformulated as: title="2007-03-12T17:00:00", then wouldn’t you agree that the screen reader difficulties are significantly mitigated?” (#23)

If by “significantly mitigated” you mean, “slightly less offensive gibberish,” then sure. I don’t think it’s acceptably mitigated, though. Do you talk to your grandmother that way? It reminds me of the Master Control Program from Tron that always ended its sentences with the meta phrase, “End of line.” Your proposal also ignores different verbosity settings, other screen reader variations, and especially pronunciation in other languages.

You also wrote: “I don’t think it should be restricted to span.” (#34)

Certainly not. Any element without special semantics applied to its title like abbr, acronym, and in some cases, th. There may be more.

#46 On April 27th, 2007 2:15 pm WaSP Member jcraig replied:

@Danny Ayers: You wrote, “I wonder what WAI have to say.” (#36)

To my knowledge, the WAI hasn’t released an official statement on this, but some of the ATF members are current or previous members of the WAI Working Groups, and we all follow the discussion lists when possible. As for your comment about RDF and Dublin Core, I partially agree, but this isn’t the forum. The arguments against it are made better elsewhere, such as the Microformats discussion list.

#47 On April 27th, 2007 2:31 pm WaSP Member jcraig replied:

@Danny Ayers I should probably clarify my last comment as “this isn’t the the forum” sounded like too much of an easy dismissal. I apologize.

The comment in question is, “…as a fan of both microformats and RDF, I find this gratuitous and misinformed: ‘Opening the floodgates to custom DTDs and namespaces would quickly raise the complexity level of Microformats to that of RDF, greatly reducing its adoption and therefore its relevance.’” #36

My implication is that embedding RDF, such as the Dublin Core namespace you referenced, would open the possibility to allowing infinite other taxonomies. I attribute much of the success of Microformats to their simplicity, allowing easy implementation for even novice web designers. I don’t think that popular adoption would hold up if Microformats became as complex as many RDF proponents would like them to be.

As for being “gratuitous and misinformed,” well, that’s why this article is tagged, “opinion.” *grin* Cheers.

#48 On April 27th, 2007 2:35 pm WaSP Member blawson replied:

Jeremy, thanks for taking this to the microformats list – but I fear that the “punctuated” ISO date-time format as a title is only slightly less bad, rather than accessible.

You’d still rather hear the real date and time read out to you, wouldn’t you?

That’s why James and I recommend leaving the abbr element out of the equation all together.

#49 On April 27th, 2007 3:20 pm Daniel Morrison replied:

I think we need to remember that this isn’t saying the abbr pattern is bad — truly, I think it was a great idea!

Unfortunately, “in the wild” it isn’t working as well as we’d like. That’s why we need to reevaluate.

#50 On April 27th, 2007 3:41 pm Patrick Griffiths replied:

Well, it’s been a blast.

I’ll leave you with a bedtime story:

http://www.htmldog.com/articles/tablebears/

Night night.
Don’t let the abbreviation bugs bite.

#51 On April 27th, 2007 4:37 pm WaSP Member jcraig replied:

As Patrick implieed with his geo example, we are recommending keeping:

<abbr class="country-name" title="Japan">JP</abbr>

But abolishing its misuse in the following dates, long/lat, and RFC type values.

<abbr class="dtstart" title="2007-03-27T12:00:00-06:00">Noon Central</abbr> <abbr class="geo" title="30.300474;-97.747247">Austin</abbr> <abbr class="type" title="home" xml:lang="es">Casa</abbr>

While changing the recommendation of the ISO date to include dashes makes a minor difference, it’s irrelevant to the problem we’re addressing.

#52 On April 27th, 2007 5:00 pm Andy Mabbett replied:

It gets worse:

April 22, 1997

Since when was “twenty-second” an abbreviation of “23″?

#53 On April 27th, 2007 5:01 pm Andy Mabbett replied:

Ack:

[abbr class="dtend" title="19970423"]April 22, 1997[/abbr]

Since when was “twenty-second” an abbreviation of “23″?

#54 On April 27th, 2007 5:27 pm Ashley Bowers Blog » hAccessibility replied:

[...] hAccessibility [...]

#55 On April 27th, 2007 5:53 pm patrick h. lauke replied:

so, looking at some “harmonisation” ideas then, what i would suggest a way forward may be:

* heavily editing the page in the microformats wiki about abbr-design-pattern to quite clearly state that, because of abbr’s semantics, which assistive technologies like screen readers rely upon, the pattern should only ever be used if the machine-readable part in the title is also very clearly human-readable (and by that we don’t mean somebody who’s into geocaching and therefore loves to hear lat and long, or somebody who really likes their time to be read out in full ISO format).

* introducing a new design pattern page…i’d call it the title-design-pattern. this can show pretty much what the current abbr-design-pattern page has, just with a variety of other elements (like span, div, p, object) and a clear warning that this pattern should not be used with elements where title has been given slightly “special” meaning and/or are used by current AT. should also include a note that this replaces the abbr pattern of old, and that abbr-design-pattern in its new form is a very limited subset of the title-design-pattern

* trawling the rest of the microformats wiki to remove examples of problematic abbr-design-pattern use and replace them with more generic title-design-pattern examples

#56 On April 27th, 2007 6:31 pm WaSP Member jcraig replied:

Patrick Lauke wrote, “introducing a new design pattern page… i’d call it the title-design-pattern.” (#53)

We should indicate title-design-pattern should not be used to hide human-readable data, but only be used in the problem cases where the data is not human readable, or in i18n cases, where the machine/human readable version is in another language. Due to opening up the pattern a bit more, there will also need to be a flag to indicate when to use title attribute versus contents. Something like this “useTitle” class:

Uses title value:
Noon Central

Does not use title value:
<a href="http://example.com/" class="fn org url" title="Visit the company web site!">Widgets, Inc.

#57 On April 27th, 2007 10:00 pm Ben Boyle replied:

That’s great really, but here is my dilemma as a website author using hCalendar. The proposed changes sound good, but by the time they are adopted by microformats (if they are) and implemented by the plugins all our current events will be finished! Yet if I don’t make changes now we retain the accessibility issue. This has always bothered me a bit and now it’s been raised in this forum I’d really like to fix it! And I’d like to do so and continue to use hCalendar…

Long term, it might work if microformat parsers supported any element with the relevant class and title attributes, that would allow current (abbr) implementations to work. Use of abbr is then deprecated and authors are encouraged to use more appropriate elements. Or some other solution may emerge.

Short term, how’s this idea?
... 12:53 pm on 28 April 2007<abbr class-"dtstart" title="2007-04-28T12:53:00+10:00" style="display: none;"></abbr>

Yes, I know it’s not elegant. But will it work, today, for existing screen readers and microformat parsers? Anyone have a better alternative?

#58 On April 28th, 2007 1:22 am mcdave.net » links for 2007-04-28 replied:

[...] hAccessibility – The Web Standards Project (tags: accessibility microformats) [...]

#59 On April 28th, 2007 2:04 am bruce replied:

I’d be jolly interested to hear from anyone who makes plug-ins that consume microformats about how quickly they could adapt to parsing dates in the title-design-pattern format, while retaining support for the deprecated abbr-design-pattern format.

#60 On April 28th, 2007 3:49 am Danny replied:

@James, thanks for the response, much more reasonable…but I still don’t see why you assume RDF folks favour complexity! Simple authoring is desirable everywhere, which is why microformats make a very nice way of expressing RDF data in a (usually) webmaster-friendly fashion for the domains covered – they can be interpreted transparently through the GRDDL mechanism.

On the problem at hand, it looks to me like it can’t be fixed to please all parties with the HTML spec as it stands. Generally I’d consider accessibility a foundational thing for human-readable markup. But in this particular case the cost of some obfuscation of the information on screen readers seems the lesser of the evils (“2007-03-27T12:00:00-06:00″ can make sense read aloud, it’s not like the information disappears). Obfuscation in regular browsers would impact more people, and as yet I’ve not seen an alternative to the current pattern which doesn’t bring in a lot of complexity. So best bet right now would seem to be continue using the current pattern in lieu of a better spec-native solution (and maybe talking to screenreader manufacturers…)

re. “allowing infinite other taxonomies” – HTML itself already allows this (@class in particular is wide open, and disambiguation is available through profiles), and while microformats do confine themselves to a handful of domains, eRDF can be used alongside them to extend their scope.

btw, Shelley picks up on the RDF point too. Lookout, asteroid!!

#61 On April 28th, 2007 4:51 am WaSP Member adactio replied:

Before the discussion gets too involved in the nitty-gritty–with talk of deprecation and extra classes (a bad move in my opinion)–it would be better to move it over the microformats-discuss list which is exactly the right place for hammering out this kind of thing:

http://microformats.org/discuss/

#62 On April 28th, 2007 4:59 am Patrick Griffiths replied:

Ben – unfortunately it’s not just inelegant, it’s kinda wrong, from a semantic HTML point of view.

The better alternatives are those mentioned – largely based around the title-design-pattern, as Mr. Lauke puts it.

I still don’t get why this is so long and drawn out. There are some simple solutions to every problem raised.

#63 On April 28th, 2007 6:26 am WaSP Member adactio replied:

Patrick said:

“I still don’t get why this is so long and drawn out. There are some simple solutions to every problem raised.”

This blog post was posted less than 48 hours ago. There is already a lot of movement on the microformats-discuss list looking into something like the title-design-pattern. But even in a fast moving structure like the microformats community, expecting immediate results is pretty unrealistic. There are other considerations here (some semantic, some technical) and even though you are personally very convinced that there is one straightforward solution here, I think it would be a good idea if you could at least try to listen to some of the other viewpoints. As I said, the best place for doing that at this stage is not here in the comments to this blog post but on the microformats-discuss list.

#64 On April 28th, 2007 7:06 am High Earth Orbit » Blog Archive » links for 2007-04-28 replied:

[...] hAccessibility – The Web Standards Project Microformats are a great idea. They allow the embedding of parsable, semantic data (like contact information and event details) into regular web pages. With the right plug-in, that information can be saved directly to your calendar program or address book (tags: standards microformats article webdesign) [...]

#65 On April 28th, 2007 7:32 am Ben Boyle replied:

Yeah, I agree it’s poor semantics; but if I’m gonna abuse <abbr> for hCalendar, I might as well abuse it in a “screen-reader friendly way”. It might sound better if I phrase it as erring towards hiding the machine data as best I can. This is only an interim measure. I’ll be there to fix the semantics when microformats folks have an alternative! ~:)

#66 On April 28th, 2007 7:39 am Patrick Griffiths replied:

Jeremy,

There are other issues – namely semantics, HTML specs, and practical accessibility, which makes this article, and WaSP in general, a perfectly reasonable place to discuss these issues. There’s genuine crossover between different topics of interest.

I am listening to viewpoints – I’m just not agreeing with all of yours. Instead of being rude, please credit me with some intelligence. I genuinely don’t understand why the problem is so huge, and even after re-reading everything, I can’t find an adequate answer. I’m not saying that there isn’t an answer. I’d be happy to find one. I want to be educated. Clue me up.

As for 48 hours being the time frame, it isn’t, as you well know. I have highlighted here that this has been raised long ago, and you highlighted in the very first line of the very first comment, “This is something that the microformats community is aware of and has been looking into.”

#67 On April 28th, 2007 8:41 am Jim O'Donnell replied:

Dates are abbreviations, ISO8601 dates are human-readable, ignorance is strength and we have always been at war with Eastasia :)

Seriously, the ‘span title’ solution seems the best to me, but still strikes me as a hack to devised to get around fundamental deficiencies in HTML ie. the lack of a specific element for dates and the lack of an attribute to hold machine-readable strings.

I don’t know if anyone else agrees, but my own rule of thumb for a title attribute is ‘if you read it aloud to the person next to you, would they understand it?’ For IS0 8601 dates, that test is only going to work if the person sitting next to you is a dalek.

Should web authors ask, before applying this markup, ‘does this date need to be read by an application?’ If not, then perhaps it isn’t necessary to mark up that particular date in ISO format in the first place.

One final though, is it odd that the country name example has the machine-readable code ‘JP’ inside the HTML element, and the human-readable expansion in the title. Whereas the markup for dates reverses that – machine-readable in the title, human-readable inside the element.

#68 On April 28th, 2007 12:25 pm Stephane Deschamps replied:

I *must* admit that last year when we put up the Paris Web 2006 site we had worries about this same problem, and confess we should have written then about that.

I didn’t like what a screen reader would give, so any the abbr used in hCalendar marking-up was replaced by span markup.

Speaking of plugins, Tails Export for Firefox didn’t cough at the idea.

I totally agree with the fact that although the Microformats group has solid ground for using abbr, real-life, ‘in the wild’ experience advocates against keeping it as the basis for this kind of information.

#69 On April 29th, 2007 7:53 am Lawrence Meckan replied:

I’ve actually done some testing for the the date-time design pattern and I seem to be getting different results than what Jon Gibbins has reported. I’ve tested with JAWS 8 set at advanced verbosity, Window Eyes and Firevox. In all cases, it parses the date correctly. In all tests, I’ve been setting it to read the entire document and watch how it parses the date structure.

There are a few caveats, however. Most of the talk on this subject has focussed on hCalendar events. My tests were run on hAtom, which also includes the same date-time design pattern as hCalendar, just used in a different form – publishing and content updated dates. I’ve also expanded the abbr pattern to include a span inside it, essentially duplicating the semantic structure, in order to do a fix for IE6 not styling abbrevations.

I’m willing to put my site (which is prebaked with the hAtom across the entire structure) under a public stress test in order to see whether or not the additional span inside the abbreviation element resolves this issue. My results seem to point to a different conclusion than what Jim has found, and the only reason I can thus far find is that there’s an extra span included for styling purposes.

Anyone wish to confirm or deny the results I’ve found ?

#70 On April 29th, 2007 5:33 pm Jim O'Donnell replied:

Given that JAWS, at least, doesn’t parse the DOM but reads whatever is passed to it by the underlying application, why should the onus be on JAWS to parse HTML?

Unless I’m missing something, which is entirely possible, shouldn’t the browser’s HTML parser convert the ISO 8601 date to a localised, human-readable format and pass that string to the screen reader?

I saw that market share got mentioned on the microformats-discuss list. Is the market share of screenreader users larger or smaller than the market share of people who actually use hCalendar to export events from web pages? :)

#71 On April 29th, 2007 10:07 pm 工控网 replied:

[…] hAccessibility – The Web Standards Project Microformats are a great idea. They allow the embedding of parsable, semantic data (like contact information and event details) into regular web pages. With the right plug-in, that information can be saved directly to your calendar program or address book (tags: standards microformats article webdesign) […]

#72 On April 30th, 2007 1:22 am mcdave.net » links for 2007-04-30 replied:

[...] hAccessibility – The Web Standards Project (tags: microformats david:leer standards) [...]

#73 On April 30th, 2007 5:46 am WaSP Member lloydi replied:

Just wanted to say that this is a great article from Bruce and James – very encouraging to see so much comment on this. And I sincerely hope that the Microformats peeps will be able to come to an agreement with us accessibility twonks on a way forward.

While adding an extra (empty) span seems like junk markup, there is a trade-off between semantics and real world usage. But here, to me, seems to be the problem – if we admit that the current implementation is bad for screen readers (because the screen readers are actually doing what they should be) and that the abbr approach is not working, then we are advocating putting in empty elements for the purposes of the microformats parsers. Some might say this is a modern day equivalent of using a spacer gif and therefore inherently evil.

Microformats do not appear overnight – they are discussed, approved and documented and for that reason I think it’s going to be a little difficult to resolve this, mainly because it’s going to take an individual or a collection of individuals to admit that they got it a bit wrong (and even that’s up for debate, as the full ISO format of a shortened date is an expanded form – albeit one that is junk to anything other than a parser).

So, let’s all have a group hug, agree to disagree on some points and then we can start to agree on what we agree on.

#74 On April 30th, 2007 6:05 am Aren’t Microformats Supposed To Be Accessible? :: Unintentionally Blank replied:

[...] I am also a big fan of accessibility on the Internet too, so try to imagine my surprise when I came across Bruce Lawson and James Craig’s article on the Web Standards Project about hCalendar’s inaccessible dates. Two movements on the web are now working against each other? Are we pushing in opposite directions and still trying to achieve the same result? Here’s my opinion. [...]

#75 On April 30th, 2007 7:52 am WaSP Member adactio replied:

Lawrence, if you could add your test results of including an extra span to the ongoing wiki documentation, that would be great:

http://microformats.org/wiki/assistive-technology-abbr-results

#76 On April 30th, 2007 10:34 am Jon Gibbins replied:

Lawrence, I’m a little busy to do further testing at the moment, but feel free to e-mail me (via my site) with details of the markup you used. Let’s see if we can bring our results together.

#77 On April 30th, 2007 4:39 pm Michael replied:

What about using URI’s for dates and geo data? For example:

<q class="dtstart" cite="http://datetime.iso.org/2007-03-12T17:00:00-06">March 12, 2007 at 5 PM, Central Standard Time</q>

#78 On May 1st, 2007 9:42 am Patrick H. Lauke replied:

if ABBR is semantically shady, Q is just completely inappropriate, in my opinion. how can “March 12, 2007 at 5 PM” be a quotation?

#79 On May 5th, 2007 2:56 pm Mosuki blog » The problem with hCalendar replied:

[...] The Web Standards Project has an good explanation of what we think is the single biggest problem with hCalendar — overloading the HTML title attribute. [...]

#80 On May 7th, 2007 8:31 am Max Design - standards based web design, development and training » Some links for light reading (7/5/07) replied:

[...] hAccessibility [...]

#81 On May 14th, 2007 2:11 am Ben 'Cerbera' Millard replied:

I have created Attribute for arbitrary data at the WHATWG forum. This could provide a long-term solution to interlacing content with arbitrary data. But at the moment, it’s just a forum topic. :)

In the meantime, I hope some “accessibility twonks” can find the time to get the  workaround into Microformats by going through their process. And I hope the Microformats community will be open to adjusting this design pattern in line with their project’s principle of humans before machines.

#82 On May 19th, 2007 9:51 am Mo replied:

I’ll say it once, and I’ll say it again: this is precisely what XHTML was intended for. Use namespaced elements or attributes for the additional data, and a plug-in can read it trivially.

#83 On May 20th, 2007 3:40 pm microformats.dk » Blog Archive » Flash trash replied:

[...] Nu er det ikke sikkert, at du synes det ser så fedt ud med længde- og breddegrader angivet midt i din tekst, så brug HTML elementet abbr som jeg viste i det første eksempel, og det sparer også en del kodning. Der er pt. en hed debat kørende på The Web Standards Project om det nu er så smart mht. tilgængelighed at benytte HTML elementet abbr til microformats. Jeg vender tilbage i næste indlæg med en anden geo opmærkningsmetode som Flickr benytter, hvis du ikke ønsker at længde- og breddegrader som være synlige, men stadigvæk maskinlæsbart. [...]

#84 On May 23rd, 2007 6:20 am Bruce Lawson’s personal site : JavaScript, accessibility, microformats replied:

[...] I’m glad that our Web Standards Project article, hAccessibility is being read and thought about, But he shouldn’t be relieved. Just because the out-of-the-box setting is accessible shouldn’t lead to complacency. This is an assistive technology we’re talking about, and one of its options for extra accessibility is to expand abbreviatons, as recommended in WCAG 1. [...]

#85 On May 26th, 2007 2:32 am Bruce Lawson’s personal site : A rant: HTML5, microformats and testing accessibility replied:

[...] Most microformats adherents seem to agree with an article that James Craig and I wrote, hAccessibility, that pointed out that the current spec’s use of the abbr element is inaccessible to some users. In theory, “Austin, TX” is an abbreviation of “30.300474;-97.747247″. In practice, it doesn’t work (mp3). [...]

#86 On May 26th, 2007 5:10 pm Olle Lundberg replied:

Why use an extra span with inline style to hide the ocject? We can accomplish the same result with the following workaround:

span.dtstart object {display:none;}

March 12, 2007 at 5 PM, Central Standard Time

Or am i missing something big here?

#87 On May 29th, 2007 2:13 pm WaSP Member jcraig replied:

@Olle, re-read the first paragraph in the section titled, “What’s the Catch?” and view the screen shots of the browser bugs in the version without the extra span.

#88 On May 30th, 2007 9:36 am enternet replied:

Maybe 20070312T1700-06 ?

#89 On May 30th, 2007 9:37 am enternet replied:

Sorry
20070312T1700-06

#90 On June 13th, 2007 2:41 pm Julie replied:

Here is what I will be including in a new markup guide I’m creating for my office (line wraps marked with ->):

<ol class="hcalendar"> <li class="vevent">Tuesday, June 5, 2007, Noon–1:30 p.m. -> <abbr class="dtstart" title="20070605T1200-0500">(0700 -> GMT–</abbr><abbr class="dtend" title="20070606T1330-0500"> -> 0830 GMT)</abbr> <ul> <li class="summary">Get-Together</li> <li class="location">402B Jesse Hall</li> <li class="description">Bring a friend!</li> </ul> </li> </ol>

I’m thinking that screen readers that read the ISO info out plain will still verbalize it, but at least it will be precluded by comprehensible information. I am no expert, though.

#91 On June 13th, 2007 2:46 pm Julie replied:

I should have explained that the “hcalendar” value is something extra that we add in our office for lists of events on our “calendar of events” pages.

#92 On July 5th, 2007 2:16 am Andrew replied:

Thanks, this information was really helpful. I have been learning html for a few weeks now and find this site very useful. Thanks to this page I now know how to abbreviate. Is this the most simple way or is there an easier way when you have more than 50 abbreviations in a single page? Thanks

#93 On July 8th, 2007 2:15 pm tercume replied:

#94 On July 8th, 2007 3:57 pm Andy Mabbett replied:

Discussion of this article on the microformat IRC channel, viewable at rbach.priv.at/Microformats-IRC/2007-07-05#T175801 (and ending with the comment time-stamped [18:27:54]) is relevant.

#95 On July 21st, 2007 9:48 pm Microformats & the govt media release [beta] | NPSC Blog replied:

[...] After reading this post from the Web Standards Group on the accessibility issues around abbreviations in microformats, I have reworked the code for the most recent e-government hRelease (on new search for newzealand.govt.nz). The dateline now looks like this: [...]

#96 On July 23rd, 2007 9:05 pm All in a days work… replied:

[...] hAccessibility – hCalendar’s Original Sin The creators of Microformats strayed from their accessible, semantic intentions when they extended the abbr-design-pattern to the datetime-design-pattern. This idea, though paved with good intentions, was a workaround for a browser bug and, like many othe [...]

Return to top

Post a Reply

Comments are closed.

Working together for standards The Web Standards Project