Re: Drop longdesc, get aria-describedat?

On Tue, 13 Mar 2012 17:44:26 +0100, Leif Halvard Silli  
<xn--mlform-iua@målform.no> wrote:

> Charles McCathieNevile, Tue, 13 Mar 2012 08:08:46 +0100:
>> On Tue, 13 Mar 2012 06:40:48 +0100, Leif Halvard Silli:
>>
>>> 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.
>>
>> Longdesc isn't default fallback, it is extended support. (Or some
>> such terminology).
>
> In the bug, then it was Alexey from Webkit who asked if the longdesc
> URL - that is to say: the link, not the content at the end of the link
> - should be rendered visually as a link 'if image loading is disabled'.
> I thought that sounded like a great idea, and hence I said 'yes' to
> that. Why would that be a bad idea?

It isn't, a priori, it is a further form of "discoverable" and probably a  
good one. (That illustrates the value of not over-constraining the  
behaviour, and expecting progressively better ideas to come from  
experience).

  There's a bug for not showing all the alt that our devs are worried about  
fixing because it breaks compatibility by messing the layout around, and  
other browsers don't fix - maybe for the same or other reasons, I don't  
know.

> Note that he had 'disabled image loading' - and not 'rotten image URL'
> - in mind, in case that is important. [There are less concerns when
> image are disabled, one should think.]
>
> PS: The CSS WG has shown interest for being able to style broken
> images: http://lists.w3.org/Archives/Public/www-style/2012Jan/0168

This would help deal with the above problem.

> PPS: In Opera, if @src points to something that Opera doesn't recognize
> as an image file, then the contextual menu fails to render, and so the
> long description becomes unavailable. Seems like a bug?

Yep, seems like one to me. Did you file it, or should I?

>>> 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.
>>
>> There's no guarantee that the long explanation of an image is
>> textual, either. (Somewhere there is an example I made with audio, to
>> illustrate a different idea, or think of multi-modal CAPTCHA).
>
> Right. But that's completely another issue, AFAICT.
>
> What I had in mind was, that when an image URL is broken, then we know
> what we get: We get the alt text, and in most browsers we also get an
> icon to signal 'lacking image'. For video, if the video URLs are broken
> or the forma is not supported, then -a- we do not get a 'lacking video'
> icon'; -b- we might get flash fallback; -c- we might get a link to
> download the file to the disk. In short: We don't know what we get. And
> so, we cannot, as easily, e.g. decide to render the longdesc URL as a
> link if the video doesn't render, because it might break the fallback.
>
>>> This, IMO, points towards 'the HTML feature' rather than
>>> 'an ARIA feature'.
>>
>> Right.
>
> But note that the chairs have asked for *more* justification for why
> the CP ask for why @longdesc is needed specifically for <img>.

That's (subtly) the wrong question. There perhaps should have been more  
justification for why it is needed for images, which doesn't imply it  
isn't needed elsewhere.

cheers

-- 
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

Received on Tuesday, 13 March 2012 19:35:57 UTC