Re: Drop longdesc, get aria-describedat?

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

Received on Friday, 9 March 2012 06:55:25 UTC