Re: Call for consensus - longdesc to CR

> This is a call for consensus on the following proposition:
>
> The HTML Accessibility Task Force requests that the HTML Working
> Group, with agreement of the PF Working Group, request publication of
> the HTML Image Description Extension (longdesc) version at
> https://dvcs.w3.org/hg/html-proposals/raw-file/ac507017569f/longdesc1/longdesc.html
> as a Candidate Recommendation.

The longdesc attribute is not appropriate for implementation, so I
object to advancing the HTML5 Image Description Extension document to
CR.

The approach we prefer for accessibility at Apple is to make the primary
interface accessible, rather than relying on lower-quality fallback
interfaces. This approach serves users well. It is the foundation for
successful accessibility not only at Apple but in other companies and
standards. It is recognized as a best practice by accessibility experts
both at Apple (consulted in drafting this response), and generally in
the industry.

Just so, we should be designing features for the Web that are inherently
accessible. For instance, the <button> element can be naturally exposed
to users of Assistive Technology without the author needing to do
anything special. This is often referred to as "built-in" accessibility.
Universal access is best achieved when, like <button>, content is
inherently accessible without additional author effort. The best
accessible solutions keep the accessible content embedded in the source
document so things can't get separated.

However, longdesc relegates accessibility to secondary, alternative
content. (This is called "bolt-on" accessibility.) When authors update
the primary content (in this case, replace the image), they often fail
to make corresponding updates to this secondary content. This bit-rot
problem is inherent to any bolt-on solution.

In fact, over the 15 years since HTML 4 went to REC with longdesc
included, what we've seen on the Web is that authors by and large do not
use longdesc and—when they actually try to—they almost always fail to
use it correctly. The result is that longdesc content in the Web corpus
is so poor that Assistive Technology tools would actually *reduce* the
pratical accessibility of pages by exposing longdesc to their users.

Longdesc will always be a sub-standard approach to accessibility given
its bolt-on nature. At Apple we take accessibility very seriously, yet
we firmly believe that longdesc is not the right solution to this
problem.

Fortunately, the Web stack already provides several mechanisms for
providing extended image descriptions today:

* The most obvious one is to simply describe the image in prose adjacent
  to it. Such a description is accessible by anyone.

* If such a description would interfere with the design goals of the
  author, the <img> can be placed inside an <a> element linking to the
  description elsewhere. A link like this is also accessible by anyone.

* It's also possible for the embedded image itself to contain its own
  accessible alternative, for instance by using ARIA in SVG. (There are
  other, non-a11y benefits to this as well. For instance, real text
  context in a vector image format lends itself to localization much
  better than any raster format.)

There are several other techniques which meet the use cases and
requirements found in the Image Description extension which are widely
supported in major browser engines. My colleague James Craig has
documented several such techniques on his website.[1]

Longdesc is worse than alternatives in many ways in addition to the
bit-rot problem described above. Technical problems with longdesc
include:

* The performance of longdesc is worse than alternatives, since a page
  load has to be performed to get an external description.

* In self-contained contexts like ebooks, longdesc is problematic
  because a book may be read offline. Therefore, encouraging use of a
  technique that may place critical accessibility information on the
  network is actively harmful to accessibility.

* The expected UI of longdesc is to load a separate page, which
  interrupts the user's current task and disrupts flow.

* It's not clear how longdesc UI could sensibly work in contexts such as
  ebook readers, where both popups and wholesale replacement of the
  current view would not fit standard UI patterns.

There is a tremendous opportunity cost to longdesc as well. Longdesc is
an attractive nuisance; by making longdesc available to authors, we risk
them using it instead of directly improving the accessibility of their
primary content. For instance, take an author tasked with making
accessible a site with mathematical content represented by bitmapped
images. A colleague of hers recommends that the author use londesc="".
Suppose the best case scenario, where the content pointed to by longdesc
consists of useful, accurate descriptions of the equations on the page.
By spending her time on creating the content pointed to by longdesc
instead of replacing the raster images with MathML, the author has
missed an opportunity to make her mathematical insights reflowable,
resizable, and available to the widest possible audience.

The technology defined by this working group is used by a number of
other standards bodies, for instance by the EPUB folks at the IDPF.
Blessing longdesc in a W3C-branded REC encourages downstream use in
other standards. We should instead be encouraging such groups to
consider the existing alternatives, including (to provide a specific
example) the use of EPUB's existing footnotes feature to provide
extended descriptions of raster images in books.

The many technical shortcomings of longdesc, both those inherent to its
design and those that have been demonstrated in practice since it was
first proposed, have been repeatedly brought to the attention of this
Working Group over many years. Given these shortcomings, and the
widespread support in Web content engines for better alternatives, we do
authors a disservice by encouraging them to rely on longdesc to make
their images accessible.

We've been debating longdesc for years. I've heard from a few people
that they just don't have the time or energy to write up an FO to this
CfC, and I fear that there are many others like them. We're facing the
real risk of consensus by exhaustion. I do not believe that this CfC can
accurately capture the consensus of the community of browser engine
implementors. If the longdesc document proceeds to CR and beyond, I
believe the credibility of this WG will be materially harmed.


Ted

1. http://cookiecrook.com/longdesc/

Received on Friday, 27 June 2014 19:15:47 UTC