W3C home > Mailing lists > Public > public-html@w3.org > February 2012

Re: ISSUE-30: Chair review of Instate Longesc Change Propsoal

From: Laura Carlson <laura.lee.carlson@gmail.com>
Date: Mon, 20 Feb 2012 15:36:46 -0600
Message-ID: <CAOavpveJ8COgzKGyYPHkXG8qunnnf2iH+QSZn84+ZgdgWvGVVQ@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: "public-html@w3.org LIST" <public-html@w3.org>
Hi Maciej,

> Thanks for the updates, these are great. Linking specific criteria to
> relevant information that justifies them is very useful.
>
> It seems like the following criteria still do not seem to include
> justification, at least not inline, or directly linked:

Thanks, Maciej. I will work on providing more links/further clarification.

Best Regards,
Laura

On Thu, Feb 16, 2012 at 9:07 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> Thanks for the updates, these are great. Linking specific criteria to relevant information that justifies them is very useful.
>
> It seems like the following criteria still do not seem to include justification, at least not inline, or directly linked:
>
> - "Accessing the long description cannot take the user away from the user's position in the document containing the image where the description was invoked as it would cause basic usability/accessibility failure."
> - "The blind user must be allowed direct access to the long description while simultaneously being allowed direct access to the link to the company home page for equal access.
> - "Direct, dual, programmatic access to both a long description and to the larger version of an image from a thumbnail image, in order to accommodate both blind and sighted users needs."
> - "Ability to reuse to the same text for both the large and thumbnail image for authoring efficiency."
> - "Customization of content in accordance with user needs and capabilities."
> - "Ability for an image to appear on two pages in the site while at the same time linking to one longdesc page for efficiency."
> - "The repository must allow for contribution and modification of image descriptions in a collaborative and moderated fashion, as the hosted descriptions will be living documents."
> - "The long description mechanism must be able to point to external sources that allow the full use of HTML as well as other markup languages, such as MathML or SVG."
> - "The long description mechanism must allow maintaining and updating existing descriptions that utilize the longdesc attribute."
>
> At this point, it is up to you whether you want to make further improvements to these.
>
> Regards,
> Maciej
>
>
> On Feb 14, 2012, at 1:41 PM, Laura Carlson wrote:
>
>> I mentioned this to Maciej already: key constraints are linked from
>> the use cases. And my use case rebuttals are linked in the notes for
>> each use case.
>>
>> Best Regards,
>> Laura
>>
>> On Tue, Feb 14, 2012 at 9:38 AM, Laura Carlson
>> <laura.lee.carlson@gmail.com> wrote:
>>> Hi Maciej,
>>>
>>> Like John's comments, I have linked my comments in the change proposal itself.
>>> http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc#Responses_to_Arguments_Against_Retaining_Longdesc
>>>
>>> Redoing all of that is just busy work.
>>>
>>> Best Regards,
>>> Laura
>>>
>>> On Tue, Feb 14, 2012 at 9:33 AM, Maciej Stachowiak <mjs@apple.com> wrote:
>>>>
>>>> Hi Laura,
>>>>
>>>> Thanks for providing the linked documents that include your planned objections to the other proposals. While some material in these objections would be acceptable for a survey objection, other material seems required in order for your Change Proposal to be complete.
>>>>
>>>> In particular:
>>>>
>>>> - Justifying the constraints for your use cases needs to be in the actual Change Proposal, not just in a survey objection. This is for two reasons: (a) without justifying the parameters of your use cases, your Change Proposal will be incomplete as written, since it will not actually include complete rationale; and (b) for any justification you provide, in others (responding to the survey, or in their own Change Proposals) must have a fair opportunity to examine and potentially dispute that justification. Therefore, this material needs to be in the Instate Longdesc Change Proposal itself, in order for the Change Proposal to be complete. Furthermore, in your survey comments, you include material that could be justification of some of the use case constraints, but it is not clear that all are justified. It is hard to be certain given how the material is structured.
>>>>
>>>> - Material that rebuts or criticizes other specific proposed solutions to the use cases, or that disputes claims that some use cases are invalid, can be left to a survey comment. That sort of material could be considered commentary on the other Change Proposals, as opposed to material required to make your own complete.
>>>>
>>>> Therefore, while it's great that you have prepared this material, the Chairs feel that some updates to your Change Proposal are still required to make it complete.
>>>>
>>>> Regards,
>>>> Maciej
>>>>
>>>> On Feb 7, 2012, at 5:07 AM, Laura Carlson wrote:
>>>>
>>>>> Hi Maciej,
>>>>>
>>>>> Justification is supplied in my objections to the two other proposals.
>>>>> Please refer the following two attached documents.
>>>>>
>>>>> 1. Objection to the Proposal Keep the longdesc attribute for the img
>>>>> element deprecated: comments-js.html
>>>>> * Objection to the Proposal Zero Edit/Obsolete longdesc: comments-mt.html
>>>>>
>>>>> Best Regards,
>>>>> Laura
>>>>>
>>>>> On Mon, Feb 6, 2012 at 4:59 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>>>>>>
>>>>>> Hi Laura,
>>>>>>
>>>>>> This is the Chairs' review of your Change Proposal for ISSUE-30: <http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc>.
>>>>>>
>>>>>> The Change Proposal appears to include all the required sections, with the necessary content.
>>>>>>
>>>>>> In this review, we focused on issues with the sections relating to use cases. Use cases are key. The primary basis for the previous decision was the fact that no use case was shown to specifically require longdesc.
>>>>>>
>>>>>> Some specific comments on the use cases:
>>>>>>
>>>>>> - The use cases each list a number of constraints, however, no justification is presented for the specific constraints chosen. The range of possible solutions for each use case seems driven more by the constraints than the use case per se; while the use cases themselves seem plausible enough to be self-justifying, the constraints are not always so self-evident. The use cases would be improved by providing justification for the listed constraints.
>>>>>>
>>>>>> - In some cases, the constraints exclude other solutions that might otherwise be equally valid, for example : "Must use a basic HTML technique as that is the employees' skill set. Library's budget does not have money for employees to be trained in other techniques (ARIA, CSS, JavaScript etc)." This kind of claim particularly calls out for justification. If it is indeed commonplace for content authors to be familiar with proper use of longdesc, but unable to learn even a subset of ARIA or CSS, then some evidence should be presented that this is the case. Otherwise, this type of constraint is likely to be disputed.
>>>>>>
>>>>>> - The previous decision was not based on the idea that longdesc could not possibly be used to address any use case. Rather, the basis that other features of the language could sufficiently address the use cases proposed for longdesc. The use cases listed in this Change Proposal do make the case that longdesc is *one* possible solution, but they do not directly  make the case that there are no other solutions. They do not, in general, indicate that longdesc is the only viable solution, or provide justification for some claims. Some information along these lines is provided elsewhere, but see below.
>>>>>>
>>>>>> - The most common specific technique proposed by alternative Change Proposals is aria-describedby. The "Suggested Alternatives Are Not Viable Solutions" section lists some claimed general issues with aria-describedby, it does not explain why aria-describedby would fail to meet the specific use cases cited. The updated Zero Edit Change Proposal identifies alternate techniques that are claimed to work for specific use cases without using longdesc <http://www.w3.org/html/wg/wiki/ChangeProposals/LongdescZeroEdit#Use_Cases>. They use techniques such as aria-describedby, image maps, or ordinary links, depending on the use case. A general list of concerns with various techniques does not rebut these alternate solutions. The Instate Longdesc Change Proposal would be stronger if it explained why the proposed alternate solutions are not valid.
>>>>>>
>>>>>> - The updated Zero Edit Change Proposal finds many of the constraints listed for the use cases to be debatable, and gives arguments for why many are not plausible constraints: <http://www.w3.org/html/wg/wiki/ChangeProposals/LongdescZeroEdit#Use_Cases>. This makes it even more important to justify the constraints, as previously mentioned.
>>>>>>
>>>>>> - The updated Zero Edit Change Proposal rejects three of the use cases as invalid and provides arguments for these claims, specifically for the "Facilitating text image descriptions", "Describing text Images", and "Describing a Newspaper Image" use cases. The Instate Longdesc Change Proposal would be stronger if it offered arguments against these claims of invalidity.
>>>>>>
>>>>>> - The "Related Solutions Do Not Negate the Need for longdesc" section claims that the existence of alternate techniques does not negate the need for authors to use longdesc. In other words - even if there are alternate techniques to satisfy any given use case, longdesc is still needed and useful But no evidence is offered to support this claim.
>>>>>>
>>>>>> - The linked response to Jonas's Change Proposal from John Foliot makes further arguments against techniques such as aria-describedby. However, there are no specific arguments here explaining why the alternate solutions in <http://www.w3.org/html/wg/wiki/ChangeProposals/LongdescZeroEdit#Use_Cases> fail to satisfy their use cases. Specific problems with satisfying a use case are likely to be more persuasive than raising general issues.
>>>>>>
>>>>>> The Chairs may provide further feedback on non-use-case sections of the Change Proposal at a later time. However, at this time, we feel that the points about use cases are essential to address and there is no need to go further until they are addressed. And if they are sufficiently addressed, then it may be that further changes will not be needed.
>>>>>
>>>>> --
>>>>> Laura L. Carlson
>>>>> <comments-mt.html><comments-js.html>
>>> --
>>> Laura L. Carlson
>>
>>
>>
>> --
>> Laura L. Carlson
>>
>



-- 
Laura L. Carlson
Received on Monday, 20 February 2012 21:37:16 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:30 UTC