Re: Comments on HTML5 Image Description Extension (longdesc)

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