Formal Objection to advancing the HTML Image Description document along the REC track

The longdesc attribute is not appropriate for implementation, so we
object to advancing the HTML5 Image Description Extension document along
the REC track. This feature is technically deficient in numerous ways.
We believe that longdesc is flawed:
* architecturally,
* historically,
* functionally,
* procedurally,
* and strategically;
and longdesc has not, does not, cannot, and therefore will not perform,
but instead harm, its only purported function — providing better
accessibility.

Fortunately, the Open Web Platform already provides accessible
mechanisms for describing images which do not suffer from the many
technical deficiencies of longdesc.

The following sections provide details of these points.

# Longdesc is fundamentally, architecturally flawed

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

# The extant longdesc corpus is polluted beyond recovery

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 and browsers would actually *reduce* the
accessibility of pages by exposing longdesc to their users. Less than
one percent of images on the Web have a longdesc attribute, and of
those, less than one percent of the longdesc values are useable.
<http://blog.whatwg.org/the-longdesc-lottery> When HTML ISSUE-30
(longdesc) <http://www.w3.org/html/wg/tracker/issues/30> was first
decided in the HTML WG (decision at
<http://lists.w3.org/Archives/Public/public-html/2010Aug/att-0112/issue-30-decision.html>),
one of the uncontested observations was that "current usage often
contains bogus values." No evidence has been offered that the situation
has improved since then, or that the documentation of longdesc in HTML 4
was so inadequate as to cause this.

In
<http://lists.w3.org/Archives/Public/public-html-a11y/2014Jul/0047.html>,
the A11Y TF co-facilitators declared that the task force "is already
aware that longdesc can be and is often misused on the Web today." They
then point out that the longdesc spec contains some advice to authors
which may improve longdesc content written in the future by authors
aware of the new specification. It's possible that future authors could
follow such advice (though it seems unlikely, given authors'
demonstrated inability to follow the HTML 4 spec today), but this fails
to address the fact that the existing corpus is heavily polluted with
invalid content. Providing a new specification with new advice can't
drain the swamp of its existing mud. To think otherwise is a triumph of
hope over experience.

# Existing alternatives

Fortunately, the Open Web Platform already provides several mechanisms
for providing extended image descriptions today. Here are three examples
of techniques authors can use.

## Self-describing images (e.g. SVG)

Images in some formats can contain their own accessible description in
the image itself. For example, SVG can contain its own description,
which can be enhanced with WAI-ARIA attributes. There are non-a11y
benefits to this as well—for instance, self-describing images can be
saved offline and not lose the association with their descriptions.
Also, real text context in a vector image lends itself to localization
much better than any raster format. SVG accessibility is well supported
today, while it was not a decade ago.

<http://cookiecrook.com/longdesc/svg/>
<http://www.sitepoint.com/tips-accessible-svg/>

## <figure> with <details>

If the image cannot carry its own description, by far the best option is
to simply describe the image in prose adjacent to it. Such a description
is accessible by anyone. If presenting such a description would
interfere with the design goals of the author, the image and its
description may be marked up with <figure> and <details>, as my
colleague James Craig demonstrates on his website at
<http://cookiecrook.com/longdesc/details/>. Such markup does not force a
visual encumbrance; <figure> and <details> may be used in conjunction
with CSS and WAI-ARIA to make the description available while not
affecting the visual presentation of the page.

<http://cookiecrook.com/longdesc/details/>

## <img> with <a>

Alternately, the <img> can be placed inside an <a> element linking to
the description elsewhere, or an <a> element can be placed next to the
<img> in the document. Links like these are also accessible by anyone.

<http://cookiecrook.com/longdesc/figure_link/>

## Other better techniques

This is by no means an exhaustive list of alternative techniques; my
colleague James Craig has documented several other techniques on his
website: <http://cookiecrook.com/longdesc/> All of the above techniques
can be combined with other features of the existing platform, such as
WAI-ARIA, CSS, and JavaScript, to achieve many design goals and
interaction patterns. Many of these techniques are already included in
the HTML specification: see
<http://www.w3.org/html/wg/drafts/html/master/embedded-content.html#graphical-representations:-charts,-diagrams,-graphs,-maps,-illustrations>

# Functional flaws: the operation of longdesc

## User Interface problems of longdesc

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.

## Network considerations

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.

# Procedural flaws: the Use Cases and Requirements

When ISSUE-30 (longdesc) was first decided in the HTML WG (decision at
<http://lists.w3.org/Archives/Public/public-html/2010Aug/att-0112/issue-30-decision.html>),
the decision stated that ISSUE-30 could be reopened if people provided
evidence of:

* use cases that specifically require longdesc,
* evidence that correct usage is growing rapidly and that that growth is
  expected to continue, or
* [or] widespread interoperable implementation.

The issue was reopened on the basis of use cases which, it's claimed,
specifically require longdesc. But as this section illustrates, the
existing web stack already meets the use cases and requirements found in
the Image Description extension. No identified use case or requirement
specifically requires the longdesc attribute, or documents a case where
longdesc is the only or best solution.

## Requirements

### Backwards Compatibility
> It should be possible to use existing tools and techniques to
> associate an image with its description.

The Open Web Platform meets this requirement without the addition of
longdesc. The above techniques all rely on features already present in
the web stack. That said, even in cases where not all existing browsers
support a feature, like for example <details>, the features used are
polyfillable for older browsers, and are designed to degrade gracefully
in such browsers.

### Discoverability
> It must be simple for a user agent to automatically discover a
> description provided for a given image.
> A user should be able to determine that there is a description
> available for a given image.

The Open Web Platform meets these requirements without the addition of
longdesc. Self-describing images handle this themselves, and for
out-of-image descriptions, native host language semantics can provide
the programmatic association that is implied by the words "simple" and
"automatically" in the text of this requirement. Where the host language
lacks such semantics, WAI-ARIA attributes can be used to provide the
association.

### Inline
> It must be possible to associate a description in the body of a page
> with an image in that page.

The Open Web Platform meets this requirement without the addition of
longdesc, as illustrated with the above techniques.

### Maintenance
> It must be simple to maintain a library of images and descriptions for
> dynamic assembly, or dis-assembly and re-assembly, of content.

The plethora of tools and publishing workflows which people use today to
assemble web content clearly meet this requirement regardless of the
technique chosen, including longdesc.

### No Visual Encumbrance
> It must be possible to provide a description for an image without
> forcing the description to be rendered on the page.

The Open Web Platform meets this requirement without the addition of
longdesc. The above techniques may be used in conjunction with other
platform features such as CSS and WAI-ARIA to prevent the description
from appearing by default. Longdesc does not meet this requirement, as
in the case of offline EPUB with online out-of-flow longdesc content.
The Platform solutions discussed are a better solution whether in EPUB
or standard HTML pages.

### Optional Consumption
> A user must be able to choose not to read the long description of a
> given image.

The Open Web Platform meets this requirement without the addition of
longdesc, as illustrated by all three of the techniques described
above.

### Reuse
> It must be possible to re-use a single description for multiple
> occurrences of an image.

The Open Web Platform meets this requirement without the addition of
longdesc. A self-describing image carries its description with it
into each occurrence. Mulitple <a> elements or aria-describedby
attributes can be used to re-use a single out-of-image description with
multiple occurrences of its image.

### Simple Return
> A user must be able to return from the description to the image.

The Open Web Platform meets this requirement without the addition of
longdesc, as illustrated by all three of the techniques described
above.

Longdesc does not meet this requirement, as in the case of offline EPUB
with online out-of-flow longdesc content. The Open Web Platform
solutions discussed are a better solution whether in EPUB or standard
HTML pages.

### Structured Markup
> It must be possible to include rich markup (e.g. HTML5) in the
> description of the image.

The Open Web Platform meets this requirement without the addition of
longdesc, as illustrated by all three of the techniques described
above.

## Use Cases

The existing web stack handles all of the use cases identified in the
HTML Image Description extension document. Simple illustrative examples
follow. In all cases, other Open Web Platform features such as WAI-ARIA,
CSS, and JavaScript may be used to achieve various design goals.

### Identifying a well-known image

<figure>
<img src="wctd.jpg" alt="Washington Crossing the Delaware">
<figcaption>Washington crossing a river, standing heroically in a boat,
while soldiers do all the paddling</figcaption>
</figure>

### Describing a complex chart, diagram, or graphic

The example of a SVG map of Africa including the country borders shows
fully described graphic content in context. This example includes
individually accessible UI elements and can be explored by touch using
VoiceOver on iOS and Macs. See
<https://www.webkit.org/blog/3302/aria_and_accessibility_inspector/>.

The vector SVG content included as inline HTML, and is made accessible
using the role attribute. Each country's name can be included as the
<title> element of a path, or by using ARIA as shown below:

<!-- Each country's vector path equates to touchable, accessible image.
-->
<path role="img" aria-label="Algeria" d="M190.6276,112.125 L191.2396,
..." />
<path role="img" aria-label="Angola" d="M372.1636,574.6182 C372.0328,
..." />
<path role="img" aria-label="Benin" d="M272.3596,284.2338 C272.7702,
..." />

The <foreignObject> element can be used to embed HTML as appropriate.

### Teaching accessible development

This use case has no technical requirements that favor one technique
over another, but naturally all of the above techniques are teachable.

### A self-describing artistic work

The existing web stack without longdesc provides a rich set of features
that can be used to create self-describing artistic works.

### Referring to an existing description

<a href="http://en.wikipedia.org/wiki/Washington_Crossing_the_Delaware"
id="wctd"><img src="wctd.jpg" alt="Washington Crossing the Delaware"
aria-describedby="wctd"></a>

### Linking to a description included within the page

This can be done in HTML today with

<a href="#wctd-desc"><img src="wctd.jpg" alt="Washington Crossing the
Delaware"></a>

or with HTML and WAI-ARIA like so

<img src="wctd.jpg" alt="Washington Crossing the Delaware"
aria-describedby="wctd-desc">
…
<p id=wctd-desc>Washington crossing a river, standing heroically in a
boat, while soldiers do all the paddling</p>

### Localizing descriptions

<a href="http://conneg.example.com/Washington_Crossing_the_Delaware"
id="wctd"><img src="wctd.jpg" alt="Washington Crossing the Delaware"
aria-describedby="wctd"></a>

As an aside, we don't think content negotiation is a good way to publish
multilingual content. That said, this example illustrates that the
existing web stack, without longdesc, addresses this use case at least
as well as longdesc does.

### Image search
### Describing images

Both of these use cases are addressed by previous examples.

# Strategic flaws: The opportunity costs of longdesc

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 longdesc.
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 authoring opportunity cost is not the only opportunity cost of
longdesc. Consider that the technology defined at the W3C 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, which is a strategic blunder. 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.

Finally, there is the opportunity cost of working on this old, flawed,
technique at the W3C, when time spent on better alternatives would be
time better spent.

# Actions which whould partially or fully address our concerns

The Process document states that Formal Objections should propose
changes that would remove the Formal Objection. In this section we
outline possible steps that would partially or fully address the
concerns that have contributed to our decision to file a Formal
Objection.

## Change the abstract of the document to reflect the historic nature of the attribute

We suggest changing the first sentence of the abstract from

"This specification defines a longdesc attribute (based on the longdesc
attribute of HTML 4) to link descriptions to images in HTML5 content.“

to

"This specification defines how the historic longdesc attribute,
originally defined in HTML 4, may be used to to link descriptions to
images in HTML5 content. However, it is rarely, if ever, best practice
to use the longdesc attribute to describe images.”

(We don’t think an abstract is the place to describe the alternatives.)

## Make the focus of the document clear from the title

Since the document only discusses longdesc, not all image descriptions
or even all image description extensions, change the title from

"HTML5 Image Description Extension (longdesc)”

to

"The ‘longdesc' Image Description attribute in HTML5 content”

## Take it off the Recommendation track

Since this technique is not, in fact, recommended we suggest it be taken
off the Recommendation track and published as a Note.

This outcome is preferred to the one below, from our perspective.

## Remain on the Recommendation track with an author-level SHOULD NOT

Despite longdesc's fundamental unsuitability as part of the platform,
there is a small amount of content that makes correct use of it, and
there may be specific, non-Web contexts (such as carefully curated
intranets or the like) in which longdesc is used.

If the document does remain on the Recommendation track, the
recommendation should be clear: use better, more structured,
alternatives that do not suffer from the problems we outline above. The
document should state clearly:

“In the vast majority, if not all cases, there are alternatives to
this attribute that provide better accessibility and better overall
behavior. The longdesc attribute SHOULD NOT be used; it is documented
here for historical compatibility, not as a recommendation for new
adoption."

# Conclusion

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 argue about this
anymore, and I fear that there are many others like them. We're facing
the real risk of consensus by exhaustion. I believe that there is no
consensus within the community of browser engine implementors in support
of longdesc. If the longdesc document continues to proceed along the REC
track, I believe the credibility of this WG and the W3C will be
materially harmed.

Given all these problems, why then does longdesc continue to have
support? Others have speculated about our motives in opposing its
further development and promotion, but we don’t think a discussion of
assumed or imputed motives is helpful, nor is it in place in a formal
objection; we are passionate about providing quality accessibility, and
continuing to promote longdesc actively harms that goal. Many people
feel that there are some entrenched positions involved, and indeed, to
avoid being in one ourselves we stepped back from this specification
development for a while to see if the problems we and others had
previously identified could and would be addressed, whereupon we would
have changed our mind. Unfortunately, we don’t believe the problems have
been addressed.

We would therefore like the decision to be made not on the basis of
motives, nor the backgrounds of participants, nor the origins of the
proposals, but on technical merits that will give the best platform for
online accessibility. Longdesc does not and will not do that.



Ted, with colleagues

Received on Thursday, 21 August 2014 00:30:30 UTC