[uf-discuss] Re: One more shot at accessible hCalendar

[Belov, Charles]

Comments in-lined below.  This message includes responses to two
messages from the digest.

> Message: 5
> Date: Wed, 14 May 2008 14:38:56 +0100 (BST)
> From: "Toby Inkster" <mail at tobyinkster.co.uk>
> Subject: [uf-discuss] Re: One more shot at accessible hCalendar
> To: microformats-discuss at microformats.org
> Message-ID: <62483.81.2.120.180.1210772337.squirrel at goddamn.co.uk>
> Content-Type: text/plain;charset=iso-8859-1
> 
> Charles Belov wrote:
> 
> > Remember that any page these occur on would presumably have 
> a language 
> > specification such as "en-us" so computers would be able to 
> deal with 
> > standard month and day of week names and abbreviations.
> 
> I'm sorry, but this sounds like a really bad idea. Parsers 
> would need to maintain translation tables for day and month 
> names, plus abbreviations for them, plus some sort of 
> heuristic for figuring out the language of the page. (In 
> practice, many authors leave out lang/xml:lang attributes, 
> and Content-Language headers.)

If the web page or RSS feed leaves out the language attribute, then the
webmaster has not provided sufficient information to the parser and
cannot be said to have implemented this alternative method.  I do not
expect any scrapers to intuit the origin language.
 
> Andy Mabbett's proposed "data:" prefix already solves the 
> abbr design pattern accessibility issue and can be 
> implemented in just a few lines of code. All we need to do is 
> build support for it into parsers. (Cognition has supported 
> it since alpha2.1.)
> 
> Closest thing to a "specification" for the prefix:
> http://microformats.org/discuss/mail/microformats-discuss/2008
-February/011583.html

That solution consists of title attribute contains readable text,
followed by the word "data" followed by the actual data.  The screen
reader software will still read the data out loud, which, on a page full
of calendar items, would be sheer torture for the listener.

And it still begs the question as to how that data is going to get into
the page in the first place when a static HTML page is being created
manually by a non-technical person who has no access to the title tag.

> 
> ------------------------------
> 
> Message: 8
> Date: Thu, 15 May 2008 19:57:49 +1000
> From: "Michael MD" <mdagn at spraci.com>
> Subject: Re: [uf-discuss] Re: One more shot at accessible hCalendar
> To: "Microformats Discuss" <microformats-discuss at microformats.org>
> Message-ID: <002101c8b672$2285cc20$116bacca at COMCEN>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> 	reply-type=original
> 
> >> Remember that any page these occur on would presumably 
> have a language
> >> specification such as "en-us" so computers would be able 
> to deal with
> >> standard month and day of week names and abbreviations.
> >
> > I'm sorry, but this sounds like a really bad idea. Parsers 
> would need to
> > maintain translation tables for day and month names, plus 
> abbreviations
> > for them, plus some sort of heuristic for figuring out the 
> language of the
> > page. (In practice, many authors leave out lang/xml:lang 
> attributes, and
> > Content-Language headers.)
> 
> 
> If machine-readable dates were removed from the hCalendar 
> spec what would be 
> the point of using it?
> Accuracy of dates is CRUCIAL for calendar applications and 
> you would not 
> want to end up using unreliable heuristics to extract them!

I'm not sure what computer cannot read "January", "Jan", "Jan.", "1" or
"01" when surrounded by <span "dtstartmm"> and </span> and be able to
figure out that it means the first month of the year.

As with the previous post, it still begs the question as to how that
computer-readable data is going to get into the page in the first place
when a static HTML page is being created manually by a non-technical
person who has no access to the title tag.

Anyway, if you don't know what language the calendar item is in, how are
you going to know whether the plain language description of the event
needs to be translated?  You could wind up displaying a page full of
events that are perfectly timed but are described in plain text in 20
different languages.  Accurate, but unusable by most people.

Or you could choose to just show English events.  Or just French.  Or
just Chinese.  Etc.  In which case you would not have to worry about
multilingual heuristics.  I acknowledge you would still have to worry
about typos.

Hope this helps,
Charles "Chas" Belov
SFMTA Webmaster
http://www.sfmta.com/webmaster