Re: aria-describedat?

Benjamin Hawkes-Lewis <[email protected]> Wed, 14 Mar 2012 08:08:13 +0000
Newsgroups gmane.comp.mozilla.accessibility
Message-ID <CAEhSh3f7bpLkduMyH9iyD68Ak2kfAVzrXApUZfVLt9jxYBCtAw@mail.gmail.com>
On Wed, Mar 14, 2012 at 7:06 AM, Silvia Pfeiffer
<[email protected]> wrote:
> On Wed, Mar 14, 2012 at 9:44 AM, Benjamin Hawkes-Lewis
> <[email protected]> wrote:
>> On Tue, Mar 13, 2012 at 8:35 PM, Joseph Scheuhammer <[email protected]> wrote:
>>> On 12-03-13 3:35 PM, Charles McCathieNevile wrote:
>>>>
>>>> It *is* pretty much the same thing
>>>
>>> Nit and possible benefit:  @aria-describedbyat can be used with any element.
>>>  @longdesc is restricted to <img> only.
>>>
>>> Or, possible implementation headache :-)
>>
>> Spec writers are as free to allow @longdesc on other elements as they
>> are to mint new attributes and allow them on other elements.
>>
>> For example, one idea under discussion at HTML WG would allow
>> @longdesc to link to transcriptions for <video> elements.
>
> The biggest problem I see with @longdesc is that it is exposed as text
> in the IE DOM and as a link in other browsers. So, for backwards
> compatibility reasons there can't be a interoperable implementation of
> how to expose @longdesc in browsers. Accessibility APIs have dealt
> with this issue and are converting IE's text to a link, so it's not a
> problem for a11y, but only for browsers.

This is thoroughly confused. The DOM representation is precisely the
same in all popular browsers (.longdesc property with a string value).
The representation to accessibility APIs is different between Firefox
and Internet Explorer with this as with many other things, and AT that
support long descriptions handle those differences. Such
representations are worth standardising to free up competition, and
that's precisely what the HTML to Accessibility APIs mapping
specification will do. In any case, the differences in accessibility
API representations are not a problem for browsers seeking to
implement UI on top of @longdesc, since browser UI does not depend on
the accessibility API representation.

> Also, there aren't any
> consistent ways of how to expose @longdesc in browser UIs - this was
> always left to the browsers and browsers have mostly ignored the need
> to expose it or implemented diverging solutions.

iCab and Opera both expose @longdesc via the context menu. The same
implementation was proposed for Gecko in 2000 and for WebKit in 2007.

I think a better implementation would provide additional ways to
discover longdesc, but in general it's problem has not been that
people have been unable to think of any way to expose it.

--
Benjamin Hawkes-Lewis
_______________________________________________
dev-accessibility mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-accessibility