Re: Call for consensus - longdesc to CR

Dear Ted,

Thank you for taking the time to express your concerns on your 27 June
2014 mail in the thread below, and also at 
http://lists.w3.org/Archives/Public/public-html-a11y/2014Jun/0115.html 

with regard to moving the HTML5 Image Description Extension forward as
a Candidate Recommendation, the issues that you raised have previously
been considered by the HTML Accessibility Task Force as described in our
response below.


At 03:15 PM 6/27/2014, Edward O'Connor wrote:
> > 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.



accessible is better than relying on a fallback mechanism. As a
follow-up to a previous comment, the Task Force had consequently
previously added the following paragraph into the specification:

[[ Authors SHOULD NOT rely solely on longdesc 
where standards exist to provide direct, 
structured access. Note: (informative) For 
example a MathML version of mathematical content, 
or an SVG image that uses the accessibility 
features of SVG, can provide better accessibility 
to users with appropriate technology. In such 
cases, it is appropriate to use longdesc as a 
fallback strategy, in combination with more modern techniques. ]]

This disposition was accepted by the Task Force, and by the original
commenter, James Craig, last year.

  http://lists.w3.org/Archives/Public/public-html-a11y/2013Dec/0045.html
  http://lists.w3.org/Archives/Public/public-html-a11y/2013Dec/0067.html


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


The HTML-A11Y Task Force is already aware that longdesc can be and is
often misused on the Web today. Previous analysis has already identified
auto-generated longdescs as a substantial source of this misuse. The
longdesc extension specification, Section 3.0:  Implementations
https://dvcs.w3.org/hg/html-proposals/raw-file/tip/longdesc1/longdesc.html#implementation
has been updated to provide implementation guidance to authors and
developers of conformance checkers regarding how to properly deploy long
descriptions of images on the Web.

Even given awareness of misuse of longdesc in some settings, the Task
Force consensed moving forward with longdesc development as it has found
longdesc valuable for certain use-cases, even though we cannot guarantee
proper use of longdesc any more than we can guarantee the proper use of
any Web technology. This was addressed as part of the decision on :

     22 Oct 2013: 
http://lists.w3.org/Archives/Public/public-html-a11y/2013Oct/0059.html
     05 Dec 2013: 
http://lists.w3.org/Archives/Public/public-html-a11y/2013Dec/0016.html


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


The HTML image description specification was designed to address the use
cases and requirements listed in Section 2:
https://dvcs.w3.org/hg/html-proposals/raw-file/tip/longdesc1/longdesc.html#UCnR
The "reuse" requirement added over the past year of development, among
others, requires that E-books on the Web should be able to access
separate resources, just as other Web resources do. The Task Force has
recognized that not all publishers and e-book-reading software support
such use, and has therefore written this specification so as to not
prevent other packaging approaches.


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


This part of your comment parallels the concerns expressed in your first
point above. Our response to that point applies here as well in that the
Task Force agrees that making the primary interface accessible is better
than relying on a fallback mechanism. However, the Task Force continued
to find use cases insufficiently covered, or not yet covered, by
alternative implementations, and this has been sufficient to convince
developers to attract significant implementations during the time that
this extension specification has been in development:
https://rawgit.com/chaals/longdesc-tests/master/test-results.html


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


A wide variety of alternative approaches has been considered by the Task
Force over the years that this specification has been in development.
These have been considered against a wide range of real-world use cases
among people with disabilities, and has resulted in the distilled list
of use cases and requirements now enumerated in the specification.

As noted in our response to your first point, the Task Force consensed
its support for development and adoption of direct access strategies for
graphical content. However, it has consistently evaluated these as too
few and too new to replace the current need for longdesc.

Separately we note that your suggestion of using footnotes fails the
"discoverability" requirement documented in Sec. 2: . 
https://dvcs.w3.org/hg/html-proposals/raw-file/tip/longdesc1/longdesc.html#UCnR


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


Thank you again for your comments regarding longdesc. We agree that
longdesc has been debated for many years in W3C. However, we also
observe that, fully cognizant of the concerns that you have
recapitulated here, the Task Force repeatedly consensed moving forward
with development of this extension specification. In the process the
Task Force adjusted the specification in multiple ways to further
address the concerns already cited and discussed; and it reached
consensus on those improvements as the extension spec was further
developed. Moreover, during this process the Task Force has also now
gathered implementations demonstrating the feasibility of these
improvements in multiple tools:
https://rawgit.com/chaals/longdesc-tests/master/test-results.html

Therefore we respectfully decline to terminate progress on this
extension specification.


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


Regards,

Janina Sajka, for the HTML A11y Task Force Facilitators  
-------------------------------------------------------------------------------

Janina Sajka,	Phone:	+1.443.300.2200
			sip:janina@asterisk.rednote.net
		Email:	janina@rednote.net

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup:	http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair,	Protocols & Formats	http://www.w3.org/wai/pf
	Indie UI			http://www.w3.org/WAI/IndieUI/

Received on Saturday, 26 July 2014 00:39:45 UTC