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

On Aug 15, 2013, at 10:07 AM, John Foliot <john@foliot.ca> wrote:

> James Craig wrote:
>> 
>> (+ Doug)
>> 
>>>>> 
>>>>>> 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.
> 
> <snip>
> 
>>> 
>>> 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.
> 
> James,
> 
> "Better" is a subjective determination at best. 

I'm not writing a spec here. We're having a conversation.

> There may be times where alternative mechanisms may be more appropriate, but
> I personally bristle at the suggestion of the use of the term "better" in
> the HTML5 Image Description Extension specification (for example, it would
> also be "better" if Safari supported @longdesc, right?). It is a loaded term
> that has no place in the specification. 

Not proposing any specific text. It was just a list to get things rolling.

>>>>> 
>>>>>> 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?
> 
> EPUB is not HTML even if they share many similarities (i.e EPUB is built
> upon HTML5). There is no such thing however as an epub:type="footnote" in
> HTML5,

Item #1 was about its use in EPUB not general HTML. 

> and as far as I know content marked up like this will still render on
> screen, on page, which fails one of the use-case requirements brought
> forward
> (http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc#Use_Cases).
> True you could perhaps hide it visually using CSS, but how would that help
> sighted users who may need the information (I know of a low vision user who
> can see infographics but hates them, and would much prefer to access a
> written equivalent). 
> 
> As well, I am unaware of any screen reader + browser today that can navigate
> to that content with that attribute, or even to note the semantics of that
> content.

Navigating footnotes is accessible in iBooks + VoiceOver. Footnotes are available to mainstream users in many other EPUB readers, though I don't know if any screen readers are supported on those devices. 

> The advice I have seen (in authoring guides) to date is to add the
> EPUB attribute to elements like <aside>:
> 	http://www.heliconbooks.com/article/epub3sem
> 	
> http://www.idpf.org/accessibility/guidelines/content/semantics/epub-type.php
> 
> 
> It remains unclear to me how the semantic of <aside> is actually conveyed to
> sighted users (outside of perhaps CSS styling).
> 
> I will strongly oppose any language or move that seeks to muddy the water by
> injecting confusing authoring techniques for EPUB or SVG content in the
> specification, as it is wholly inappropriate for mainstream HTML authoring.
> The appropriate place for that type of guidance is in authoring guidelines
> for EPUB and SVG (and/or in WCAG), and not the specification itself. 

Many specs do this. Here are two examples:

HTML: http://www.w3.org/TR/html5/grouping-content.html#the-dl-element
"The dl element is inappropriate for marking up dialogue. Examples of how to mark up dialogue are shown below."

ARIA: http://www.w3.org/WAI/PF/aria/complete#form
"Authors are reminded to use native host language semantics to create form controls, whenever possible." (e.g. DON'T USE AN ARIA ROLE) 

>>>>> 
>>>>> In cases where apple users are targeted it is of course necessary
>> to provide a fallback, since VoiceOver doesn't currently 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.
> 
> Citation please. Which browser(s) provides an on-demand delivery of
> epub:type="footnote" content, and then allows the user to return to the same
> place in the document that provided the footnote reference in the first
> place? (See: User Choice -
> http://www.d.umn.edu/~lcarlson/research/constriants/choice.html) 

iBooks (accessible) and other EPUB readers (accessibility unknown).

>>> 
>>> 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. 
> 
> James, this is a tired old argument that has been asked and answered a
> thousand times already.

I think you're expecting me to make an argument that I did not make here. 

> Why do you insist that authors who wish to use
> @longdesc be ham-strung from creating valid HTML5 documents?

Where did I insist that in this thread. My comments here have nothing to do with validation rules… Only authoring guidance.

> Has not one of
> the goals of HTML5 always been to be fully backward compliant? Change the
> document type and off you go?
> 
> ANY move that seeks to keep @longdesc from being fully conformant in HTML5
> is a non-starter.
> 
> 
> 
>> 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.
> 
> Given the poor state of support for the other ways of making SVG accessible
> today, why is the "only longdesc" solution not OK? It may not be optimum,
> but it is a far sight better than nothing, and again, the way this is being
> phrased has the appearance of suggesting that @longdesc is a flawed
> mechanism. 
> 
> Let's be 100% clear here, it is not the attribute that is flawed, it is the
> support from user agents. (I can say the very same thing about the other way
> of making SVG accessible too - it isn't 'flawed', but without user agent
> support it is just words on a document).
> 
> Once again, this is advice that belongs in authoring guides, not the
> specification itself.  I am at a loss why a specification, any
> specification, would say, in the spec itself, not to use the self-same
> specification. Can you point to any other W3C specification that does that?
> (I can't find one)

See the two examples I listed above. Scan other specs for more examples.

>>> 
>>>> 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?
> 
> Are you suggesting that is wrong?

I was merely asking a question. 

> Please elaborate on why.

I wasn't claiming right or wrong, but I do believe that math (parseable MathML) is a "better" default than a picture of math. If you need to retrofit MathML to use an image in a legacy browser, I'd probably do that with progressive enhancement script.

> I can think of a
> couple of (retrofit) reasons why that may, in fact, be a good idea.
> 
> 
> 
>>>>> 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?
> 
> Do we have any documented test results?

Unlikely.

>>>>>> 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.
> 
> Wait, explain to me why attribute "a", which semantically links a graphic to
> content at the bottom (foot) of the page is "better" than attribute "b",
> which semantically links a graphic to content at the bottom of the page. 
> 
> If both attributes function, in theory, in identical ways (or at least
> provide an equivalent functionality), then the only reason to choose one
> over the other is a)authoring whims/choice, and/or b)better user agent
> support.  
> 
> Right now, it seems to me that the support for @longdesc versus
> epub:type="footnote" in mainstream browsers (+ screen readers) leaves the
> footnote solution in last place, but happy to be proven wrong. 

Any examples where I listed "EPUB" were about such use in EPUB documents, not in general HTML.

Received on Thursday, 15 August 2013 22:57:51 UTC