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
