My case for the obsoletion of longdesc (Was: 48-Hour Consensus Call: InstateLongdesc CP Update)

I realize this is a heated topic, one with many facets and valid perspectives, and so I ask that you consider my arguments with an open mind, regardless of your previous conceptions in this debate.

I also feel I should introduce myself, as I'm new to the HTML Working Group and the HTML Accessibility Task Force, though I am not new to web standards or accessibility. Despite my opposition to longdesc, I assure you that I vehemently evangelize the importance of accessibility, and I believe my record speaks for itself. I've been involved with the W3C for nearly a decade; I have been a contributor to CSS 2.1 and WCAG 2.0, an editor of ARIA 1.0, and most recently an editor in the newly formed IndieUI Working Group. I have worked professionally on accessibility part-time for more than a decade, and I now work full-time in the Accessibility Engineering team at Apple. I have volunteered with organizations like Knowbility and the Web Standards Project. I have spoken on the importance of accessibility and universal design at conferences like SXSW, Access U, and WWDC. I firmly believe that no product is complete until it's been made as accessible as possible to everyone, regardless of their level of ability.

On Sep 13, 2012, at 10:10 AM, Janina Sajka wrote:

> The HTML-A11Y Task Force has twice resolved support for the InstateLongdesc Change Proposal on Issue-30 Longdesc reconsideration, most recently as logged at:
> 
> http://lists.w3.org/Archives/Public/public-html-a11y/2011May/0399.html
> http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc
> 
> As we expect reconsideration of the Issue-30 decision on longdesc will be taken up by the HTML-WG soon, the Task Force Text Subteam has provided a narrative wrapper for this CP which is intended to serve as concise orientation at the top level of the CP, leaving detailed evidence and argument to subpages.
> 
> http://www.w3.org/html/wg/wiki/Talk:ChangeProposals/InstateLongdesc

Despite the importance I place on accessibility, I am hereby voicing my opposition to inclusion of the longdesc attribute in HTML 5. I believe longdesc should only be reinstated in HTML 5 with the caveat that it be denoted as obsolete or deprecated. I will attempt to refrain from using a few subjective, difficult-to-prove arguments like the claim that longdesc is not commonly used, or that it was a bad design decision from conception. Instead I will mention the reasons I believe have not been accurately, completely, or convincingly addressed on the HTML Accessibility Task Force wiki page. Those reasons are as follows:

1. *There are existing, valid alternatives to longdesc in HTML 5, some of which work in implementations today.*

Here are several: http://cookiecrook.com/longdesc/

To the best of my knowledge, one of these approaches (the iframe example listed at http://cookiecrook.com/longdesc/iframe/) works in all major implementations today, which is to say that it is much better supported than longdesc itself. 

2. *The separate-but-equal approach always falls short of being truly equal, and using this approach for accessibility is no exception.*

As a physical example, compare a wheelchair ramp or curb-cut, used by everyone, to the expensive, clunky, separate-but-not-really-equal alternative, a wheelchair stair lift. For those of you unfamiliar with these terms, I've included some links to images below.

	http://www.google.com/search?q=curb+cut&tbm=isch
	http://www.uklift.co.uk/stairlift/wp-content/uploads/2009/08/wheelchair_stairlift_tsl1000.jpg

As a digital example, I'll refer to this opinion piece about the Amazon Access web site. Please note that this reference is not intended to be political commentary about Amazon. It's just a prominent example and the article does a good job of explaining the cons to this approach.

	http://www.wired.com/techbiz/media/news/2001/12/49195
	http://www.amazon.com/access

I am in favor of the general idea of providing structured accessible content, but I believe the best way to do that is to make the content itself accessible rather than linking to a separate alternative. As demonstrated in the examples above (e.g. embedded SVG), image content in many formats can be made directly accessible, which is a much better approach than either longdesc or the hidden iframe example. No one is clamoring to retain the mediocre accessibility of the <embed> element, because the accessibility of the <video> and <audio> elements provides a much better solution, especially when displaying media types that allow embedded accessible content like CC or SDH for the deaf and hard of hearing, and Described Audio tracks for persons with vision impairments. No one is clamoring for longdesc support of MathML, because it is defined in an accessible manner, despite the fact that support for MathML accessibility is varied in implementations today.

I would even support a recommendation to include a structured long description alternative in the embedded metadata of raster image filetypes, such as PNG. Some of you may recall that Fireworks used to store its layer and path editing information in PNG metadata in much the same way.

3. *The longdesc attribute will never be removed from HTML 4.*

Previous versions of HTML are set in stone (virtually of course). Once a document reaches Recommendation status at the W3C, it does not change. Ever. Web authors or publishers can still use a valid HTML 4 doctype for their creations, and those documents will always be conforming. Likewise, rendering engines and assistive technologies are allowed and encouraged to provide the best support possible, even in the case of non-conforming documents. The comparatively few implementations with existing support of longdesc are not required to drop support for it, and no one has suggested that they should.

4. *Progress is a goal we all share.*

Software and hardware life-cycles are ever-changing. Web software is no exception, and neither is the native software that supports it, like browsers and screen readers. We live in an amazing world, and technology is progressing more quickly than at any time in the past. We no longer use punch cards to program computers. We no longer use serial ports and floppy drives. We no longer use the bgcolor attribute, or the <blink> and <basefont> elements to define style. We no longer use the <applet> or <noframes> elements to define functionality. A major part of software progression is that new development is focused on better ideas that arise, and continued support of older technologies is allowed to drop from newer implementations, while it's free to remain in existing implementations of the older standards.

My belief is that this drawn-out, years-long debate over longdesc tarnished the reputation of web accessibility opinion within the web standards and technology communities, because longdesc itself was not worth the effort that many of you expended to save it. I previously tried to avoid the discussion because there are so many more important accessibility discussions on which I'd rather spend my time. There is a wealth of knowledge represented in the W3C working groups; imagine what amazing new things we could have accomplished in the time we've spent on this topic. 

As one of my managers likes to say, "I can fight for this if you need me to, but I only have so many silver bullets." Let's not waste any more of our collective silver bullets on longdesc, when there are much more important accessibility decisions to be made, and so many more amazing new technologies waiting to be made accessible.

Let's move the Web forward as we are chartered to do. Let's work together to make the Web as accessible as it can be, instead of worrying so much about hanging on to the mediocre technologies of the past that we jeopardize forward progress towards better accessibility for everyone. 

Thank you for reading,
James Craig

PS. It is with some reluctance that I join this debate. I originally avoided discussing longdesc publicly, as I considered it an online "holy war" better left to those who felt more strongly than I, but I've come to the conclusion that I can no longer abstain. Like many of you, I have a busy schedule, but I will, to the best of my ability, read all points raised in this thread, and respond to all I can. I also realize not everyone can post to the HTML list, so if you feel I should be made aware of viewpoints expressed elsewhere, please click the reply-to link from the W3C email list archive page (this will retain the proper thread headers so I don't filter your message) and if needed, add me as a recipient directly. At the very least, ping me with a link on Twitter at @cookiecrook. Thanks.