TF response to your comments on HTML5 Image Description Extension (longdesc)

Dear Joanmarie Diggs and Alejandro Piņeiro:

Thank you for your comments on the Candidate Recommendation (CR) publication
of HTML5 Image Description Extension (longdesc) [1] as provided in your email
archived at [2] and further explained in your email at [3].

The HTML-A11Y Task Force has reviewed all comments received on the draft. We
would like to know whether we have understood your comments correctly and
whether you are satisfied with our resolutions.

Note that we have numbered your comments in order to aid in the
discussion of your individual points.

Please review our resolutions for your comments, and reply to us as soon
as possible to say whether you accept them or to discuss additional
concerns you have with our response. If we do not hear from you by 9
September, we will mark your comment as "no response" and close it. You
can respond by email by replying to this message.

Note that if you still strongly disagree with our resolution on an issue, you
have the opportunity to file a formal objection (according to 3.3.2 of the W3C
Process [4].  Formal objections will be reviewed during the transition meeting
with the W3C Director, unless we can come to agreement with you on a
resolution in advance of the meeting.

Joanmarie Diggs writes:
> ... 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.

DISPOSITION: Not accepted

Whether a longdesc is essential or nonessential will depend on
circumstance. It will vary among users, and will even vary for the same
user given different circumstances.

The point of the longdesc feature is to make it easy for the user to
access that information, or to readily skip past it as their needs of the moment
may dictate.

> *  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.

DISPOSITION: Not accepted

While we appreciate the concern regarding content in fragment IDs, this
is a well-known failing of HTML fragment IDs in general. This
specification is not the appropriate place to attempt remedies. In
particular we do not want to encourage hiding text, since it is very
often done in such a way as to make it inaccessible - for example to
people who are not using a screenreader but have+some other
accessibility requirement or preference.

Your concerns are, however,  appropriate for discussion in future authoring
guidance and will be forwarded accordingly.

> 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.

DISPOSITION: Not accepted

We consider it counterproductive to attempt to prescribe user agent
behavior beyond the general requirement to support "all users." Rather,
we rely on other W3C guidelines, particularly the WAI User Agent
Accessibility Guidelines, to further explain how this provision can be

> 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.


We have edited the specification to provide  a more generic statement as follows:

"If the longdesc value is valid, User agents must expose the longdesc to
relevant APIs, especially accessibility-oriented APIs in a manner most
appropriate to the API."

Informative "What is most appropriate to an API will vary with the
individual API. Some APIs (like MSAA) will need the text string which
constitutes the URL of the longdesc.  Other APIs may provide an
actionable interface."

>     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.

DISPOSITION Not accepted

As noted above, issues with fragment IDs are well known for HTML
generally. It is thus beyond the scope of this specification to improve
the specification of fragment ID expected behavior.

But, as before, describing the issues and suggesting best practices is
clearly appropriate for authoring guidance and we will forward this
concern accordingly.

> Thank you in advance for your time and consideration of these issues.
> --Joanmarie Diggs and Alejandro Piņeiro

Thank you for your time reviewing and sending comments on your
experience and observations implementing this specification for Orca.
Though we cannot always do exactly what each commenter requests, all of
the comments are valuable to the specification development process.


Janina Sajka, for the HTML-A11Y Task Force Co-Facilitators



Janina Sajka,	Phone:	+1.443.300.2200

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup:

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair,	Protocols & Formats
	Indie UI

Received on Tuesday, 2 September 2014 23:11:07 UTC