WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Microformats (was address tag)

for

From: John Foliot - Stanford Online Accessibility Program
Date: Feb 20, 2007 2:10PM

Jukka K. Korpela wrote:
> On Tue, 20 Feb 2007, Alastair Campbell wrote:
>
>> Displaying the title on mouseover is unfortunate,
>
> If it's unfortunate, then you're abusing the attribute. Such behavior
> was mentioned (informatively, not normatively, but sure suggestively) as
> early as in the HTML 2.0 specification, though at that time as relating to
> <a> elements only (since it was the only element for which the attribute
> was originally allowed).

I have been watching this thread, and I'm afraid that Jukka you are starting
to perpetuate that hoary myth that web accessibility is stuffy, boring and
should be text only.

The W3C Recommendation neither expects nor suggests that the way that the
current crop of browsers handle the title attribute is correct nor endorsed
(although it does hint at it as one possible way). What the W3C says is:

"This attribute offers advisory information about the element for which it
is set... Values of the title attribute may be rendered by user agents IN A
VARIETY OF WAYS." (emphasis
mine)[http://www.w3.org/TR/html4/struct/global.html#adef-title]

Nowhere do I see anything that would suggest that using the title attribute
to "annotate" an element with microformat data is wrong or incorrect: the
fact that it may impact on some users is indeed unfortunate, but it is not
due to misuse of the attribute or it's spec, but rather in the way that
current technology is rendering the attribute. Speak to what is *really*
broken - I would suggest that the user agents should allow the end user to
determine if the "tool tip" displays or not visually, just as the current
crop of screen readers can allow for the vocalization of the title attribute
or not.

A user agent capable of consuming microformats (and I have at least 2
Firefox plugins now that can do so) will render the annotated information
into an alternative format (in some ways not unlike XSLT or XPath) that can
further be consumed by other technologies, such as my Google calendar, or an
iCal application. I can also export content author contact data as hCard
data, adding information to my contacts applications (such as Outlook or
Thunderbird), or annotate location information using microformat's address
annotation that can be 'rendered' via Web2.0 concepts such as googlemaps
mashups. If we do something like this, it is a simple click from a
"printed" address to a visual rendering of the location on a map - I can
certainly see this being a benefit for those with cognitive difficulties or
mobility impairments. Microformats might still have some kinks in them, but
to suggest that they abuse a vaguely worded spec is just wrong.



>
>> given that the content
>> is aimed at being machine-readable.
>
> Everything in HTML is aimed at being machine-readable. If you counted
> on something not being presented to the user, then you were betting on
> the wrong horse.

But Jukka, you are throwing the baby out with the bathwater. If I told you
that I was giving away free cash to all people named Jukka on 07-03-07 would
you be standing in front of me on the right date? Perhaps, perhaps not, as
that date is, at best confusing. However, if it were annotated using
microformat's "standard" for hCalendar markup, it would be done using the
ISO8601 Date standard. So in their own way, microformats *are* encouraging
and supporting standards - a point you seemingly fail to acknowledge.

(And if you wish to further play the "Standards" card, hCalendar is based
upon the iCalendar standard (RFC2445 (http://www.ietf.org/rfc/rfc2445.txt))
Finally, for what it's worth, there *is* an open community based standard
for microformats, with "rules", structure and agreed upon class values for
the many microformats to emerge to date. Just because they are not W3C
Recommendations does not negate their stature as a standards based concept.

>
>> However, to get a working
>> implementation within current specs (i.e. not creating new
>> attributes), is there another option with the same benefits?
>
> You are not within current specs if you _abuse_ attributes. Creating
> new attributes would be risky too, but not wrong the same way.

But you are interpreting the spec in your own ways and suggesting abuse. My
reading does not suggest abuse of the spec by content authors, but perhaps
by technology. Again, how is annotating a vague date with the machine
readable ISO date standard (which is hardly human-readable friendly) abuse
the spec? Or are you suggesting that not using the ISO8601 date standard is
a better way to go? With microformats, it appears to me we can have it both
ways...

>
> Can't you give the same (or better) service to _all_ users simply
> using a subscribable email list with a link to the updated calendar
> (as a normal, accessible web page)?

Simply, no. By using microformats, the content author is enhancing
screen-readable data with markup that can make the data more useful,
consumable and clearer to understand. In many ways, microformats borrow
from a concept that our field has used and promoted for some time -
progressive enhancement. Content marked up with microformats enhances it's
value in certain situations, to some users; however without the microformats
annotation the screen content is still available and consumable to all.
Microformats also allow for the exportation of this information to other
"user-agents" with a minimum of effort - I can export a calendar entry with
one click, as opposed to re-typing (or copy and pasting) large chunks of
data. For the mobility impaired, this is a wonderful enhancement, and
hardly "counter-accessible".

It really is unfortunate that the title attribute *is* so vaguely defined in
the specs. But to argue that microformats are abusing the attribute is
one-sided and unfair. To suggest that microformats go against accessibility
is wrong, and frankly unproven. As others have already said, I believe our
community should stay close to this developing "standard" and work with that
community to ensure that accessibility concerns do not get over-looked,
rather than our community shunning microformats and being left behind and
out in the cold.

JF
---
John Foliot
Academic Technology Consultant
Stanford Online Accessibility Program
http://soap.stanford.edu
Stanford University
560 Escondido Mall
Meyer Library 181
Stanford, CA 94305-3093
Tel: 650-862-4603