Review of longdesc CPs, was: Re: uneven handling of issues

Those change proposals have become interesting resources in their own right.
Note: I am not a chair nor W3C member.

tl;dr: The negative effects of dropping longdesc measurably outweigh the 
positive impact of removing the attribute. It appears, the positive 
impact is limited to encouraging authors to use ARIA. Authors should be 
using ARIA regardless of longdesc.

Aside:
Neither usemap nor longdesc are used with the Canvas object: Canvas is 
scripted, and Image is not. Canvas has the subtree, SVG has title and 
description, Image has alt, title and longdesc. Image is the 
least-expressive and simplest of those specs. Thus usemap and longdesc 
exist, to represent the limited tree that Image implementations should 
support.

Note the cross-over technique: <img src="document.svg" />
This is a generic SVG file referenced by an image element.

This seems appropriate, understandable and short.
<img src="document.svg" longdesc="document.svg" />


I've reviewed the cases and I most of the content reads like Techniques 
for WCAG 2.0.
http://www.w3.org/TR/WCAG-TECHS/Overview.html


This proposal for marking longdesc as non-conforming is a rich resource 
of potential ARIA techniques:
http://www.w3.org/html/wg/wiki/ChangeProposals/LongdescZeroEdit

It's a great document, I don't think it proves its argument: Zero Edit 
Change Proposal: Keep Longdesc Non-Conforming
"HTML5 will send a clear message that longdesc cannot be relied on to 
provide long descriptions, as most developers and accessibility 
practitioners already know, and that the time has come to move on to 
more perceivable and robust solutions for providing long descriptions 
like aria-describedby and rel=longdesc."

The proposal for including longdesc also has a great list of techniques.
http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc

This, I believe, proves its argument:
Issue 30 Change Proposal: Include longdesc in HTML5
"Provides a method for the long description to be programmatically 
determinable when an image already has a link which is mapped to go to 
another document or a larger image ... [that is] recognized by existing 
authoring tools, user agents, assistive technologies, educational 
material, etc."

Whatever "reliability" longdesc has, it's out there, in use, and it's a 
viable option for authors. Authors using longdesc should also use ARIA 
semantics and other WCAG techniques. Nobody is arguing against ARIA 
here, and yet the arguments against longdesc suggest that ARIA support 
will be harmed by the co-existence of longdesc.

That brings us to the third proposal:
http://www.w3.org/html/wg/wiki/ChangeProposals/DeprecateLongdesc

The proposal attempts to change the definition of "hidden", which I 
believe has many side effects and complications not otherwise 
considered. It otherwise repeats the Zero Edit proposal, that rel and 
aria vocabulary should be used. I've not seen sufficient evidence that 
rel="" microdata is supported, nor that anchor links can be applied 
without butting into DOM and CSS semantics. Or in the Deprecate 
proposal, without butting heavily into "hidden" and ARIA semantics.

Both the deprecate and non-conforming proposals make the argument: 
"people seem to misunderstand how the attribute works". I have a hard 
time with these kind of arguments. I'll try to keep it in perspective: 
people misunderstand how many attributes and APIs work. That's just a 
part of coding and authoring. The proposed ARIA alternatives have more 
complexity than longdesc.

The "Positive Effects" of the deprecate and non-conforming positions, 
when I filter out the "encourage" and "sends a message" arguments, are 
simply repeating the message that ARIA, and rel are two useful 
mechanisms for descriptions. I couldn't agree more.

The "Negative Effects" and "Impact" of marking longdesc as 
non-conforming far outweigh the shared argument that "longdesc cannot be 
relied on... people seem to misunderstand how the attribute works".


-Charles

On 11/19/11 1:54 PM, Shelley Powers wrote:
> Hi Laura
>
> Thanks for posting this update to the email. I really was curious as 
> to what is happening with longdesc.
>
> I am amazed at how much effort has had to be expended to keep 
> longdesc, as compared to how little effort people put in to remove, 
> and the modify <time> and add <data>. The process seems incredibly 
> skewed and not representative.
>
> Ah well. Hopefully this issue is resolved soon.
>
> Best regards,
>
> Shelley
>
> On 11/19/2011 11:03 AM, Laura Carlson wrote:
>> Hi Shelley,
>>
>> According to the Change Proposal Status page [1] the HTML Chairs are
>> evaluating change proposals. My "Include longdesc in HTML5  proposal
>> has been ready for the HTMLWG objection survey since last May when the
>> accessibility task force endorsed it. It will be good to get Issue 30
>> decided. We have been waiting a very long time.
>>
>> Best Regards,
>> Laura
>>
>> [1] http://dev.w3.org/html5/status/issue-status.html#ISSUE-030
>

Received on Saturday, 19 November 2011 23:06:52 UTC