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

Hi Janina.

Comments regarding individual resolutions are below. In short, we accept
the Task Force's resolutions of our comments, though we do not
necessarily fully agree with them. We have no plans to raise any formal
objections.

In order to simplify our response, we've reordered the text (preserving
the numbering you assigned).

> YOUR COMMENT #4
>> 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.
>
> DISPOSITION: Accepted
>
> We have edited the specification to provide  a more generic statement
as follows:

[...]

Thank you. We very happily accept this resolution. This issue was our
chief concern as it has direct impact on Orca's ability to provide
support for longdesc.

Regarding Comments #1, #3, and #5 which are all marked as "DISPOSITION:
Not accepted", we accept the Task Force's decision.

Mind you, we still have concerns that authors will use longdesc for
things which are necessary for understanding core content (our
definition of "essential") and which the user might not be able to
access due to issues such as difficulty in discovery and/or difficulty
in activation and/or lack of support in a given user agent. We also have
concerns about how the user can efficiently return to the described
element in user agents which do have longdesc support. But our concerns
are not specific to Orca users or our platform. Hopefully through a
combination of guidance and feedback from end users and developers of
assistive technologies, authors and user agents will sort out how to
properly use and support longdesc.

As for the remaining comment:

> YOUR COMMENT #2
>> *  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.

We would agree were it not for the fact that this specification contains
the following text:

     When a description is only part of the target document, authors
     SHOULD link to a container element in the target document that
     contains the entire description.

Given the "well-known failing of HTML fragment IDs in general," putting
the description in a fragment seems like a bad idea. But assuming that
authors know about these limitations/failings (can we assume that?) and
have an overriding need to put the description in a fragment, the
specification states that authors SHOULD put the entire description in a
container element. Why SHOULD authors do so? The specification doesn't
say. Thus speculating on why and the expected results of doing so seems
to be left as an exercise for the reader.

As readers, we speculated. And our conclusion is that it is not
unreasonable for authors to walk away from the above specification text
believing the following: Putting the entire description in a container
element will make it possible for user agents and/or assistive
technologies to constrain the presentation of the description to that
element.

Here's our problem with that: At least in the case of content being
accessed via web browser, if authors do walk away from the specification
believing that presentation of the description will be constrained to
that element, they will be sadly mistaken -- at least on our (GNU/Linux)
platform. We believe VoiceOver may have a similar issue.

Thus we would find it helpful if the specification were more clear with
respect to why authors should put the entire description in a container
element and/or what authors should be aware of with respect to platform
differences. Can this not be accomplished through some clarifying,
nonsubstantial change? If the answer is "no," then our response is that
while we do not agree with the resolution to our Comment #2, we can live
with it.

Thank you again for your time and consideration of these issues, and for
addressing our primary concern.

--Joanmarie and Alejandro

Received on Thursday, 4 September 2014 11:40:45 UTC