- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Tue, 13 Mar 2012 23:38:28 +0100
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: 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>
Silvia Pfeiffer, Wed, 14 Mar 2012 06:43:33 +1100: > On Tue, Mar 13, 2012 at 4:40 PM, Leif Halvard Silli: >> Silvia Pfeiffer, Tue, 13 Mar 2012 13:12:26 +1100: >> I have started to shop: https://bugs.webkit.org/show_bug.cgi?id=10448#c6 > Yes, I agree that there are differences between the elements that need > longdesc-like features. I also wouldn't restrict it just to <img> and > <video>/<audio>, but include <table>, <canvas> and other complex > elements that may better be described through an additional long text > description. > > I'd also not go quite as far as your recommendations go, The more general, the less element specific, I guess. > but rather > restrict it to a limited number of recommendations for how to display > the URL. Something more like what Alexey suggested on the same bug: > - adding a link to context menu; > - implementing a property inspector for end users, similar to the > Firefox one; > - use for fallback content when the element's display is disabled by > the browser (e.g. in text-only browser). > - expose to screenreaders through a11y APIs. But here you are, nevertheless, element specific: IMG. Can aria attributes be implemented differently, depending on the element? Should we have contex-menus for all the elements you mentioned? Btw, I'm not against property inspector. But I'm not sure it is very useful - not unless it is possible to activate the links it contain, e.g. >> 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. > > In HTML there is also no need to specify visual presentations etc. > They can't be part of the normative text. The rendering section of HTML5 *is* normative, but only for them for whom it is normative ... > However, it's always > possible to provide recommendations in non-normative text. I would > think that we can do that, too, in ARIA. It should at least so specific that it becomes reliable cross browser. >> 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. > > Sure. My main reason for going for another attribute is that I want it > used for more than just <img>. *My* main motivation is only that I have - or at least had - the impression that it would be faster specified that way. -- leif halvard silli
Received on Tuesday, 13 March 2012 22:39:02 UTC