Re: Expanding longdesc use

On Wed, Mar 14, 2012 at 9:09 AM, Léonie Watson <lwatson@nomensa.com> wrote:
>        Isn't the basic problem that longdesc is poorly implemented/supported, and that it's unlikely to gain much more traction in the future? The core functionality is the bit that's important (as you say), so wouldn't a new attribute/element/whatever create an opportunity to improve implementation/support?

Why?

>From an author perspective @longdesc poses the problem that many
popular implementations do not expose @longdesc to end-users, so it's
not a reliable way of providing long text alternatives that are
necessary to understand content.

>From a user agent perspective @longdesc poses two problems:

1. It is hard to design a way to make long description links
discoverable without altering the default rendering of the page.

2. The web corpus contains a lot of @longdesc values that are not
useful to expose to users (the "longdesc lottery").

Minting a new attribute for hidden long description links makes the
problem of support worse (since it will have no implementations, to
start with) and does not help with the user interface design problem.
It also means that existing content that uses @longdesc correctly will
remain poorly supported by future user agents.

The best we could hope is that authors would misuse the new attribute
less than they misused @longdesc. I admit a name change could help
here. For example, we could include "link" or "url" or "href" in the
name of the attribute to make it clear it is a link.
("aria-describedat" is a terrible name; it's got the meaningless
"aria" prefix, it's easy to confuse with "aria-describedby", and it's
not clear that it takes a URL as a value rather than an IDREF.)

But I think to get really good usage, you need to solve the design
problem, so that it's obvious to users that long descriptions are
available and it's obvious to authors that they've made long
descriptions available (or failed to do so). Then we need to give user
agents a consistent message to implement the attribute, accompanied by
design recommendations. Finally, once user agents actually implement
the attribute, we can advise authors who want to hide long
descriptions to use it. Until then, the only advice that will result
in widely accessible long descriptions is to provide them using
visible content in the page (e.g. an <a> element or a <details>
element).

My gut feeling is that supporting existing content using @longdesc
correctly and backwards compatibility with existing user agents is
more important than the reduced error rate of a name change. (If we
want to start renaming badly named elements and attributes in HTML,
there are other striking candidates like "href" and "address".)

The worst case scenario is that we mint a new attribute and we end up
exactly where we are with @longdesc in a decade. We should wait for
implementations in the user interface of mainstream user agents like
Firefox for any new attribute before suggesting it replace @longdesc.

The design problem can be solved as easily with @longdesc as a new
attribute, there's less work to do to get widespread support, and
there's no obstacle to expanding @longdesc to cover <video> etc if we
want to do so.

If our main rationale for preferring a new attribute is to name things
clearly to encourage correct usage, then arguably we should be minting
a more explicit name for <video> anyway, such as "transcriptlink".

--
Benjamin Hawkes-Lewis

Received on Wednesday, 14 March 2012 10:44:28 UTC