- From: Steve Faulkner <faulkner.steve@gmail.com>
- Date: Fri, 9 Mar 2012 10:41:02 +0000
- To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Cc: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, 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: <CA+ri+VmbKKZPuRdzehO=YT-PEfLeP13RVtxq0MXVKSczbcrjOg@mail.gmail.com>
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
Received on Friday, 9 March 2012 10:41:54 UTC