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

Apologies for the tardy response. Work issues have taken precedence. I still plan to respond to all points raised in the order received.

On Sep 15, 2012, at 7:53 AM, Charles McCathie Nevile <chaals@yandex-team.ru> wrote:

> As it stands (in particular, only being available on the image element) longdesc is insufficient for the future. That said, I think it solves otherwise unmet needs, and while there is no clear replacement I think it is premature to mark it obsolete or deprecated.

My whole premise was that I don't agree that there is no clear replacement, and have listed several techniques that offer serious improvement over longdesc. The issue that not all of these are support yet is moot, because HTML won't be able to get through CR without them, and a number of them have support today, including one that has better support than 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.
> 
> There are several issues that this approach does not solve.
> 1. It fails to improve on the "separate but equal" aspect of longdesc.

Agreed, but it does improve upon the screen reader support significantly.

> 2. It is actually available to fewer people - in particular, users who have some residual vision, and benefit from at least looking at the image, have no means to access the description.

That's speculation. I say the iframe technique is available to more screen reader users. You say the longdesc technique is available to more low-vision users. 

> Try magnifying your example by 500% and turning on high-contrast.

As far as I can tell, Opera's high-contrast mode doesn't change anything, so I'm not sure what you're expecting me to see. In case I'm experiencing an Opera bug, this is Version 12.02. Build 1578. Platform Mac OS X. System 10.8.2.

> 3. It requires starting from scratch to teach a new technique to authors, educators, users, software developers.

I'd wager that many more people know how to use iframes than how to use longdesc, and I think you'd be hard pressed to find anyone who knew how to use longdesc that did not also know how to use an iframe.

>> 2. *The separate-but-equal approach always falls short of being truly equal, and using this approach for accessibility is no exception.*
> 
> Always? Illustrating with a couple of examples is insufficient to prove the general proposition.
> 
> I agree that in general it is not as good to have a separate solution, but that is a very different statement, and one that doesn't need to be demonstrated for the sake of the case under discussion.

Fair enough. I'll soften that statement to "almost always."

> In particular, one of the requirements for supplementary description is that people are able to *choose* whether to read it, and are not forced to do so.

Screen reader users can already choose whether or not to interact with a frame.

> And finally, I am not clear in what way longdesc is "separate-but-equal". I recently demonstrated [1] that the description can be on the same page and visible to all (per spec and how real implementations work) as well as being out of band to meet a common authoring goal.

Granted that's possible, but uncommonly needed. Also, the frame technique could be done this way with a small addition of functionality implemented in JavaScript.

>> 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.
> 
> Certainly. I also believe that a real, but imperfect solution is almost infinitely better than a perfect solution that is not actually available in practice, at least until such time as the better solution includes the important feature of existing in the real world.

Again, we'll have to agree to disagree. My belief is that existing alternative techniques provide a superset of the functionality provided by longdesc, and with better implementation support across the board.

>> ... No one is clamoring for longdesc support of MathML, because it is defined in an accessible manner,
> 
> This is incorrect. People do request alternatives be provided for MathML. A common approach for mathematical content today is to use images representing it - and a sound HTML4 method to provide accessibility in that case is to link, via a longdesc, to MathML...

I believe what people *want* is accessible MathML, which is an implementation request, not a spec need, since the content is already accessible in it's defined format. Also, as a stop-gap measure until the implementations catch up, MathML can already be retrofit with ARIA.

>> despite the fact that support for MathML accessibility is varied in implementations today.
> 
> Right.
> 
>> 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.
> 
> As you can see from the links I posted in the discussion of SVG above, I have supported such ideas for many years. I still do.
> 
> Unfortunately this approach is not implemented on the Web today. (It makes longdesc look like a very well-supported and effective approach to providing accessibility).

Agreed. My point again was not that this is supported, but that it's a better approach to embed any needed alternatives directly in the content, rather than having two resources (in this case, an image and its alternate) linked by a third (the main HTML document).

The same point applies to SMIL reference movies, which link otherwise unrelated files in an difficult-to-package means. History has shown that the better approach is to embed captions, and alternate audio tracks directly into the movie file itself.

>> 3. *The longdesc attribute will never be removed from HTML 4.*
>> 
>> 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.
> 
> That is incorrect. It has been suggested that Opera drop its support for longdesc, and according to a whatwg IRC discussion a bug was raised for this. (I think that would be a mistake)

I agree that would be a mistake, and that you should close the bug as Behaves Correctly. 

I will change my statement from "no one has suggested that" to "no specification or accessibility-conscious standards body or consumer-focused organization has suggested that."


> Further, this would deny authors the ability to combine longdesc, the enhanced accessibility support of HTML5, and producing valid code. Assuming a real proportion of authors who do use longdesc have a valid use case, this seems an undesirable restriction to impose.

I think a validity warning or error is appropriate here, if for no other reason than it will alert the author that longdesc is not well supported and likely never will be.

>> 4. *Progress is a goal we all share.*
> 
>> 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.
> 
> This argument is circular. And can be reversed (either on the premise that removing longdesc is not worth the effort expended, or on the premise that removing longdesc casuses harm in excess of the value of removing it) to explain why the reputation of people proposing to remove it has been tarnished among those who want the Web to be accessible. That helps clarify the current political situation, but is not a technical argument.
> 
> I have spent more effort trying to save longdesc than it took to effectively implement it (naturally that included providing test cases, checking for, finding, and fixing bugs). But I have spent far less effort than many of the people involved in this discussion.
> 
> It is unedifying to see an argument consume (on both sides) far more resources than the subject of the argument.

Agreed.

>> 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.
> 
> As one of the few managers to actually just implement, my experience is that the cost is far less than that of the argument, the results are valuable in proportion to that cost, it is far simpler than implementing the alternatives proposed, and there is no significant downside.

Every minute of time spent on a mediocre idea is one that could be spent on a great idea. My opinion is that 

>> 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.
> 
> s/worrying so much about hanging on to the mediocre technologies of the past/fighting so hard for wishful thinking and hand-waving proposals/ and you may understand why I find this to be a nice rhetorical flourish, but immaterial to the discussion and unworthy of the concrete technical arguments you started with.

Please don't fault me for ending with an editorial synopsis. I believe any reader familiar with the subject has the ability to transition clearly between the concrete technical to the opinionated editorial. 

> (For completeness in your alternatives, you should list the idea of longdesc pointing to a link on the page and doing the magic to follow that. I suggest that such a technique needs to include a discussion of maintaining content which relies on that pattern, which is where the major difficulties arise).

I will add it. I assume you mean something like this? 
<img src="…" longdesc="#link"><a id="link" href="data.html">Foo</a>

FWIW, I think that's probably a better implementation idea than the current proposal for "DescribedAt":
<img src="…" aria-describedat="#link"><a id="link" href="data.html">Foo</a>

rel="longdesc" or no?

> [1] http://lists.w3.org/Archives/Public/public-html-a11y/2012Aug/att-0192/internalLongdescTest.html
> 
> cheers
> Chaals

Cheers, and thanks for the thoughtful response.
James

Received on Wednesday, 19 September 2012 20:21:15 UTC