[uf-discuss] changing abbr-design-pattern to title-design-pattern?

[Jeremy Keith]

Tantek wrote:
> I concur with Jeremy - this is a really bad idea.

I think we can all agree that the addition of an extra class for the  
benefit of parsers "smells" bad so we can probably ditch that  
suggestion.

> In addition, using span title is less semantic than abbr title thus  
> it is
> undesirable.

Ah, now here's where we differ.

I agree that it is technically less semantic. A title attribute on an  
abbr element means something different to a title attribute on any  
other element. I agree that storing machine-readable data in the  
title attribute of an arbitrary element is less than ideal...  
although storing machine-readable data in the title attribute of an  
abbr element has always felt more than a little shady anyway.

> To be frank - the blog post on hAccessibility WaSP was seriously  
> flawed.

It's true that the example was extreme--including timezone info and  
leaving out dashes and colons--but the fundamental point was still a  
good one.

> I for one have always tried to push things (browsers, content)  
> towards at
> least being accessibility-friendly, and I still think that's a good  
> policy.
>
> However, I'm against contorting microformats because of bugs or  
> suboptimal
> behaviors in <1% marketshare browsers.

Normally I would agree with you here. But the situation with screen  
readers is somewhat different. We're not talking about a regular  
browser here: if someone is using a sub-optimal or outdated web  
browser and they don't get the full benefits, then that's something  
that can be brushed over but for a blind person using the most up-to- 
date technology available to have to put up with an illegible piece  
of data isn't acceptable. In this particular case, the market share  
numbers are--to my mind--irrelevant.

> I think there needs to be a balance.

I agree completely. And I find the title-design-pattern to be a good  
compromise.

It's true that it is semantically less correct than the abbr-design- 
pattern but given that pattern's dubious grounding, it's probably  
more accurate to refer to the title-design-pattern as "slightly more  
semantically dubious" rather than "worse."

> In addition I think this is a case where a little bit of pain now  
> with abbr
> and some tools actually opens up the potential for *much* better
> accessibility/usability tools (once UAs actually recognize ISO  
> dates as such
> and can speak/rewrite them for a user's datetime/language/locality
> preferences).  I for one think this tradeoff is more than reasonable.

If we were talking about anybody other than screen reader  
manufacturers, I would agree with you. But history has shown us that  
these people, frankly, don't give a shit.

I've made it very clear (on the WaSP blog post and elsewhere) that  
microformats represent a huge opportunity for screen reader  
manufacturers. Derek Featherstone gave me goose bumps at the Web  
Directions conference in Sydney last September when he mocked up a  
demo of what it might sound like for a screen reader not just to  
announce the number of links and headings on a page but also "There  
are X number of contacts and Y number of events on this page."  
Inspiring stuff! But... in the here and now we have to deal with the  
current (craptacular) technology that screen reader users have no  
choice but to use.

In this instance, we could stick by our semantic guns and say that  
the more semantically correct solution (the title attribute on abbr)  
is preferable to a slightly less semantic solution (the title  
attribute on any other element). But I strongly feel that, in this  
particular case, that would be a grave mistake.

The theory of the abbr-design-pattern is pretty good. The  
practicalities are problematic.

The theory of the title-design-pattern is problematic. The  
practicalities are pretty good.

So what do we choose?

I firmly believe that the strength of microformats lies in their  
*practical* value. Microformats have always been a here-and-now  
technology rather than a utopian idea for some future Semantic Web  
(see: RDF and other noble but failed W3C technologies).

It's a somewhat bitter pill to swallow but I believe that we need to  
balance the practical and the semantic angles to embedding machine- 
readable data inside markup and come down on the side of practicalities.

Therefore, I fully support the title-design-pattern. I don't believe  
it will be a slippery slope that leads to any semantic watering-down  
of microformats. I believe it's a necessary step to take to deal with  
the situation on the ground with screenreaders.

I'd also like to point out one of the beauties of the proposed title- 
design-pattern: it's completely backwards compatible with the abbr- 
design-pattern. The abbr-design-pattern uses the title attribute of a  
*specific* element: the title-design-pattern uses the title attribute  
of *any* element. abbr is an element therefore the title-design- 
pattern still applies to the abbr-design-pattern. Already-implemented  
vevents will still work using the title-design-pattern. It may be  
that some parsers may have to broaden their range to search for  
datetimes in the title attribute of any elements but I wouldn't be  
surprised if current parsers are already being liberal in what they  
accept.

I'd be interested in hearing if anyone else feels as strongly as I do  
that the title-design-pattern is something that should codified as  
soon as possible. I'd be even more interested in hearing if there's  
anybody, like Tantek, who feels that it's a bad idea... or to be more  
accurate, who feels that the practical benefits don't outweigh the  
semantic purity.

Bye,

Jeremy

-- 
Jeremy Keith

a d a c t i o

http://adactio.com/