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

(unknown charset) Re: Drop longdesc, get aria-describedat?

From: (unknown charset) Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Tue, 13 Mar 2012 06:40:48 +0100
To: (unknown charset) Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Cc: (unknown charset) John Foliot <john@foliot.ca>, Charles McCathieNevile <chaals@opera.com>, RichardSchwerdtfeger <schwer@us.ibm.com>, W3C WAI-XTECH <wai-xtech@w3.org>, HTMLAccessibility Task Force <public-html-a11y@w3.org>
Message-ID: <20120313064048292752.0f1ab018@xn--mlform-iua.no>
Silvia Pfeiffer, Tue, 13 Mar 2012 13:12:26 +1100:
> Anyway, I think we should write a spec and start shopping it around
> with browser developers to get some feedback and see if there is will
> to implement. Whether we call that attribute @aria-longdesc or
> @aria-describedat or just extend the existing @longdesc to video and
> audio and update its spec (which I frankly think is the maddest path
> of them all) doesn't really matter - a problem needs to be addressed.

I have started to shop: https://bugs.webkit.org/show_bug.cgi?id=10448#c6

This is a proposal for how Webkit should implement @longdesc in the 
chrome [context menu etc], the link behavior, how the CSS should work, 
how to become keyboard focusable and how VoiceOver should behave 
including when the longdesc announcement should be made - before or 
after the @alt text? And, not least: what do do if <img> is wrapped 
inside a link. Ideas are taken from many places, including the CP and 
Webkit's Alexey Proskuryakov who suggested that longdesc should be 
displayed when image wasn't display - which is a thought that we seem 
to not have dared thinking ...

One thing that struck me, as I was writing this - at least the things 
relating to fallback, is that much of what I was describing probably 
only makes sense for the <img> element. Simply because only the <img> 
element has a such a specific behavior whenever it isn't displayed. 
E.g. for <video>, <audio> etc, then there is no guaranteed fallback. 
And even if there is fallback, it isn't guaranteed to be a textual 
substitute. This, IMO, points towards 'the HTML feature' rather than 
'an ARIA feature'.

When it comes to implementing it as 'the HTML feature' or as a new 
'ARIA feature', then another reason to go for the HTML feature, is the 
issues related to fallback. Because, as we know, there is no fallback 
when it comes to ARIA attributes: Browsers are not required to render 
aria-label if the image doesn't display. And so, I think, that unless 
we describe it as a HTML feature, then we can't - as easily - justify 
that the feature looks like in the chrome, via CSS, or how the link 
behaves to normal users.

The chairs in their responses have asked for justification, and so, if 
we can justify it, then a HTML feature is all good, in principle, I 
think.
-- 
Leif Halvard Silli
Received on Tuesday, 13 March 2012 05:41:26 UTC

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