- From: Janina Sajka <janina@rednote.net>
- Date: Mon, 25 Aug 2014 23:22:38 -0400
- To: public-html-a11y@w3.org
Forwarding the following comment from NVDA with their permission ... James Teh writes: > Hi Janina, > > It has indeed been a while! All is well with us. I hope the same for you. > > For Firefox, the situation is the same. Where longdesc is present, we get an > accessible action of showlongdesc and we invoke that action. Presumably, > this is how it will work in Chrome too, but I'm not sure if they support it > yet. I believe this is the correct way to support it, and consequently, I > agree with Joanmarie that the spec wording needs to be fixed. > > For Internet Explorer, we have to extract the URL from the DOM and then use > the browser API to open that URL. However, due to IE's poor accessibility > implementation, direct DOM access is just how things have to be done. In > other words, don't use IE's implementation as the basis for how it *should* > be done. > > Hope this helps! > > Jamie > >-- > >James Teh > >Executive Director, NV Access Limited > >Ph +61 7 3149 3306 > >www.nvaccess.org > >Facebook: http://www.facebook.com/NVAccess > >Twitter: @NVAccess > >SIP: jamie@nvaccess.org Joanmarie Diggs writes: > Hi Charles. > > Thank you for your response. Of all the points you've made, there's one > in particular I'd like to address, namely: > > On 08/25/2014 09:16 AM, chaals@yandex-team.ru wrote: > > [...] > > > 21.08.2014, 17:14, "Joanmarie Diggs" <jdiggs@igalia.com>: > > [...] > > >> Other additions: > >> > >> If the longdesc value is valid, user agents MUST make activation > >> of the link possible via the platform's accessible action interface > >> on platforms where such an interface is present. > >> > >> When the description is only part of the target document, user > >> agents MUST provide a means to return to the image being described > >> via the platform's accessibility API. > > > > I think that is a useful suggestion for a future revision. I don't > > think it is essential - i.e. if it doesn't happen, I think people > > have managed to implement longdesc in such a way that it is still > > useful. > > [...] > > The reason I was able to implement support for longdesc is BECAUSE > Mozilla already does the first of the two above proposed additions, > namely to make activation of the link possible via AtkAction. Their > implementation via AtkAction is also what makes it possible for Orca, > and through Orca its users, to discover that a particular image has a > longdesc. > > If Mozilla had instead taken the following proposed spec text literally: > > If the longdesc value is valid, User agents must expose the > link to relevant APIs, especially accessibility-oriented APIs. > > And for a given image with a longdesc simply exposed a string with the > URL via ATK, Mozilla arguably would have fulfilled the specification. > BUT Orca could do nothing with the URL, and Orca would not be able to > support longdesc beyond what is described on the test results [1] for > Firefox with the Mac, namely: > > Access to the description is poor. You can get the URL of the > longdesc, then copy it and paste it into a tab > > And I'd likely have to add further support in Orca to accomplish that > poor level of access (i.e. by providing a means for the user to copy and > paste the exposed-to-Orca URL). If that constitutes "still useful," fair > enough. > > Having said that, perhaps I am being far too literal in my > interpretation of what "expose the link" means. If so, I apologize. And > if an appropriate response to a similarly-literal-minded user agent > developer is for me to tell them that "expose the link," in the case of > ATK/AT-SPI2, means "make activation of the link possible via AtkAction" > then it's all good. :) > > Something which may be relevant to this discussion and to understanding > my concerns as a screen reader developer implementing support for > longdesc: Orca does not have a virtual buffer or any off-screen > (re)rendering of content. Orca does not go off and fetch content > (longdesc or otherwise) to present it to the user. Orca does not load > pages on behalf of the user. When you use Orca with Firefox, you are in > Firefox. Mind you, Orca does take over navigation (considerably so!) so > that you can browse, interact with forms and web apps, jump quickly > amongst elements of a given type, etc., etc. as you would expect to be > able to do in a screen reader. But that's simply alternative/enhanced > navigation within content which is already rendered by the native > application. Long way of saying: Something (other than Orca) needs to > display the longdesc in order for the description to be navigable (and > hence accessible) to Orca users. It is insufficient to simply "expose > the link to ... accessibility-oriented APIs" if "link" means "string > containing the URL where the description can be found." > > I hope that clarifies things a bit. > --joanie > > [1] http://w3c.github.io/test-results/html-longdesc/cr-report.html -- Janina Sajka, Phone: +1.443.300.2200 sip:janina@asterisk.rednote.net Email: janina@rednote.net Linux Foundation Fellow Executive Chair, Accessibility Workgroup: http://a11y.org The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI) Chair, Protocols & Formats http://www.w3.org/wai/pf Indie UI http://www.w3.org/WAI/IndieUI/
Received on Tuesday, 26 August 2014 03:23:12 UTC