W3C home > Mailing lists > Public > public-html-a11y@w3.org > November 2012

longdesc using #id

From: Charles McCathie Nevile <chaals@yandex-team.ru>
Date: Fri, 23 Nov 2012 15:21:09 +0100
To: "public-html-a11y@w3.org" <public-html-a11y@w3.org>
Message-ID: <op.wn74hjr7y3oazb@v3-151-181.yandex.net>
(chair hat off)


there has been some discussion about longdescs whose URL is a relative  
reference to somewhere in the page. And there have been implementation  
reports that some screen reader / browser combinations don't handle this  

I think that is a bug in the relevant software (maybe screenreader, maybe  
the underlying browser). There is a demo of longdesc that Patrick Lauke  
wrote to go with his Firefox extension, last updated in 2008, which uses  
internal page links, and the extension as well as the browser-native  
implementations of iCab and Opera all handle the case of an internal  
reference just as they would an external one.

In the original HTML specification of longdesc, the value of the attribute  
is given as URI, and that can be an internal or an absolute link (the same  
as the href attribute for a link). I don't know of any evidence that  
longdesc was intended to only work on external pages, despite some  
implementations failing if you don't do that.

During the seemingly endless discussions of ISSUE-30 in the HTML WG, one  
argument raised against longdesc was that it forced the description to be  
on a separate page. This assertion is not backed up by the spec, but by  
some implementations.

It seems to me that there are valid use cases for having the description  
on the same page as an image, and pointing to it. So I think the HTML 4  
spec was right, and we should re-affirm that, and file bugs against the  
software that doesn't implement it properly. (I have already done this for  
the Yandex browser...)



Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals@yandex-team.ru         Find more at http://yandex.com
Received on Friday, 23 November 2012 11:21:52 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:32 UTC