- From: Joanmarie Diggs <jdiggs@igalia.com>
- Date: Mon, 25 Aug 2014 12:38:26 -0400
- To: chaals@yandex-team.ru, "public-html-a11y@w3.org" <public-html-a11y@w3.org>
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
Received on Monday, 25 August 2014 16:39:35 UTC