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