Re: Call for consensus - longdesc to CR

Dear Ted:

Can you please respond whether you intend that your objection below[1] is 
a formal objection as per W3C process:

http://www.w3.org/2005/10/Process-20051014/policies.html#WGArchiveMinorityViews



Also, is this objection your personal objection? Or is it filed on behalf of Apple?

Thank you for the clarifications.

Janina

[1] http://lists.w3.org/Archives/Public/public-html-a11y/2014Jun/0115.html

Edward O'Connor writes:
> > 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 
> Ted
> 
> 1. http://cookiecrook.com/longdesc/

-- 

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 Friday, 18 July 2014 13:52:35 UTC