W3C home > Mailing lists > Public > public-html-a11y@w3.org > March 2012

Re: Drop longdesc, get aria-describedat?

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Tue, 13 Mar 2012 11:33:49 +1100
Message-ID: <CAHp8n2=wUH5LoYi__gMSV3ON_FQTgejU-ihsMZQJAv8-027C6g@mail.gmail.com>
To: Charles McCathieNevile <chaals@opera.com>
Cc: John Foliot <john@foliot.ca>, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, RichardSchwerdtfeger <schwer@us.ibm.com>, W3C WAI-XTECH <wai-xtech@w3.org>, HTMLAccessibility Task Force <public-html-a11y@w3.org>
On Tue, Mar 13, 2012 at 11:14 AM, Charles McCathieNevile
<chaals@opera.com> wrote:
> On Mon, 12 Mar 2012 21:56:26 +0100, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote
>> On 13/03/2012, at 5:53 AM, John Foliot <john@foliot.ca> wrote:
>>> Quoting Charles McCathieNevile <chaals@opera.com>:
>>>> On Wed, 07 Mar 2012 20:04:16 +0100, Leif Halvard Silli
>>>> The specification can be done in a tiny amount of time if that is
>>>> needed. But without implementor commitment, it just isn't needed very
>>>> urgently. Understanding the basics can be done just as well by implementing
>>>> longdesc...
> ...
>>> Let's be crystal clear: without further support from the tool vendors
>>> (and I sidestep the fact that the browsers are a significant, but not
>>> exclusive member of that group) @longdesc will languish under-used, cheating
>>> users from functionality they require. But rushing to dump it and insert
>>> something "new" with even less support is stupid, and I will go so far as to
>>> suggest that anyone who fails to understand *THAT* also deserves the same
>>> title.
> Sure. What I meant by the below though, is that if it is stupid, but
> *works*, then it isn't so stupid.
>>>> If aria-describedat will get implemented, that is pretty much trumps for
>>>> me. But if an ongoing discussion about it is an excuse to do nothing for a
>>>> few extra weeks, I'd rather talk about something more productive.
>> We're spinning in circles. If implementers would rather implement a new
>> attribute the same across all browsers and for more elements than just img,
>> we should enable them to do so. Refusing to produce a spec because isn't
>> helping.
> I absolutely agree. If there is a will to implement, I don't think producing
> a spec is the issue. If that were the roadblock, I could find resources to
> make sure a spec is produced in a timely manner.
> I was trying to point out that *without* implementation commitment, having a
> spec is not that useful, since it requires some days of real work and the
> result isn't so different from where we are already. Certainly I think it
> should be obvious to a person of reasonable intelligence and familiarity
> with the state of the art roughly what such a spec might say.

The ePub spec is indeed quite a good start. I'd like to see
requirements on what the browser is required to do with the attribute,
e.g. the list stated in https://bugs.webkit.org/show_bug.cgi?id=10448.

I don't think we've asked any browser or screenreader devs yet whether
they'd resist an aria-describedat attribute.

Received on Tuesday, 13 March 2012 00:34:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:56:05 UTC