ISSUE-30: Chair review of Instate Longesc Change Propsoal

Hi Laura,

This is the Chairs' review of your Change Proposal for ISSUE-30: <>.

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


Received on Monday, 6 February 2012 23:04:23 UTC