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

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. 

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. 



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



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



> >
> > 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. Why do you insist that authors who wish to use
@longdesc be ham-strung from creating valid HTML5 documents? 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)



> >
> >> 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? Please elaborate on why. 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?



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



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

+1.

JF

Received on Thursday, 15 August 2013 17:08:31 UTC