Re: Call for Review: HTML5 Image Description Extension (longdesc) Last Call

(+ Doug)

On Aug 13, 2013, at 9:31 PM, Charles McCathie Nevile <chaals@yandex-team.ru> wrote:

> On Wed, 14 Aug 2013 03:46:43 +0400, James Craig <jcraig@apple.com> wrote:
> 
>> On Jul 17, 2013, at 9:30 AM, Charles McCathie Nevile <chaals@yandex-team.ru> wrote:
>> 
>>> Hi James,
>> 
>> Apologies for the delayed response. I've been on leave for a few weeks.
> 
> No worries. A few thoughts...
> 
>>> On Tue, 16 Jul 2013 10:40:18 -0700, James Craig <jcraig@apple.com> wrote:
>>> 
>>>> I have an additional suggestion that I believe would help the acceptance of this document within the general working group. Add an informative section detailing several of the many cases where it is inappropriate to use @longdesc.
> 
> I am not sure about the statement "several of the many cases" - this seems like a rhetorical device intended to make the spec sound worthless in practice. I don't think that improve the acceptability, since although it may appeal to those who are unlikely to accept longdesc in reality (they'll live with a spec rather than argue to the death, but they'll pointedly refuse to implement anything good enough to be useful in practice, as some kind of protest) it is clearly likely to be unacceptable to those do, or who intend to actually *use* the spec to enhance accessibility.
> 
> That said, I am not opposed to listing things where longdesc is really a bad idea, if it is common to try and use longdesc for them. I don't think there is much point listing things it won't do like feed your cat and wash your dishes…

I'm only suggesting it be listed because many people in the accessibility standards community list these examples as justification for longdesc even though a better mechanism already exists.

> So if you think this is really a useful exercise, I'd request some proposal for where such a section would fit into the document.

Fair enough. Are you requesting I write the section or just point out where it should go in the document?

>>> For example…
>>> 
>>> I think some of these are misplacing the cause of the problem they attempt to solve:
>>> 
>>>> 1. @longdesc is inappropriate when an EPUB footnote is sufficient.
>>> 
>>> Can you explain why it is "inappropriate" in terms of the problem that using it causes?
>>> 
>>> In cases where apple users are targeted it is of course necessary to provide a fallback, since VoiceOver doesn't curently enable longdesc to be used, but that is not the same as causing harm by using the attribute.
>> 
>> AFAIK, longdesc doesn't work in any popular EPUB reader, unless you're counting desktop browsers. Footnotes, on the other hand, are well-defined and well-supported.
> 
> Fair enough.
> 
>>>> 2. @longdesc is inappropriate for Math. Use MathML instead.
>>>> 3. @longdesc is inappropriate for SVG graphics. Make the SVG DOM accessible instead.
> 
> You don't appear to have answered the comment on SVG, which is that I agree in principle (and agreed to co-chair the Accessible SVG task force to try and get some motion on what is currently a sorry story in practice), but in practice that actually fails to help most people who need to use your content *today*.

I'm not sure I understand the comment. Is it that longdesc is better because it's been around longer even though it's not well implemented? AFAIK there is nothing stopping an author from using longdesc in HTML4 on an accessible SVG image. This would validate as well as being accessible to systems that supported either longdesc or SVG accessibility.

That said, if an SVG document can be made reasonably accessible, I would object to the spec condoning longdesc as an easy alternative to making the SVG accessible natively. IOW, using both is okay, but using only longdesc instead of native SVG accessibility is not okay.


> [tables moved below...]
>>> In all of these cases, you appear to be blaming the use of longdesc as a repair strategy for an inappropriate design choice to which longdesc is orthogonal.
>> 
>> Not blaming. Just pointing out that these were listed as reasons that longdesc was "needed" when better mechanisms exist.
>> 
>>> Using images for mathematical content, or tabular data, is a known accessibility fail. But in a case where the image is there, using longdesc to mitigate the failure seems far better than simply throwing up your hands and saying "the world shooulda been different"...
>> 
>> Are you recommending images of math over MathML? If so, I don't agree with that at all.
> 
> No, I would not suggest that as a general approach. I think you should use MathML, whether or not you supplement it with images.

That's my point with SVG.

> But people do go with just images, for reasons that are entirely pragmatic - asking people to have infinite budgets to do the right thing is an exercise in noble futility, rather than actually improving accessibility.
> 
>> If you're argument is for the retrofit, I still think MathML is the
>> better solution.
> 
> In practice I think the current situation is that you should use MathML, but it is reasonable to *also* have the fallback solution of images.

Are you suggesting longdesc point to the real MathML content?

>>> In the case of SVG we currently have a disconnect between theory and reality. Although my text on SVG accessibility is (after more than a decade) pretty solid on how to make the DOM accessible, in practice I believe that is only useful for the relatively small proportion of users who have VoiceOver.

Doug Schepers says this works pretty well with NVDA, too. Maybe JAWS?

>>> I realise it is bigger in some markets, but the best figures I can get for Russia suggest that is under 5%. In this situation, while I strongly support the idea that the DOM should be accessible, it seems that a longdesc as a temporary repair strategy for windows users - i.e. the vast bulk of real people - is actually a very helpful thing to do.
> 
>>>> 4. @longdesc is inappropriate for graphics of tabular data. Use an accessible table instead.
> 
> Actually, I sort of agree. For most cases, a table full of data is actually impenetrable to far more people than a good graphical representation or two. However this is a case where it makes sense to also have the table available to everyone, and an example of where it is useful for a longdesc to refer to something that may well be in the page.

This is a good example of where an EPUB footnote or annotation is useful for sighted and non-sighted users alike. The table of data is the source content for the chart. Perhaps incorporating "footnotes" from EPUB back into SVG may provide part of the solution. If nothing else, Wikipedia would benefit.

> In a concrete example, Opera published a mass of graphs on usage. They were far more helpful for the majority of users than providing a table directly, but the table could actually be toggled instead of the graph. Making the association explicit (so you could easily find the table from an image of the graph in a search engine) is the extra value longdesc adds. You may think this is marginal benefit - but as a search engine looking at concrete ways to enhance accessibility we believe it is actually very useful.
> 
> cheers
> 
> 
> 
> -- 
> Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
>      chaals@yandex-team.ru         Find more at http://yandex.com
>

Received on Wednesday, 14 August 2013 22:22:12 UTC