Re: CfC: to maintain “Image Description Extension (longdesc)” Working Draft on the Recommendation track

On 01/27/2014 01:37 PM, Matthew Turvey wrote:
> I object to publishing this "Image Description Extension (longdesc)"
> Working Draft on the Recommendation track.
>
> Plan 2014 suggested people focus on providing a better solution to the
> use cases longdesc supposedly addresses.

Incorrect.  Here's what plan 2014 actually says:

"Allow the A11y TF the authority to produce an extension spec that 
defines a longdesc attribute. If such a specification obtains consensus 
and meets the proposed CR exit criteria by 2014Q2 it could be folded 
back into the core HTML spec by that time. This can be combined with a 
solution for issue 203 and/or with work on a purported replacement.

We ask those that oppose instating a longdesc attribute to focus on 
producing a better solution, and meanwhile not oppose those that wish to 
pursue longdesc via an extension spec or making progress towards 
demonstrating that it meets the identified CR exit criteria."

http://dev.w3.org/html5/decision-policy/html5-2014-plan.html#issue-30

> But as the chairs have
> already pointed out - twice - these use cases can already be solved
> with existing alternative techniques:
>
> http://lists.w3.org/Archives/Public/public-html/2010Aug/att-0112/issue-30-decision.html

This was subsequently reopened based on new information:

http://lists.w3.org/Archives/Public/public-html/2011Mar/0037.html

> http://lists.w3.org/Archives/Public/public-html/2012Feb/0058.html

After which, Laura agreed to provide additional links/clarification:

http://lists.w3.org/Archives/Public/public-html/2012Feb/0245.html

> And this has again been confirmed by Charles in the Last Call feedback
> noting "It is clearly possible to meet any given use case's
> requirements, and even a subset of all of them, with many kinds of
> solutions":
>
> http://lists.w3.org/Archives/Public/public-html-a11y/2013Feb/0093.html
>
> PF and HTML A11Y TF have recently again stated their intention to make
> longdesc obsolete, but understandably have a "strong concern of
> controlling when a longdesc attribute is obsoleted":
>
> http://www.w3.org/2013/10/31-html-a11y-minutes.html#item04
>
> In the meantime, longdesc is still being suggested as a viable
> technique, despite the well-known problems with longdesc usage
> including basic usability and POUR issues, the current poor level of
> UA/AT support, and the hopelessly polluted state of current longdesc
> usage:
>
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22777

It isn't clear what your point is here.  It is indeed true that there 
exist people who are still suggesting longdesc as a viable technique at 
this moment in time.

If you are suggesting that longdesc will not meet the proposed exit 
criteria, I encourage you to bring your evidence for this assertion forward.

> It seems there is a much stronger consensus around making longdesc
> "obsolete but conforming":
>
> http://lists.w3.org/Archives/Public/public-html-a11y/2012Dec/0030.html

Here you cite a proposal that was raised while publishing the document 
as a FPWD was being considered.  This matter was resolved a few weeks later:

http://lists.w3.org/Archives/Public/public-html-admin/2013Mar/0010.html

> "Obsolete but conforming" would also mean authors using a conformance
> checker can be informed via a warning that longdesc is not currently
> well supported, and the warning could contain links to alternative
> approaches that actually work right now:
>
> http://lists.w3.org/Archives/Public/public-html-a11y/2012Dec/0031.html

This is not a complete proposal.  It doesn't identify the alternative 
approaches.  Nor does it identify a plan to meet the exit criteria 
required for any specification which would include this proposal.

> I'd like to propose instead:
>
> 1. The HTMLWG publish this document as a Note to indicate work - and
> discussion - on this feature is finished
>
> 2. Reinstate longdesc into HTML5.0 as a "obsolete but conforming" feature
>
> 3. Make longdesc "obsolete" in HTML5.1
>
> This approach has the advantage of ensuring authors, implementors and
> this Working Group do not spend any more time on a feature that is
> known to be problematic for users at the current time, and that is
> going to be obsoleted in the near future anyway.

The key word in this is text is 'near'.  I've heard this for five+ 
years.  Lacking a complete and concrete proposal -- including a plan to 
address the exit criteria required -- usage of the the word 'near' in 
this context is premature.

> -Matt

- Sam Ruby

Received on Wednesday, 29 January 2014 11:58:58 UTC