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

Re: Moving longdesc forward: Recap, updates, consensus

From: Tantek Çelik <tantek@cs.stanford.edu>
Date: Sat, 7 May 2011 09:51:57 -0700
Message-ID: <BANLkTimhtfN1WEGaUrA6F3GW9sVVCAYrJQ@mail.gmail.com>
To: John Foliot <jfoliot@stanford.edu>
Cc: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>, "Gregory J. Rosmaita" <oedipus@hicom.net>, Laura Carlson <laura.lee.carlson@gmail.com>, Charles McCathieNevile <chaals@opera.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>
Hi John,

Just a quick clarification on a couple of points.

On Fri, May 6, 2011 at 18:36, John Foliot <jfoliot@stanford.edu> wrote:
> Benjamin Hawkes-Lewis wrote:
>>
>> Here's Tantek's objection from the poll:
>>
>> "[@longdesc] is one of the worst forms of invisible metadata or "dark
>> data"
>> which are known to rot and become inaccurate over time (see: meta
>> keywords, RDF
>> in comments, sidefiles, etc.)."
>
> Links rot; this is a known problem.

To be clear - the data/content rot I refer to is *not* the link rot problem.

I'm talking about rot that occurs *in the same document*, not *across
documents*.

E.g. the first couple of examples given: meta keywords, RDF in
comments - are both hidden metadata in a document that has been known
to get out of sync with the visible (actual) content of the document
to the point of those features being entirely ignored by commonly used
search engines (search engines which do pay attention to links, rotten
or not).

In the case of "longdesc" - the content rot scenario is that a web
author changes the image (src) to point to something else, but forgets
to update the longdesc to point to a new description  because it is
hidden metadata and isn't apparent as being "wrong" when the author
refreshes the page in their browser to check it.

The longdesc URL itself may still be fully functional (i.e. no *link*
rot may have actually occurred).

The result is a new image, with a longdescription that no longer
applies to it. Doesn't matter for most users, and those that attempt
to access the longdesc get inaccurate information.


> (Here's another for you: http://tantek.com/CSS/19980106.html - check the
> link to HyperCard... BTW, Tantek is also a friend, and I don't mean to pick
> on him.)

Heh. No personal offense taken :)

And yes, links/markup on tantek.com are fair game (understand that
some old pages I may leave as is for historical purposes ;)

I'm actually a bit shocked that http://hypercard.apple.com/ doesn't at
least redirect to something else, like perhaps
http://support.apple.com/kb/DL1230?viewlocale=en_US

Perhaps Maciej can forward that onto someone.


> Link rot is a fact of the web, whether or not the links are referenced via
> @longdesc or via @src.

Agreed. But content rot and link rot are two different things. Just
wanted to clarify that.


> The problem with @longdesc today is not the attribute, it's the browsers'
> failure to make it discoverable to end users.

John, a while ago you proposed the alternative of using rel="longdesc"
and looks like there is a stub description evolving in the
microformats wiki (I started it with just a link originally but it's
grown since).

http://microformats.org/wiki/rel-longdesc

Is this still under consideration?

Seems to me there's much lower barriers to specification and adoption
of a rel="longdesc" (since 2003 more and more web authors are
cognizant of and actually using (even *new*) rel values on links per
XFN, rel=license, rel=tag and other rel microformats). And web authors
have become quite skilled at using progressive disclosure of their
content/links when their designs call for it.

Was there already a debate somewhere between longdesc="" vs. rel="longdesc" ?

Thanks,

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5
Received on Saturday, 7 May 2011 16:53:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:38 GMT