E-mail List Archives
Thread: Microformats (was address tag)
Number of posts in this thread: 9 (In chronological order)
From: Alastair Campbell
Date: Tue, Feb 20 2007 4:20AM
Subject: Microformats (was address tag)
No previous message | Next message →
Jukka Korpela
> Making some web content accessible _only_ in RSS format is
> surely discriminating.
>
> The situation is not comparable, though, since RSS has fairly
> stable excuses for a specification, it is widely known and it
> is supported by the modern versions of popular web browsers.
Since the content of the subscription calendar is *sourced* from the web
page (the whole point of Microformats), I would say they are very
comparable situations.
Browsers have taken on some RSS features, but many people select an RSS
feed and open it (automatically) in an external Newsreader application.
I don't see browsers supporting calendars anytime soon, but the
situation / implementation is similar.
Displaying the title on mouseover is unfortunate, given that the content
is aimed at being machine-readable. However, to get a working
implementation within current specs (i.e. not creating new attributes),
is there another option with the same benefits?
I take it there isn't an assistive technology that reads out titles on
<abbr>s then?
> Regarding subscription to the calendar, I don't know anybody who would
want
> to do such things, but my point about it was the very cryptic nature
of the
> subscription link.
People who want to keep upto date with events, and not have to type in
15 events into their own calendar by hand. I've had some good feedback,
partly because you get a higher than normal proportion of Mac users in
the competitive windsurfing community, so quite a few people took
advantage of it.
I think that's one of the main points, with Microformats a central
person (me in this case) types all the events in, and individuals don't
have to. Surely that's a good thing?
I take the point about bad wording, as I said, it's from quite a while
ago and I didn't want people without a suitable calendar application
selecting the link. I will change that soon.
Kind regards,
-Alastair
--
Alastair Campbell | Director of User Experience
Nomensa Email Disclaimer:
http://www.nomensa.com/email-disclaimer.html
From: Patrick Lauke
Date: Tue, Feb 20 2007 4:30AM
Subject: Re: address tag
← Previous message | Next message →
> Jukka K. Korpela
> Making some web content accessible _only_ in RSS format is surely
> discriminating.
Yes, but in this case, the information is not _only_ available as iCal.
> The situation is not comparable, though, since RSS has fairly stable
> excuses for a specification, it is widely known and it is
> supported by the
> modern versions of popular web browsers.
Yes, the situation _is_ comparable. iCal is also a fairly stable specification, and it is widely known and supported
by most modern calendaring software (integrated directly in OS X's and Vista's default calendar software, for instance).
P
From: Jukka K. Korpela
Date: Tue, Feb 20 2007 4:40AM
Subject: Re: Microformats (was address tag)
← Previous message | Next message →
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).
> 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.
> 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.
Option to what? To putting some hidden content onto web pages, to be
consumed by specialized software? Sorry, I don't play that game, and I've
been explaining why that's at least potentially hostile to accessibility.
> I take it there isn't an assistive technology that reads out titles on
> <abbr>s then?
Huh? Non sequitur, and not true. Even if it were not true, using titles
for other than advisory titles would be wrong, since it would work against
the desirable development where the titles are optionally (or by default)
made available to users.
> People who want to keep upto date with events, and not have to type in
> 15 events into their own calendar by hand.
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)?
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
From: Tim Beadle
Date: Tue, Feb 20 2007 4:50AM
Subject: Re: Microformats (was address tag)
← Previous message | Next message →
On 20/02/07, Jukka K. Korpela < = EMAIL ADDRESS REMOVED = > wrote:
> 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)?
iCal subscriptions are fantastic, and have operated distinctly from
and prior to microformats as a published grammar for years. A calendar
can be synchronised/copied to my mobile phone, iPod or even Google
Calendar (with new, albeit still beta, software Spanning Sync [1]).
The hCalendar microformat brings something new to the table - you
don't subscribe to an hCalendar marked-up page (for it's not iCal,
it's hCalendar, and needs transforming into the former), you use a
tool like Operator to export individual events to your calendar, which
can be synchronised as above.
An e-mail list of events would work, but it wouldn't be the best, most
easy-to-repurpose way to do this.
Regards,
Tim
[1] www.spanningsync.com
From: Alastair Campbell
Date: Tue, Feb 20 2007 5:30AM
Subject: Re: Microformats (was address tag)
← Previous message | Next message →
I think we will go in circles unless we separate what currently happens
from what should happen, and what is proposed to happen in future.
I wrote:
> > Displaying the title on mouseover is unfortunate,
Jukka replied:
> If it's unfortunate, then you're abusing the attribute.
I could argue that the title is providing extra information, the full
date in a standard. However, it's quite a stretch and I won't.
Currently, only mouseover in visual browsers displays that attribute to
the user. Unfortunate, but not the end of the world as it is in reaction
to the user doing something specific. It doesn't get in the way. If the
title were read-out by assistive technologies inline, that would be
confusing.
Titles aren't read out (by default) by current assistive technologies,
but they can and should be an option on certain elements. Off hand,
things like acronym, abbr, and most form elements.
Assistive technology vendors aren't likely to make titles read out by
default, as that title isn't a common attribute on many HTML elements
[1]. In future, without a use-case for titles on everything, that level
of support is unlikely to change.
Jukka wrote:
> To putting some hidden content onto web pages, to be
> consumed by specialized software? Sorry, I don't play that
> game, and I've
> been explaining why that's at least potentially hostile to
> accessibility.
To enable the kind of functionality that Microformats provide (which can
be useful for everyone), it does require that the content be in the
markup.
Observers may think I'm over selling the usefulness of Microformats, or
that you are blowing out of proportion the accessibility issues.
Hopefully the following clarifies things.
Currently, the main issue with Microformats is that the (not-very
understandable) date is shown on mouseover.
Currently, people are using microformats to save time, and receive
updates straight to their calendar with two clicks.
In future, assistive technologies might start using the title attribute
more, and these titles would be confusing.
In future, people will be able to select information straight from a web
page and send it to other applications, in a way that is far easier (and
more accessible?) than having to read through the page and type things.
>From a standards point of view, we have to use current markup. I would
suggest that assistive technologies do make use of title on certain
elements, and updates to the standards (HTML primarily and the
Microformats pages) reflect this.
Microformats are being used now by large companies such as Yahoo (which
has marked up millions of pages already), and will be by Microsoft
(according to Bill Gates).
I think that practical options for us at the moment are to get onboard
and make sure it's accessible in practice, or be ignored.
I wrote:
> > People who want to keep upto date with events, and not have
> > to type in 15 events into their own calendar by hand.
Jukka replied:
> 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)?
Nope. I take it you haven't tried it? I'd recommend giving it a go. With
a couple of clicks you can add calendar items (that would take me 30
minutes to type into each place) to you computer's calendar, a Google
calendar, and your phone's calendar.
I do highlight updates, and send emails out linking back to the up to
date calendar. As an organisation we get more competitors (paying
participants) the easier we make it for people to remember and attend
the events.
Currently, most people print out the calendar, but if their own computer
reminds them about events, they are much more likely to attend!
Cheers,
-Alastair
1. http://code.google.com/webstats/2005-12/elements.html
--
Alastair Campbell | Director of User Experience
Nomensa Email Disclaimer:
http://www.nomensa.com/email-disclaimer.html
From: John Foliot - Stanford Online Accessibility Program
Date: Tue, Feb 20 2007 2:10PM
Subject: Re: Microformats (was address tag)
← Previous message | Next message →
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
From: Andy Mabbett
Date: Tue, Feb 20 2007 2:30PM
Subject: Re: address tag
← Previous message | Next message →
In message < = EMAIL ADDRESS REMOVED = >,
Tim Beadle < = EMAIL ADDRESS REMOVED = > writes
>Perhaps you would like to actually find out a little more about
>Microformats before declaring that they are of no practical use?
I mentioned this discussion, using a neutral tone, on the Microformats
wiki. Here's how the description has been re-written, by the wiki's
"final arbiter":
<http://microformats.org/wiki?title=criticism&;curid=2431&diff=0&oldid=13641&rcid=23357>
Summary: criticism is nearly all from
[http://www.cs.tut.fi/~jkorpela/ Jukka "Yucca" Korpela] who
believes ridicule (he uses the term "microbabble") is a valid
method of criticism. His critiques are thus mostly ignorable,
though if you dig deep and ignore his rhetoric you can find a
few points we can use to improve microformats.
--
Andy Mabbett
* Say "NO!" to compulsory ID Cards: <http://www.no2id.net/>;
* Free Our Data: <http://www.freeourdata.org.uk>;
* Are you using Microformats, yet: <http://microformats.org/>; ?
From: Andy Mabbett
Date: Tue, Feb 20 2007 3:40PM
Subject: Re: address tag
← Previous message | Next message →
In message
< = EMAIL ADDRESS REMOVED = >,
Alastair Campbell < = EMAIL ADDRESS REMOVED = > writes
>(NB: I'll be changing the <abbr> to <span>, due to the title issue.
Microformats only use "title" on "abbr":
<http://microformats.org/wiki/abbr-design-pattern>;
For other discussion of the use of "abbr" in microformats, see:
<http://www.accessifyforum.com/viewtopic.php?t=6167&;postdays=0&postorder=asc&start=0>
--
Andy Mabbett
* Say "NO!" to compulsory ID Cards: <http://www.no2id.net/>;
* Free Our Data: <http://www.freeourdata.org.uk>;
* Are you using Microformats, yet: <http://microformats.org/>; ?
From: John Foliot - Stanford Online Accessibility Program
Date: Tue, Feb 20 2007 3:50PM
Subject: Re: address tag
← Previous message | No next message
Andy Mabbett wrote:
>
> Microformats only use "title" on "abbr":
>
> <http://microformats.org/wiki/abbr-design-pattern>;
>
> For other discussion of the use of "abbr" in microformats, see:
>
>
>
<http://www.accessifyforum.com/viewtopic.php?t=6167&;postdays=0&postorder=asc
&start=0>
...and with a simple addition to your style sheet:
<style>
vevent abbr.title{display:none;}
</style>
"Confusing" tool-tip gone. (And while some bemoan the fact that screen
readers respect this display instruction, here it actually is of benefit)
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