Re: Comments on HTML5 Image Description Extension (longdesc)

Note that I am writing in my capacity as editor, and an implementor. Decisions on this are made by the Task Force. As co-coordinator I am partially responsible for determining when the group has consensus, but the following is my personal opinion and not some kind of "decision" or "official policy".

21.08.2014, 17:14, "Joanmarie Diggs" <jdiggs@igalia.com>:
> While Igalia shares many of the concerns raised by Apple [1] and has
> similar doubts about the benefits of longdesc, we will not formally
> object to advancing the HTML Image Description document along the REC
> track.

It seems that you managed to implement this pretty fast, and correctly. Could you tell us a little more about how long it took, and how difficult it was to get right?

> However, if longdesc does continue to advance, we have a number
> of concerns, many of which I identified whilst implementing support for
> longdesc in the Orca screen reader for GNU/Linux desktop environments.
> Below please find text Igalia would like you to consider incorporating
> into the specification.
>
> =====================================
> Proposed Additions to "3.0.2 Authors"
> =====================================
>
> *  Authors MUST NOT rely solely on longdesc as the means to provide
>    access to information which is essential for the user.

This is tricky, because it assumes that there is "essential" and "non-essential" information.

That isn't how longdesc works. It is precisely for cases where information is "essential" in the sense that users can get it, but that it is essential (for working at a reasonable level of efficiency) not to have to read it every time. A1000-word description of an image might be very important to somoene encountering it for the first time, but an incredible waste of that person's time afterward, when instead the title/alt of the image is more than enough.

I therefore don't think this wording is useful, and don't propose to add it.

> *  When the description is part of the target document, authors SHOULD
>    NOT rely upon assistive technologies to constrain presentation of the
>    description to that fragment. If such restriction is essential,
>    authors MUST take additional means to mark surrounding content as
>    hidden.

It is not clear that authors do rely on that. But also, asking authors to hide content is generally asking for trouble - they do that about as badly as they create longdescs (but with far more destructive effect).

I am therefore strongly opposed to this proposal as is. Perhaps a best practice is to note at the end of a "section" that there is some clear indication to users that they are entering a new section. But this applies to any document, not just a set of descriptions.

I welcome suggestions for how to frame this for longdesc in a way that doesn't suggest that the requirement is limited to such documents.

> =======================================
> Proposed Changes to "3.0.3 User Agents"
> =======================================
>
> Current:
>
>     If the longdesc value is valid, User agents must make the link
>     available to all users through the regular user interface(s).
>
> Issue:
>
>     One way to achieve the above is via the right-click menu. Firefox
>     does this. It works well for sighted users who can use a mouse.
>     It works well with the Orca screen reader which makes it possible
>     for the user to move to the image and then synthesize a right
>     click. But the image with a longdesc is likely not going to be
>     focusable, so keyboard-only users cannot navigate to it, which
>     is necessary prior to bringing up the context menu via the keyboard.
>
> Proposed modification to the above:
>
>     ... including users who cannot use a mouse and do not use any
>     assistive technologies.

I don't think this is a good idea. It doesn't convey the requirement that users of magnification software who can use a mouse can access the description (one group of users excluded by James Craig's "iframe" technique), nor various other situations.

"All users" is a pretty clear statement in english and in logic. But if we begin to characterise the users we mean, we run a great risk that people develop for that list instead of "all users" as they understand them - there is plenty of evidence that people react this way and e.g. design for screenreaders only (this is a problem with implementations of ARIA, although the specification doesn't actually suggest that all users with disabilities rely on accessibility APIs).

I don't think the longdesc spec is a good place to describe all the kinds of disabilities and interaction setups available, and therefore suggest we don't head partially down that path.

> 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. This could improve it for some implementations but won't cause any backward-compatibility problems I can think of.

I would rather ship a specification and then produce a revision based on further experience than spend another year with the attribute 
 in "limbo".

cheers

Chaals


> ============
>
> Thank you in advance for your time and consideration of these issues.
> --Joanmarie Diggs and Alejandro Piñeiro
>
> [1] http://lists.w3.org/Archives/Public/public-html-admin/2014Aug/0028.html

Received on Monday, 25 August 2014 13:16:46 UTC