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

Re: Epub's DescribedAt [Was: Drop longdesc, get aria-describedat?]

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Fri, 16 Mar 2012 16:07:17 +1100
Message-ID: <CAHp8n2mOzN808xatLBYjc+Fy7YyaFuHDzM97nQeZ=1rTGU6vDw@mail.gmail.com>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Charles McCathieNevile <chaals@opera.com>, 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>
Hi Janina,

I just saw this email. Too many discussions! :-)

On Wed, Mar 14, 2012 at 3:17 AM, Janina Sajka <janina@rednote.net> wrote:
> Silvia Pfeiffer writes:
>> 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.
> A good start, perhaps. But also a troubling development from the ARIA
> timeline perspective.
> Notice that the Epub DescribedAt supports multiple URIs. In our brief
> discussion of the underlying use cases, as we understand them currently,
> we found we are unconvinced that this simply providing multiple URIs,
> space delimited, is either sufficient or the best way to address the
> requirement.
> On what basis does the user agent choose among the URIs:
> *       When the choice is I18N based?
> *       When the choise is grade level based?
> *       When the choice is some other heuristic?
> Let me note that PF and DAISY/IDPF have agreed to discuss architecting
> the Epub requirements even before this topic came up in email here.
> Regretably, because of various travel schedules, we are unable to hold
> that call until early April.
> Let me note further that this "multiple target list" requirement could
> conceivably postpone ARIA-DescribedAt to ARIA 2.0 by reason of this
> added complexity. We've just begun considering the implications
> here--and they're significantly more involved than a basic HTML longdesc
> replacement feature applicable to various elements.

I agree. I don't think it makes sense to have more than one link in
the attribute.

Received on Friday, 16 March 2012 05:08:05 UTC

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