W3C home > Mailing lists > Public > public-html@w3.org > October 2009

RE: ISSUE-30 (Longdesc) Change Proposal

From: John Foliot <jfoliot@stanford.edu>
Date: Tue, 27 Oct 2009 14:06:02 -0700 (PDT)
To: "'Jonas Sicking'" <jonas@sicking.cc>, "'Leif Halvard Silli'" <xn--mlform-iua@xn--mlform-iua.no>
Cc: "'Charles McCathieNevile'" <chaals@opera.com>, <public-html@w3.org>
Message-ID: <009e01ca5749$4a8f87f0$dfae97d0$@edu>
Jonas Sicking wrote:
> 
> I don't agree there's an expected difference.
> 
> Comparing the markups:
> 
> <img aria-describedby="desc">
> <a href="description.html" id="desc">...</a>
> 
> and
> 
> <img longdesc="description.html">


...Right, the first example has an explicit link *on the same page* as the
image, which IMHO is an unrealistic expectation given other 'design'
considerations that a content developer might have to juggle, while the
second (longdesc) example does not.  The fact that even you provided
'different' examples in illustrating your point shows that there is a huge
difference.  

I have already pointed to one example earlier in this thread
(http://lists.w3.org/Archives/Public/public-html/2009Oct/0951.html) where
the designer explicitly does not want a URL included on screen, and is in
fact using CSS to position the link off screen.  Meanwhile the longdesc
provides the same URL, but is not visible on screen, so the 'expected'
difference is significant: one you see the link, one you don't see the
link. You can argue all you want that putting a visible link to a longer
description on the same page as a complex image is "better" for all
accessibility, and you would be right, except that it is unrealistic to
expect that to happen all the time - longdesc is a mechanism for when that
'better' option is not available.

Also, aria-describedby *only* takes IDREFs, not URIs
(http://www.w3.org/TR/wai-aria/#aria-describedby), and there is no
anticipation that this will change any time soon.

Thus the outcomes are the same (a longer text description of the image in
question), but the path to getting there is very different. 

Finally, I am somewhat at a loss as to why there is resistance to
improving (or in this case, maintaining) the developer's toolbox with
specialty tools.  The cost to browser developers is minimal to zero, the
cost to content creators is a non-issue, AT support exists today and the
benefit (when applied) has significant enough value to preserve the
intent.  What 'value', exactly, do we receive by obsolescing the longdesc
attribute?

JF












> 
> In both cases I would expect AT to indicate to the user that a
> description is available for the image. And if the user chooses to
> access that description, there is no reason the UA couldn't perform
> exactly the same action in both examples. Be that navigating to
> "description.html" using the current tab, opening a new tab, reusing a
> dedicated "description" tab. Or not navigating at all and simply
> reading the contents of description.html to the user.
> 
> In neither case there is a specification that mandates how that
> description is presented to the user.
> 
> There *is* specified behavior for if the user activates the <a> link
> in the first example. However that behavior doesn't need to be
> followed if the user accesses the description for the image.
> 
> / Jonas
Received on Tuesday, 27 October 2009 21:06:37 UTC

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