Chair review of "Keep Longdesc Deprecated" Change Proposal for ISSUE-30

Chair feedback on the Keep Longdesc Deprecated proposal:

http://www.w3.org/html/wg/wiki/ChangeProposals/DeprecateLongdesc

- In general, this Change Proposal includes all of the required parts, has sufficient detail to be applied unambiguously, and provides rationale for the changes proposed.

Here are the key points of feedback, relative to other Change Proposals:

- The proposal claims that aria-describedby, combined with the enhancements to aria-describedby that it proposes, can address the use cases for longdesc. Use cases were the key issue in the original ISSUE-30 decision, in particular the lack of presented use cases that are uniquely addressed by longdesc.  It would be helpful to enumerate each of the use cases mentioned in the InstateLongdesc proposal and, for each, show how aria-describedby could be used and why it would be equivalent or better for that specific use case.

As Sam wrote regarding the zero-change proposal for this issue: "The history of this issue is that the primary reason that the original proposal to instate Longdesc wasn't selected was lack of use cases.  Use cases were later provided and the chairs have publicly stated that that information would likely have materially affected the outcome of the last survey."

As a result of similar feedback on the zero-change proposal for this issue, a "Use Cases" section was added, addressing each of the use cases from the InstateLongdesc proposal: <http://www.w3.org/html/wg/wiki/ChangeProposals/LongdescZeroEdit#Use_Cases>. This chaange made the "Zero Edit" Change Proposal significantly more effective. We recommend either incorporating a similar explanation to the "Keep Longdesc Deprecated" proposal, or referencing the "Zero Edit" proposal, or some combination.

- As compared to the zero edit Change Proposal for this issue, this proposal suggests a material change, namely allowing aria-describedby to reference hidden elements. However, it does not provide any specific use cases that justify this change. In the course of ensuring that all use cases are addressed, this proposal should be updated to show that either some use cases cannot be fully met without this change, or that some cases cannot be met as effectively without this change, or some combination. Otherwise, there will be no reason to consider this proposal over the zero change proposal.

Here are some less essential points of feedback:

- The Change Proposal claims that "a lot of people seem to misunderstand how the attribute works". The supporting argument is that the attribute is used incorrectly in "a large number of cases". No concrete evidence of this point (not even a single example) is provided.

- The Change Proposal argues that one problem with longdesc is that it encourages putting the description in a separate document. It does not explain why this is a problem. Mentioning concrete downsides of using a separate document would make this argument stronger.

- Many of the Positive Effects points are presented without supporting evidence or arguments. Some of these may be implied by the rest of the proposal, but it is better to make the arguments explicit. Example of a point presented without zupporting evidence or arguments:
  * Makes it possible to write simpler tutorials for how to make HTML5 contents accessible.
Example of a point presented with a supporting argument:
  * Allows tools to be simpler since they can use a single mechanism for providing descriptions for elements.

- A few other points lack specific supporting evidence: "browsers have traditionally been very reluctant", and "dividing their time between longdesc and aria-describedby" are claims presented without evidence. Likewise, it is not clearly established that the education savings would outweigh the cost of updating educational materials.

- In addition, John Foliot presented some counter-arguments to the Deprecate Longdesc proposal: <http://www.w3.org/wiki/A11yTF/longdescresponse>. While the Chairs have not yet reviewed the merits of these counter-arugments in detail, we nontheless advise reviewing and addressing them (whether by changing what is proposed or simply offering explanations), since these comments were specifically written to address this Change Proposal.


If anybody plans on either revising any of the current proposals or to submit a new proposal based on this feedback, please let us know so that we can plan accordingly.


On Oct 17, 2011, at 11:58 AM, Sam Ruby wrote:

> 
> It must be noted that this change proposal does propose a change, namely to make inline ARIA links valid.  

Actually, the change it proposes does not relate to inline ARIA links; rather, it makes ARIA references to hidden elements valid. I changed the feedback to point out that no use cases are given to justify this, so modulo this detail, I agree with your comment below.

> It suggests this without making any reference to any use cases.  It doesn't attempt to show existing usage where people are doing this today.  It doesn't even mark up an existing site to show how it could be improved.  It merely states the author's belief that somehow this would be preferred.  I think this needs a bit more than mentioning concrete downsides.  At a minimum, I would like to see some shred of evidence that the proposed beneficiaries would actually make use of this feature if it were adopted.

[...]

> But mostly, this proposal needs to be updated (or withdraw) to reflect the fact that we now have a strong proposal to make longdesc invalid. This proposal needs to make the case that making longdesc completely invalid would harm HTML5, while simultaneously make the case that making the case that making longdesc completely valid would also harm the web.  If "a lot of people seem to misunderstand how the attribute works", why not remove it entirely?

I don't think this is a material difference between the two Change Proposals. The zero-change proposal proposes literally no changes in its Details section, and therefore does not change the validity of longdesc from what it is now in the current HTML5 draft. Jonas's proposal has some changes, but not to londesc, so it also does not make longdesc more or less invalid. Under either proposal, longdesc would continue to have a status of "obsolete" and therefore invalid, but documented for historical purposes. So I think this second difference you describe is not a real difference between the proposals, just a difference in wording. Therefore I did not address it.

Regards,
Maciej

Received on Tuesday, 20 December 2011 19:01:04 UTC