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

On Aug 20, 2014, at 5:30 PM, Edward O'Connor wrote:

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

It is not the right solution to your problem, which consists of
content that is designed with the Web as its sole user interface.
Fortunately, HTML is not limited to that vision of the Web Platform.

As I described in 

  http://lists.w3.org/Archives/Public/public-html/2012Sep/0309.html

the applicability of longdesc as an accessibility mechanism has nothing
to do with modern web pages, home pages, or rather lame imitations of
an operating system.  The longdesc attribute, like summary, is primarily
for use when the publisher DOES NOT have the freedom to redesign the page
to be more accessible by design.  Not the author!  The publisher.

Defining the longdesc attribute does not prevent authors from using other
mechanisms to achieve better accessibility.

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

As has been pointed out before, selective use of statistics based on
popular sites that are ephemeral in nature is not going to give any
insight on how well (or poorly) the longdesc attribute is used in practice.
It is primarily used by sites that are out on the long tail, providing useful
information to the public that was formerly only accessible (at all)
to those with a major public library or government records archive nearby.
When it is used in earnest, I have not encountered any misuse of longdesc.
Ignorance of standards is not one of their problems.  What they need
is the ability to reference long form descriptions within marked-up but
immutable documents using declarative mark-up.

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

No, to think otherwise merely means I understand HTML's purpose as the
document mark-up language for the Web -- that corpus of the world's
information that we have managed to link together using URIs.
That doesn't mean your examples are irrelevant for Web browsers.
It just means that there is a lot more to the Web than browsers, and
I have sufficient experience to know it.

> # 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/>

Absolutely great when you have the option of designing the page from
scratch.  Not applicable to longdesc.

> ## <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/>

It can, yes, if you can depend on a CSS-capable rendering environment
that is equally supported by the devices used by the intended audience
and not subject to legacy problems that result in the description being
displayed all over the content when they don't happen to support it.
At best, this is just a stretch to claim that it might eventually be
possible to make an external description using something other than
longdesc, which doesn't justify removing the attribute that can already
do that right now.

> ## <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/>

It can't if the image already has a link that is not a description of the
image.

> ## 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>

And they will still be applicable when longdesc is defined.

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

Umm, most ebook readers use popups to provide additional content like
shared notes, glossaries, dictionaries, etc.  It doesn't seem to be a
difficult notion in practice.  longdesc is equivalent to a footnote
added by the publisher (as opposed to the author).  In any case, whatever
problems might apply to longdesc UI would necessarily apply to any
replacement for longdesc that attempts to satisfy the same needs.

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

It isn't critical accessibility information.  Wherever you got that idea,
just forget about it.  If it were critical, the content would have been
destructively annotated in place. The longdesc attribute is supposed to
be ignored in most cases.

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

That simply isn't true.  How many AT viewers are capable of rendering
arbitrary CSS and javascript today?  How about printers? Your examples
depend on that assumption.

Our customers that use longdesc are primarily government or society
related and are constrained to publish for older platforms because
the information they are marking up is considered more valuable than
the latest browser features.  The fact that longdesc is not displayed
by visual user agents is exactly why they are using it.  Yet, they are
also constrained to publish valid documents.  They do not want their
documents to be invalid just because you have an opinion.

If the technologies used by their target audience significantly change
in the future to support better accessibility choices, they will adopt
whatever technologies best suit their audience's needs.  They don't need
the WG to tell them how best to author their content for their audience.
They need the choice. The language is supposed to give them a choice.

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

Polyfills don't work on non-scripted platforms.

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

Only by changing the visible content, which is not an option.

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

Yes.

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

And they can be used when they are a better solution.  That does not
justify removing the solution that doesn't require CSS and WAI-ARIA to
be implemented first.

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

I don't believe that forcing publishers to do more work because you
arbitrarily dropped an attribute that they currently use correctly
can be legitimately called an "opportunity cost".  Flagrant abuse of
a privileged position is more like it.  A far better idea would be to
provide free OCR algorithms that are specific to MathML, which they would
happily use in preference to less attractive forms.

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

The longdesc attribute is already part of HTML.  It was already blessed.
That train left over a decade ago.  Nobody is stopping the WG (or the spec)
from encouraging the use of other accessibility mechanisms.  The only reason
this is a problem at all is because HTML5 bizarrely chose to deprecate
attributes by removing them from the spec entirely.

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

There is no cost to working on longdesc.  The attribute already exists
and must at least be ignored to avoid breaking existing sites.
CMSs must implement longdesc to support existing customer demands and
multiple regulatory requirements. No matter what happens with the specs,
we still have to support the attribute in practice.  The only question is
whether the W3C standard is going to reflect that practice or some
imaginary universe concocted by the WHATWG's collective inexperience.

As an implementor of authoring platforms, I find your conclusions to be
wrong. External accessibility mechanisms are used out of necessity by
publishers of existing documents that have been marked-up for the Web,
not by the original authors of documents for the Web.  Your entire
argument is based on misunderstanding how the attribute is used in practice.
That's okay.  What is not okay is this continued disregard for the
considered opinions of folks whose use of HTML does not revolve around
developing a browser engine.  There is more to the Web than that, and it
should be possible for the Web's primary technologies to support the
needs of the entire Web.


Cheers,

Roy T. Fielding                     <http://roy.gbiv.com/>
Senior Principal Scientist, Adobe   <http://www.adobe.com/>

Received on Thursday, 21 August 2014 17:12:11 UTC