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

FYI.

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329


-----Original Message-----
From: Edward O'Connor [mailto:eoconnor@apple.com] 
Sent: Wednesday, August 20, 2014 8:30 PM
To: public-html-admin@w3.org
Subject: 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:37:14 UTC