W3C home > Mailing lists > Public > public-html@w3.org > March 2011

Re: example spec text for longdesc

From: Laura Carlson <laura.lee.carlson@gmail.com>
Date: Fri, 25 Mar 2011 12:36:32 -0500
Message-ID: <AANLkTimVX9FKMO4eBwEZXgHse8wO_u1ZkphfdavNKRjb@mail.gmail.com>
To: Aryeh Gregor <Simetrical+w3c@gmail.com>
Cc: Lachlan Hunt <lachlan.hunt@lachy.id.au>, Henri Sivonen <hsivonen@iki.fi>, HTML Accessibility Task Force <public-html-a11y@w3.org>, HTMLWG WG <public-html@w3.org>
Hi Aryeh,

Based on Lachlan's and Henri's feedback I deleted the sentence,
"Conformance checkers should issue errors if the longdesc URL has
certain file suffixes, such as .gif, .jpeg, .png etc.)", I could put
something like it back if people think it would be useful to have it
as a warning. Do you think that the example spec text is better with
or without it?

Aryeh, if longdesc is to be reinstated into HTML, do you have any
thoughts on how to improve the spec text at:
http://www.d.umn.edu/~lcarlson/research/ld-spec-text.html

Ideas for improvement are very welcome.

Best Regards,
Laura

-- 
Laura L. Carlson


On 3/25/11, Aryeh Gregor <Simetrical+w3c@gmail.com> wrote:
> On Fri, Mar 25, 2011 at 8:26 AM, Lachlan Hunt <lachlan.hunt@lachy.id.au>
> wrote:
>> It's completely bogus in the case of MediaWiki, for example.  Take this
>> randomly picked image from the front page of Wikipedia today.  The URL
>> ends
>> in .jpg, but it's to the image's summary page, not the image itself, and
>> so
>> this could actually be a perfectly acceptable URL for a longdesc (if the
>> page actually contained a suitable description).
>>
>> http://en.wikipedia.org/wiki/File:San_Giacomo_di_Rialto_%28Facade%29.jpg
>
> FWIW, we consider that a bug:
>
> https://bugzilla.wikimedia.org/show_bug.cgi?id=4421
>
> We've had anecdotal reports in the past that, for instance, Google
> doesn't index MediaWiki file description pages because of this,
> apparently with special exceptions for some high-profile sites like
> Wikipedia.  I haven't personally verified these reports, but they came
> from fairly credible sources.  Even if we fixed that, of course,
> there's still nothing to stop article names from ending in common
> extensions, like <http://en.wikipedia.org/wiki/Hello.jpg> (don't
> worry, no pictures in that article!).  It's occurred to me that we
> could add type="text/html" to such links to disambiguate them, if we
> thought anyone would use that info . . .
>
> Although anyway, yeah, you're right that extension sniffing is not
> completely reliable.
>
>


-- 
Laura L. Carlson
Received on Friday, 25 March 2011 17:38:07 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:23 UTC