Re: Drop longdesc, get aria-describedat?

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