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

On Thu, 15 Aug 2013 02:22:00 +0400, James Craig <jcraig@apple.com> wrote:

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

Hmm. "Many people" say all kinds of things. I'd rather specs stick to  
saying things that are necessary, in general. That said, I think we are  
converging on enough that it might be worth having something in the spec  
if we can agree on it.

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

Well, I was trying to imagine what you thought we needed and failing, so I  
was requesting you have a bit of a go at both.

On the other hand, I am thinking I am getting some idea, so if you don't  
have time to do this, I'll have a go at it in the next week or so.

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

No.

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

Right.

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

Agreed.

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

So we seem to be on similar wavelengths.

>> 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 long run if longdesc is still used when MathML accessibility is the  
norm, that would be the logical thing to do. In the interim, the content  
of the longdesc might include the MathML, or a link to it, along with  
something else.

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

Which browser? (I am very glad to hear this, by the way. I just haven't  
tested in a while, and last I did the results were that accessibility was  
very "limited").

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

Bringing footnotes into SVG might make sense (although I am not sure they  
are quite the right mechanism - a direct link, with useful metadata, is  
already possible in SVG...). But that doesn't really solve much of the  
short-term problem for HTML that longdesc can solve very quickly.

cheers

Chaals

-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals@yandex-team.ru         Find more at http://yandex.com

Received on Thursday, 15 August 2013 01:31:19 UTC