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 23:38:28 +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: <20120313233828278979.c1585be0@xn--mlform-iua.no>
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:00 UTC

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