- From: Charles McCathieNevile <chaals@opera.com>
- Date: Tue, 13 Mar 2012 20:35:08 +0100
- To: "Leif Halvard Silli" <xn--mlform-iua@xn--mlform-iua.no>
- Cc: "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>, "John Foliot" <john@foliot.ca>, RichardSchwerdtfeger <schwer@us.ibm.com>, "W3C WAI-XTECH" <wai-xtech@w3.org>, "HTMLAccessibility Task Force" <public-html-a11y@w3.org>
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