Re: Comments on HTML5 Image Description Extension (longdesc)

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