Re: Drop longdesc, get aria-describedat?

Hi all,
I looked into firefox's IAccessibleAction implementation for longdesc.

they do indeed implement it and it does work.

One can use accprobe[1] to view the details and can invoke the implemented
action (doAccessibleAction) in the browser through the accprobe interface.

Invoking the method on an image that has a longdesc opens the longdesc URL
in a new tab.

[1] http://accessibility.linuxfoundation.org/a11yweb/util/accprobe/

so potentially any AT that uses IA2 could use this to provide access to
longdesc.

regards
Steve

On 9 March 2012 07:39, Steve Faulkner <faulkner.steve@gmail.com> wrote:

> hi ben,
>
> thanks for the following:
>
> they are using
> IAccessibleAction to provide an interface to @longdesc:
>
>
> https://developer.mozilla.org/en/XPCOM_Interface_Reference/IAccessibleAction
>
> have filed a bug against the api spec.
>
> regards
>  steve
>
> On 9 March 2012 06:54, Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>wrote:
>
>> On Fri, Mar 9, 2012 at 2:41 AM, Leif Halvard Silli
>> <xn--mlform-iua@xn--mlform-iua.no> wrote:
>> > Benjamin Hawkes-Lewis, Fri, 9 Mar 2012 02:03:12 +0000:
>> >> How would working on specifying @aria-describedat rather than
>> >> @longdesc persuade the opposed user agent representatives or otherwise
>> >> deliver wide user agent support?
>> >
>> > I think ARIA lives in another domain than @longdesc: Longdesc has
>> > demands/options for being available to all users. Whereas ARIA is
>> > specifically for accessibility.
>>
>> It is not possible to draw a line between "all users" and "accessibility".
>>
>> People sometimes argue that ARIA only affects the rendering of the web
>> into accessibility APIs, but (a) accessibility goes beyond
>> accessibility APIs and (b) that's not what the ARIA specification says
>> because this reflects a long-running identity crisis in the spec:
>>
>>     http://www.w3.org/WAI/PF/aria/introduction#ua-support
>>
>> > I suppose it is entirely possible that
>> > ARIA 1.1 does not get @aria-describedAT. But I also think that
>> > @aria-describedAT looks quite different from an ARIA angle than from an
>> > HTML angle. Just one question I picked up from Steve yesterday: Where,
>> > would you place @longdesc in [today's] accessibility APIs? The only API
>> > that has mapped @longdesc to anything, is the Microsoft MSAA api - but
>> > it has apparently mapped it plain wrong, see
>> > https://www.w3.org/Bugs/Public/show_bug.cgi?id=16268
>>
>> I'd normally look at what Gecko has done as part of baking IA2 into MSAA:
>>
>>
>> https://mxr.mozilla.org/mozilla-central/source/accessible/src/html/nsHTMLImageAccessible.cpp
>>
>> I'm no expert on how this stuff fits together (for that you want Aaron
>> Leventhal or David Bolter I think), but they are using
>> IAccessibleAction to provide an interface to @longdesc:
>>
>>
>> https://developer.mozilla.org/en/XPCOM_Interface_Reference/IAccessibleAction
>>
>> > Hence, I think that it is best that such a feature is sewn nicely into
>> > ARIA, in order to work well.
>>
>> @aria-describedat would almost certainly need to be expressed in
>> today's APIs, so if we cannot express @longdesc we will not be able to
>> express @aria-describedat.
>>
>> > Or, just consider how Jaws implements it:
>> > HTML5 has no chance at specifying it exactly the way JAWS implements
>> > @longdesc. It is too much details and issues etc.
>>
>> It doesn't need to. It needs to suggest an API mapping or (if worst
>> comes to worst) a DOM query that can be used by new AT to talk to new
>> browsers. JAWS etc can retain their current behaviors for legacy
>> browsers.
>>
>> >> Authors who want to keep providing hidden long descriptions even in
>> >> the absence of wide user agent support could be trivially supported by
>> >> producing an extension specification to HTML that makes @longdesc
>> >> conforming, along the lines of the HTML+RDFa extension specification:
>> >>
>> >>     http://dev.w3.org/html5/rdfa/
>> >>
>> >> "HTML5 + longdesc" could then be presented as an option in the W3C
>> >> validator.
>> >
>> > Such a spec would be less binding on the vendors, I guess. So yes, this
>> > could probably work, from that angle.
>>
>> It's not about "binding … vendors", since the HTML spec cannot force
>> vendors to implement whole user interfaces they do not want to
>> implement. What it can do is communicate that major browser vendors
>> aren't planning on actually implementing it. Communicating such
>> intentions is, as I described, an attenuated praxis of HTML WG in
>> producing the HTML5 specification. If our goal is just to give authors
>> a conformance target that includes @longdesc, this can be done in an
>> extending specification. If our goal is to actually make @longdesc
>> usable, that requires more.
>>
>> >> But to achieve wide user agent support, engagement with product
>> >> owners, developers, and designers is critical. Switching to another
>> >> attribute defined by PFWG seems like a distraction that would reset
>> >> user agent support from zero without doing anything to involve
>> >> essential contributors.
>> >>
>> >> I think the limited accessibility resources available would be better
>> >> spent on specifying how to deal with the existing @longdesc web corpus
>> >> (for example, in the HTML to accessibility APIs mapping document -
>> >> thanks for opening a bug for this) and on coming up with a good design
>> >> and patch for the Firefox @longdesc bug:
>> >>
>> >>     https://bugzilla.mozilla.org/show_bug.cgi?id=longdesc
>> >
>> > I see you point. And why not. My druthers would be that that we get a
>> > ARIA-fied @longdesc rather than a new @aria-describedAT.
>>
>> If by "ARIA-fied @longdesc", you mean implied ARIA semantics for the
>> @longdesc attribute, that would be nice. But it's not going to make
>> any significant difference to what browser vendors implement or
>> authors use.
>>
>> > But I think, in order to make it fit with the rest of ARIA,
>> > it is necessary that it is the *PF* that specifies whichever attribute
>> > one ends up choosing.
>>
>> As it's not blocking progress on making @longdesc usable, so I think
>> PFWG can take their time.
>>
>> > Yeah, deciding once and for all whose responsibility it is to specify
>> the long description link mechanism,
>> > would probably be the most important decision.
>>
>> Specifying @longdesc isn't the problem; designing and implementing
>> effective user interfaces for it is. I don't think it matters much who
>> specifies it if it doesn't make a difference to how or whether such
>> interfaces are implemented.
>>
>> --
>> Benjamin Hawkes-Lewis
>>
>>
>
>
> --
> with regards
>
> Steve Faulkner
> Technical Director - TPG
>
> www.paciellogroup.com | www.HTML5accessibility.com |
> www.twitter.com/stevefaulkner
> HTML5: Techniques for providing useful text alternatives -
> dev.w3.org/html5/alt-techniques/
> Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
>
>
>


-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html