W3C home > Mailing lists > Public > public-html-a11y@w3.org > March 2012

Re: Drop longdesc, get aria-describedat?

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Fri, 9 Mar 2012 03:41:48 +0100
To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
Cc: Janina Sajka <janina@rednote.net>, Richard Schwerdtfeger <schwer@us.ibm.com>, W3C WAI-XTECH <wai-xtech@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>
Message-ID: <20120309034148166414.0caed61c@xn--mlform-iua.no>
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. 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

Hence, I think that it is best that such a feature is sewn nicely into 
ARIA, in order to work well. 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.

> 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.

> 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. Clearly, for 
those that *have* supported @longdesc - in the HTMLwg or by 
implementing it properly - such a thing would probably be very 
welcomed. 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. Yeah, deciding once and for all whose 
responsibility it is to specify the long description link mechanism, 
would probably be the most important decision.
-- 
Leif H Silli
Received on Friday, 9 March 2012 02:42:23 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:27 UTC