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

I think this is a reasonable change.

Mark


On Thu, Sep 4, 2014 at 11:01 AM, Shane McCarron <shane@aptest.com> wrote:

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