WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: LONGDESC in HTML5?

for

From: Jukka K. Korpela
Date: Sep 25, 2010 12:48PM

John Foliot wrote:

> The simple fact of the matter is that while adoption has been slow,
> there are numerous cases of its usage, and documented existence of
> laws, policies and guidelines that suggest your current opinion is
> not correct. (http://www.d.umn.edu/~lcarlson/research/ld.html#glps)

You are citing a document titled "Guidelines, Laws, Policy, and Standards",
though it contains some links to actual usage. Let's pick up one:
http://cirrie.buffalo.edu/encyclopedia/article.php?id=108&;language=en#s7
There we have a figure with a longdesc attribute, followed by a link to the
same plain text document as referred to by the attribute.
So what is the point of the attribute? It only creates unnecessary
duplication for those users who notice it - they will have to guess or
check, by comparing the URLs, whether the resources are identical.

In short, the longdesc attribute just creates confusion. And if the link
were _not_ there, all people who do not notice the attribute, for some
reason or another, such as due to using a browser that ignores it, would not
have access to the text description.

> Removing the existing @longdesc attribute from HTML5 breaks the basic
> premise of HTML5 being backward compatible,

There's a large number of well-established HTML features that are banned in
HTML 5, in the sense that the draft says that authors must not use them. Of
course this is just a verbal game. Browsers will keep supporting what they
have supported (they just have to), and authors will keep using banner
features if they like, especially since HTML 5 says that browser must
support them. Making longdesc banned (using whatever verbal acrobacy that
HTML 5 will exercise to avoid saying "banned" or "deprecated") will have
some effect, admittedly: browser vendors will have less reasons to _add_
support to browsers that now lack it. And that's fine. They have better
things to do.

> and for those who *must*
> use @longdesc due to their workplace requirements, it effectively
> means that they cannot move towards using HTML5.

That's just fine. There is no reason to think that you can move forward
_and_ keep using outdated constructs. If the workplace requirements are
outdated, they need to be fixed, instead of adding outdated ideas to new
drafts.

> Nothing you can say
> or argue removes this fundamental fact.

Even if your statement were correct, it would not be a _fact_ any more than
my correct statement is a fact. Facts are simple statements about observable
phenomena. Principles, even well-founded principles, are not facts.

> @longdesc fills a need, one that is not met by any other native
> semantic means.

Which specific need does it fill, considering the existence of links in HTML
since the early days? Longdesc is effectively a hidden link with very
limited browser support (limited to specialized browsing software, as
opposite to normal graphic browsers). What's the need for hiding a link?

I could imagine some _use_, though not compelling need, for a construct like

<figure>
<img ...>
<longdesc>An <a href="...">explanation of figure 1</a> is
available.</longdesc>
</figure>

... so that a browser not supporting <longdesc> (in some way which we might
expect to be advanced and suitable for the specific way of browsing with it)
would simply ignore the tags and fall back to rendering its content.

> Seeking to keep a rich and useful toolkit to improve accessibility is
> not a waste of anyone's time,

It is, if some of the tools are quite unsuitable for the intended use.
Whatever time spent in writing longdesc attributes is better spent doing
something useful.

--
Yucca, http://www.cs.tut.fi/~jkorpela/