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

personal opinion only:

like Patrick,

"I've been trying to avoid taking sides publicly, as longdesc seems to be
> such a talismanic issue that has been debated for so long. And
> admittedly, the silence was mostly due to my belief that there are far more
> important issues to concentrate on in accessibility."


Like Igalia [1] I share many of the concerns raised by Apple [2] and have
similar doubts about the benefits of longdesc, but will not formally
object to advancing the HTML Image Description document along the REC
track.

Why not? Because I don't want to waste any more time on it, and whether it
is in a spec or not will make no material difference to me on how I advise
clients on the provision of text alternatives for images. It is clear to me
that as an important browser (webkit) and assistive technology (voiceover)
will not implement longdesc , it is not a viable solution for the general
provision of longer text alternatives for images on the web.

If this situation changes I may have cause to rethink.

[1] http://lists.w3.org/Archives/Public/public-html-admin/2014Aug/0037.html
[2] http://lists.w3.org/Archives/Public/public-html-admin/2014Aug/0028.html

--

Regards

SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>


On 21 August 2014 01:30, Edward O'Connor <eoconnor@apple.com> 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.
>
> # 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
>
>