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

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…

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.

>> 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*.

[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. 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.

>> 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. 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.

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 12:31:36 UTC