Re: Drop longdesc, get aria-describedat?

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