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" <[EMAIL PROTECTED]> > Subject: [uf-discuss] Re: One more shot at accessible hCalendar > To: microformats-discuss@microformats.org > Message-ID: <[EMAIL PROTECTED]> > 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" <[EMAIL PROTECTED]> > Subject: Re: [uf-discuss] Re: One more shot at accessible hCalendar > To: "Microformats Discuss" <microformats-discuss@microformats.org> > Message-ID: <[EMAIL PROTECTED]> > 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 _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
