Re: Drop longdesc, get aria-describedat?

On Wed, Mar 7, 2012 at 1:54 AM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
> There are potential problems related to having both @longdesc and
> @aria-describedat: @longdesc as a HTML5 native feature, would be the
> HTML WG's domain. It is not clear to me, yet, what rules you plan with
> regard to @aria-describedat's permission point to for example sections
> that are hidden via aria-hidden=true. But what is certain is that
> @longdesc would be subject the rules that the HTMLwg decides also in
> this detail.
>
> Whereas the rules for aria-describedat, would be entirely in the hands
> of PF/the ARIA community. When we consider how difficult it seems to be
> to agree about how to @hidden relates to ARIA, it seems to me to it
> *could* be an advantage if we only had @aria-describedat instead of two
> attributes with potentially different rules.

The basic rationale for @longdesc is "no default visual encumbrance",
shifting the responsibility of providing a user interface for
progressive disclosure of initially hidden long descriptions from web
designers to user agent designers.

@longdesc suffers from two poverty of implementation problems:

    1. @longdesc is rarely used by authors, and where used often used
incorrectly (the "@longdesc lottery").

    2. @longdesc is rarely implemented by user agents, and where
implemented often with poor discoverability (e.g. Opera and Patrick H.
Lauke's Longdesc add-on for Firefox rely on users discovering
@longdesc by right-clicking an image of interest to check for a
context menu option).

Encouraging the subset of authors interested in conformance to use a
hidden long description mechanism is counter-productive if at the end
of the day, users cannot easily discover and retrieve those long
descriptions. Consequently, recommending a mechanism in a spec would
be a pyrrhic victory for accessibility if it results in higher usage
by authors but not wide user agent support.

Opponents of adding @longdesc support to user agents argue that it is
hard to provide a user agent interface that gives good discoverability
and without good discoverability @longdesc will continue to be widely
used incorrectly.

The WHATWG praxis producing the Living Standard aims to capture what
the dominant user agents plan to implement to provide access to the
web corpus. If you are trying to implement content that needs to be
accessed by users of those user agents, or you are trying to implement
a user agent, that's critical information. The Living Standard's
discouragement of @longdesc use is consistent with most of the
feedback from user agent representatives who overlap heavily with the
opponents of adding @longdesc support.

Capturing what the dominant user agents plan to implement to provide
access to the web corpus is not an explicit focus of the W3C Process,
but it is an (attenuated) praxis of the HTML WG. We can see this in
the Chairs' demand, with respect to @longdesc, for "use cases that
specifically require longdesc, evidence that correct usage is growing
rapidly and that that growth is expected to continue, or widespread
interoperable implementation":

    http://lists.w3.org/Archives/Public/public-html/2010Aug/att-0112/issue-30-decision.html

How would working on specifying @aria-describedat rather than
@longdesc persuade the opposed user agent representatives or otherwise
deliver wide user agent support?

Authors who want to keep providing hidden long descriptions even in
the absence of wide user agent support could be trivially supported by
producing an extension specification to HTML that makes @longdesc
conforming, along the lines of the HTML+RDFa extension specification:

    http://dev.w3.org/html5/rdfa/

"HTML5 + longdesc" could then be presented as an option in the W3C validator.

But to achieve wide user agent support, engagement with product
owners, developers, and designers is critical. Switching to another
attribute defined by PFWG seems like a distraction that would reset
user agent support from zero without doing anything to involve
essential contributors.

I think the limited accessibility resources available would be better
spent on specifying how to deal with the existing @longdesc web corpus
(for example, in the HTML to accessibility APIs mapping document -
thanks for opening a bug for this) and on coming up with a good design
and patch for the Firefox @longdesc bug:

    https://bugzilla.mozilla.org/show_bug.cgi?id=longdesc

--
Benjamin Hawkes-Lewis

Received on Friday, 9 March 2012 02:04:03 UTC