- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Fri, 9 Mar 2012 06:54:35 +0000
- To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- 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>
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