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

I would be comfortable with that editorial change.


On Thu, Sep 4, 2014 at 8:42 AM, Charles McCathie Nevile <
chaals@yandex-team.ru> wrote:

> On Thu, 04 Sep 2014 13:40:04 +0200, Joanmarie Diggs <jdiggs@igalia.com>
> wrote:
>
>  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.
>>
>
> Thank you, that is good to know.
>
> [...]
>
>  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.
>>
>
> I believe that we could make an editorial clarification, and I believe
> that would be a useful thing to do. A suggestion for text following the
> requirement:
>
> Note that while in some cases this will allow user agents to present the
> description, there will be cases where user agents can not or do not
> restrict the information presented to the container element.
>
> What do you (and the rest of the Task Force) think?
>
> cheers
>
> Chaals
>
>
>  Thank you again for your time and consideration of these issues, and for
>> addressing our primary concern.
>>
>> --Joanmarie and Alejandro
>>
>>
>>
>>
>
> --
> Charles McCathie Nevile - web standards - CTO Office, Yandex
> chaals@yandex-team.ru         Find more at http://yandex.com
>
>