Rebuttals to Use Case Comments

Table of Contents

Use Case Overview

Longdesc is an established and implemented solution to real problems in valid use cases. All of the documented use cases are substantiated by real world examples as cited in the use case notes. The use case real world examples in the wild include longdescs from the following sites:

Content owners should not have to re-author accessible content, already being delivered to legacy devices, for it to be valid and accessible HTML5.

Describing a Logo

Logos provide evidence of long descriptions for images already inside of a link. Evidence of this pattern is supported by real world examples in the wild. No evidence has been presented that this functionality is not needed. It is impossible for other solutions such as rel="longdesc" to provide this functionality.

Impossible for One Link to Have Two Destinations

As explained, one link cannot take a user to two locations. Attempting to force dual functionality into single functionality is unworkable.

Removing the possibility for direct, dual, programmatic access to both a long description via longdesc and a separate a href on an <img> element would be (a) needless authoring impediment, (b) a step backwards for HTML, and (c) a barrier to providing accessible content. Including longdesc in HTML5 affords authors a way to provide both an a href as well as an accessible programmatically determinable long description.

Freedom of Choice

The following statement from the Zero Edit Obsolete longdesc Change Proposal is inaccurate:

Using the logo description as a “replacement for the original rendered content” would mean users with this function enabled would hear the long description of the image as the link text, which would be useless.

On the contrary, longdesc allows screen reader users freedom of choice. The description is not forced upon them whether they want it or not. Screen reader users can choose to interact with it at their own will. The content of the long text description is voiced only when the user requests it. In other words with Longdesc the user is informed that longer textual description is available, and they need can easily request that content be presented to them--or not. In no instance, however, is the content automatically forced on them.

Longdesc provides users freedom of choice. Authors are already providing this functionality, as evidenced by real world examples.

Equal Access to Dual Functionality

longdesc affords equal access to dual functionality.

Separate Logo Link Is Not Programmatically Determinable

As explained programmatic determinability aids accessibility A separate logo description link as part of the navigation is not programmatically determinable. There is no relationship that indicates that the link has anything to do with the logo. With such a technique, a screen reader user may never know that a long description exists for a given image.

In contrast, a longdesc is tied to the image that it describes and provides explicit semantics, which in turn enables a higher degree of accessibility.

Description Available in a Separate Document Provides Efficiency

Using one global document to provide descriptions for multiple instance of the same image is powerful. It provides efficiency and scalability making authoring and maintenance easy wherever instances of the same image are used in multiple locations. For a full explanation of this please consult description available in a separate document provides efficiency. HTML5 should not unduly obstruct authors in this regard.

Real World Sites Implement longdesc on Logos

The logo use case is evidenced by real world examples in the wild. For example, as documented in the use case notes, the following sites provide logo functionality:

Content owners should not have to re-author accessible content, already being delivered to legacy devices, for it to be valid and accessible HTML5.

Alternative Techniques

As explained the suggested alternatives are not viable. Most are not programmatically determinable. They fail logo use case constraints and do not meet requirements.

For detailed rationale of why aria-describedby and hidden are not viable, please consult the aria-describedby and hidden documents as well as:

Existence of other approaches do not justify killing off longdesc. It is an unwarranted conclusion.

Users Who Desire Access Can Have It

As explained any user who wants to access a longdesc can do so by using tools that support longdesc.

Describing a Cartoon

Shelley Powers has explained the need for longdesc on cartoon images,

There is no better justification for a verbose descriptor/longdesc, though, than political cartoons, as I demonstrate over at Puppies @ Burningbird.

The argument that the material describing the image can be repeated in the page just doesn't fly. To repeat the image data textually, just before or after the image, not only detracts from the image, it lessens the impact the political cartoon intends.

At the same time, political cartoons are highly sophisticated bits of imagery, which can't be described in a small blurb in an alt attribute. They also provide essential information, because political cartoons are created specifically to convey important arguments about ongoing political and other activities.

The Zero Edit Change Proposal: Keep Longdesc Non-Conforming does not dispute this need.

Cartoonist Kyle Weems (aka CSS Squirrel) provides artistic requirements and design functionality testimony [web.archive]:

I have no qualms with other people using hyperlinks where they desire to provide alternate text. However, as a designer, I object to being told I must use those links myself. As you've pointed out on Twitter, the current design of the comic page would certainly support a hyperlink wrapping around the comic. However, my upcoming design already has functionality mapped to clicking the comic, and won't have space for a large "transcript here" hyperlink sitting around in plain sight (which would be distracting for the 99% of my users that are sighted). In that scenario, longdesc can and does serve my needs.

Functionality mapped to clicking a comic can be evidenced in sites such as dizABLED which utilizes an a href around the cartoon image to go to the next image in a series of comic images while simultaneously utilizing the longdesc attribute to provide the long description.

Rejecting artistic requirements and design functionality requirements is not a winning strategy for HTML5 or for accessibility. Reinstating Longdesc is.

Description Available in a Separate Document Provides Efficiency

Using one global document to provide descriptions for multiple instance of the same image is powerful. It provides efficiency and scalability making authoring and maintenance easy wherever instances of the same image are used in multiple locations. For a full explanation of this please consult description available in a separate document provides efficiency. HTML5 should not unduly obstruct authors in this regard.

For instance the CSS Squirrel uses images in separate documents that share the same long description page.

Alternative Techniques

As explained the suggested alternatives are not viable. Most are not programmatically determinable. They fail cartoon use case constraints and do not meet requirements.

For detailed rationale of why aria-describedby and hidden are not viable, please consult the aria-describedby and hidden documents as well as:

In addition:

Existence of other approaches do not justify killing off longdesc. It is an unwarranted conclusion.

Real World Sites Implement longdesc on Cartoons

The cartoon use case is substantiated by real world examples. Content owners should not have to re-author accessible content, already being delivered to legacy devices, for it to be valid and accessible HTML5

Expecting authors to rewrite their content to support pervasive and intrusive coding changes ignores aesthetics and infuriates authors.

Users Who Desire Access Can Have It

As explained any user who wants to access a longdesc can do so by using tools that support longdesc.

Describing Artwork

Artwork Use Case Constraints

Linking the thumbnails to pages with both the larger image and the long description as in-page content is not a solution:

  1. When the image link is mapped to go to a page other than a description page. For example, Dayton Art Institute's accessart site uses the longdesc attribute to take the user to a long description page and an a href to go to a different "dialogue with the director" page. The longdesc attribute is used to describe all images in all of the tours.
  2. When the aesthetic constraints prevail. Ignoring aesthetic considerations is ignoring reality.

As previously explained it is impossible for one link to have two destinations.

Alternative Techniques

As explained the suggested alternatives are not viable. They fail artwork use case constraints and do not meet requirements. In particular:

Existence of other approaches do not justify killing off longdesc. It is an unwarranted conclusion.

Users Who Desire Access Can Have It

As explained any user who wants to access a longdesc can do so by using tools that support longdesc.

Real World Sites Implement longdesc on Artwork

The artwork use case is substantiated by real world examples in the wild. Content owners should not have to re-author accessible content, already being delivered to legacy devices for it to be valid and accessible HTML5.

Describing Screenshots

Real World Sites Implement longdesc on Screenshots

Real world sites implement longdesc for screenshots.

As noted the Oracle and IBM the examples in the wild provide visible text links in addition to longdesc. IBM Corporation provides redundant non-programmatic determinable link text "below the fold" in the endnotes. All of these links are not programmatically determinable. Longdesc is.

Redundant link text attempts to mitigate damages of user agents that do not yet have a long description feature built directly into them. Because longdesc it is not yet supported by some web browsers, some sites provide a fallback method of providing a full description via redundant link text. With proper implementation in user agents these links could all be solely longdesc. The new spec text for the rendering section will help more user agents implement longdesc properly.

Content owners should not have to re-author accessible content, already being delivered to legacy devices for it to be valid and accessible HTML5.

longdesc on Screenshots is Perceivable

The Zero Edit/Obsolete longdesc Change Proposal accused longdesc of being a secret. The question is, "a secret from whom?".

As Joseph C. Dolson has explained,

For most users, perceivable content is visual. Your visitors view video clips, see images of your products, and read your descriptive texts. Perceivable content applies to the visual aspect of your website. But other aspects include providing a version of your content that is available for users who require other modes of sensing it.

That sounds complex, but all it really requires is that information be provided in a machine-readable text format. Computers can easily and efficiently take text and convert it into Braille or audio, but they can't work with graphics, video, or audio in nearly as effectively.

These later formats must be made available in a "text equivalent," which provides the meaning of the content it represents.

longdesc provides a text equivalent of visual content that is available for users who require another mode of sensing it in a machine-readable format. Longdesc as a secret is a fallacy.

Alternative Techniques

The suggested alternatives are not viable. Most are not programmatically determinable. They fail screenshot use case constraints and do not meet requirements.

For detailed rationale of why aria-describedby and hidden are not viable, please consult the aria-describedby and hidden documents as well as:

A normal link below the image and mentioning the link below in the image's short text alternative fails screenshot use case constraints. It is not programmatically determinable.

Existence of other approaches do not justify killing off longdesc. It is an unwarranted conclusion.

Users Who Desire Access Can Have It

As explained any user who wants to access a longdesc can do so by using tools that support longdesc.

Describing a Chart

Users Who Desire Access Can Have It

As explained any user who wants to access a longdesc can do so by using tools that support longdesc.

Chart Use Case Constraints

Both long description text in page or a visual link to a long description page add visual clutter for the sighted. As explained, a forced visual encumbrance for sighted users is information overload, which wastes time and taxes attention at the content's peril. That is a critical constraint.

Alternative Techniques

As explained, the suggested alternatives are not viable. They do not meet requirements.

Existence of other approaches do not justify killing off longdesc. It is an unwarranted conclusion.

Real World Sites Implement longdesc on Charts

The chart use case is substantiated by numerous real world examples in the wild.

Notably sister sites Statistics Canada and Statistique Canada are using longdesc on charts in "The Daily" publication. This is concrete evidence of continuing growth.

Content owners should not have to re-author accessible content, already being delivered to legacy devices for it to be valid and accessible HTML5.

Describing a Photograph

Users Who Desire Access Can Have It

As explained any user who wants to access a longdesc can do so by using tools that support longdesc.

Alternative Techniques

Other approaches are not programmatically determinable. programmatic determinability aids accessibility Without programmatically determinability no explicit relationship exists to indicate that a long description has anything to do with an image.

Existence of other approaches do not justify killing off longdesc. It is an unwarranted conclusion.

Describing an Email Banner

Images in email are a significant and valid use case because email is a major form of communication. Email has changed the shape of our lives and become a major form of communication. According to a Radicati Group Study, billions of email messages are sent every day. By 2014, it is estimated that there will be some 2.5 billion e-mail users worldwide.

As the email banner use case demonstrates, if a long description of an image is needed it can not be provided in the body of the email when constraints include:

These constraints are evidenced by 2011-2012 real world usage.

Email Banner Images Are a Valid Use Case for longdesc

No evidence has been provided that blind users do not deserve or want equal access to descriptions of banner images. The majority of blind people lose their sight later in life, either progressively, or through an accident. They have understanding of vision and are able to "visualize" what things look like in their mind's eye. This is an important part of them. They appreciate descriptions. Some have described themselves by saying, "I am blind. I am a visual person. I just can’t see".

As Joe Clark stated,

"A longdesc is a long description of an image...The aim is to use any length of description necessary to impart the details of the graphic. It would not be remiss to hope that a long description conjures an image - the image - in the mind's eye, an analogy that holds true even for the totally blind."

Other people born blind may not be interested in what such an image looks like. If they don’t want to listen to the long description, they won’t. In any case, providing longdesc provides user choice.

Critical Content Images in an email are a Valid Use Case for longdesc

An email image that is content is also a valid use case for longdesc. If the information contained in an image is important to the meaning of the page (i.e. some important content would be lost if the image was removed), a longer description than the "alt" attribute can reasonably display should be used. Longdesc provides for rich, expressive documentation of a visual image while allowing for afore stated constraints.

Description Available in a Separate Document Provides Efficiency

Using one global document to provide descriptions for multiple instance of the same image is powerful. It provides efficiency and scalability making authoring and maintenance easy wherever instances of the same image are used in multiple locations. For a full explanation of this please consult description available in a separate document provides efficiency. HTML5 should not unduly obstruct authors in this regard.

For instance the University of Minnesota Duluth uses images in separate documents that share the same long description page.

Alternative Techniques

As explained, the suggested alternatives are not viable. They do not meet requirements.

For detailed rationale of why aria-describedby and hidden are not viable, please consult the aria-describedby and hidden documents as well as:

Existence of other approaches do not justify killing off longdesc. It is an unwarranted conclusion.

Users Who Desire Access Can Have It

As explained any user who wants to access a longdesc can do so by using tools that support longdesc.

Describing Illustrations

Users Who Desire Access Can Have It

As explained any user who wants to access a longdesc can do so by using tools that support longdesc.

Description Available in a Separate Document Provides Efficiency

Using one global document to provide descriptions for multiple instance of the same image is powerful. It provides efficiency and scalability making authoring and maintenance easy wherever instances of the same image are used in multiple locations. For a full explanation of this please consult description available in a separate document provides efficiency. HTML5 should not unduly obstruct authors in this regard.

For instance the Texas State Library uses images in separate documents that share the same long description page.

Author Skill Sets Differ

As explained, Author Skill Sets Differ a different skill set exists between JavaScriptlLibrary/app developers and the run of the mill content authors/web designers.

Training budgets for organizations such as libraries have been slashed, for instance,

In today's economic climate new training for run of the mill content authors/web designers is seldom an option leaving these workers with existing skill sets.

Alternative Techniques

The suggested alternatives are not viable. Most are not programmatically determinable. They fail Illustration use case constraints and do not meet requirements.

For detailed rationale of why aria-describedby and hidden are not viable, please consult the aria-describedby and hidden documents as well as:

Existence of other approaches do not justify killing off longdesc. It is an unwarranted conclusion.

Real World Sites Implement longdesc on Illustrations

The illustration use case is substantiated by real world examples in the wild. Content owners should not have to re-author accessible content, already being delivered to legacy devices for it to be valid and accessible HTML5.

Facilitating/Describing etext Image Descriptions

etext images are a valid and significant use case. On March 11, 2011 Jim Fruchterman, Geoff Freed, and George Kerscher indicated that professional content producers (such as those involved in the ePub initiative, or the US federally funded DIAGRAM Project) indeed wish to use longdesc to meet their existing etext requirements to externally store descriptions in a non-visual manner. Their testimony to the HTML working group in support of reinstating longdesc into HTML5 states,

We are writing on behalf of the Digital Image and Graphic Resources for Accessible Materials Center (DIAGRAM; http://diagramcenter.org/) in support of the reinstatement of @longdesc into HTML5 (http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc). We believe that omitting @longdesc from HTML5 would be a serious blow to the cause of accessibility, and would set back nearly two decades of work by accessibility researchers, technologists and educators throughout the world.

The Facilitating etext Image Descriptions and Describing etext Images use cases point to longdesc as the best solution. Bill facilitates etext the creation of image descriptions by procuring a database system that utilizes longdesc. Susan, an experienced volunteer trained in writing image descriptions, creates the descriptions.

Description Available in a Separate Document Provides Efficiency

Using one global document to provide descriptions for multiple instance of the same image is powerful. It provides efficiency and scalability making authoring and maintenance easy wherever instances of the same image are used in multiple locations. For a full explanation of this please consult description available in a separate document provides efficiency.

longdesc not only fulfills requirements but also provides efficiency in this use case:

Alternative Techniques

The suggested alternatives are not viable. Most are not programmatically determinable. They fail etext image descriptions image use case constraint and do not meet requirements.

Existence of other approaches do not justify killing off longdesc. It is an unwarranted conclusion.

Users Who Desire Access Can Have It

As explained any user who wants to access a longdesc can do so by using tools that support longdesc.

Describing a Newspaper Image (Lightbox Technique)

The Zero Edit Change proposal is wrong regarding the validity of this use case. It incorrectly stated that:

This does not seem to be a valid use case: the image of the newspaper front page cuts off the text of the article at the bottom of the image, and the image appears to include unrelated stories. Providing a text version of a partial story is pointless when the article text already links to the full article within the main body of the text. The purpose of the image of the front page can be effectively described just with a short text alternative like "Front cover of Newspaper on 9.9.99 when we originally broke the story"

Where an image is cropped is a red herring to this use case. The point of the use case is that sighted users are provided detailed visual content. That content is locked in an image. It includes text as well as look and feel details of visual appearance. A blind user should be afforded the equal opportunity to have that detailed visual content of the large image described to them.

Real World rel="lightbox" Images

Real world images use lightbox functionality on an a href with rel="lightbox" to display a larger image while simultaneously using longdesc to provide a text description.

For example the lightbox technique is used on screenshots, photographs of paper forms, and equipment tags.

Sample markup:

<a href="images/big/checkin.jpg" rel="lightbox"
 title="Lightbox Image">
  <img src="images/checkin.jpg" id="checkin1"
   alt="Annotated Lab Check In System Screenshot" 
   longdesc="images/ld/checkin.html#content_frame" 
   width="200"
   height="149" />
</a>

The technique provides equal access. In this example it enables employees with disabilities and employees without disabilities needed information to do their jobs.

More Lightbox Examples

National Institute of Dental and Craniofacial Research uses longdesc and a separate invisible a href to go to a larger version of the image:

<a href="/NR/rdonlyres/5BCE4FD4-48C4-4272-BA70-E788F0F01FF4/19267/RangeFigWebsite1.jpg" 
 target=_blank>
  <img height=248 
  alt="Patterning of the neuroectoderm in sea urchin embryos - click to enlarge" 
  src="/NR/rdonlyres/5BCE4FD4-48C4-4272-BA70-E788F0F01FF4/19268/RangeFigWebsitethumb1.jpg" 
  width=400 
  longDesc=http://www.nidcr.nih.gov/Research/NIDCRLaboratories/DevelopmentalMechanisms/neuroectoderm-longdesc.html>
</a>

A related light box implementation is easyALBUM. It uses the following markup to provide a link to a larger image and longdesc to provide a long description of the image:

<a title="19th Century - Oil on wood"
 href="http://tjkdesign.com/articles/gallery/img/img/002.jpg">
 <img src="img/002T.jpg"
  alt="A necessary Skill"    
  longdesc="002LD.asp">  
</a>
  

Real world photo albums use longdesc for lightbox images.

Impossible for One Link to Have Two Destinations

One link cannot take a user to two locations. Attempting to force dual functionality into single functionality is unworkable.

Removing the possibility for direct, dual, programmatic access to both a long description via longdesc and a separate a href on an <img> element would be (a) needless authoring impediment, (b) a step backwards for HTML, and (c) a barrier to providing accessible content. Including longdesc in HTML5 affords authors a way to provide both an a href as well as an accessible programmatically determinable long description.

Alternative Techniques

As explained the suggested alternatives are not viable. They fail newspaper image (lightbox) use case constraints and do not meet requirements.

For detailed rationale of why aria-describedby and hidden are not viable, please consult the aria-describedby and hidden documents as well as:

Existence of other approaches do not justify killing off longdesc. It is an unwarranted conclusion.

Users Who Desire Access Can Have It

As explained any user who wants to access a longdesc can do so by using tools that support longdesc.

 

Alleged Incorrect Usage is a Hollow Argument

The Zero Edit/Obsolete longdesc Change Proposal parrots the same alleged longdesc usage problems as stated in Maciej Stachowiak's 2010 change proposal. As the prior Issue 30 decision determined, objections on this matter are weak and not clearly established.

However, even if it was established, an incorrect usage argument is hollow. Many web pages have incorrect usage i.e., duplicate id values when they should be unique on a page. Arguing that some authors use longdesc ineffectively is no more sensible than arguing that we must obsolete the id attribute because some authors or spec writers get it wrong. The argument is specious and a waste of time.

Incorrect usage is not the fault of a mechanism. Almost every attribute and element is incorrectly coded or applied in ways not intended. That does not mean the feature is useless and should be killed. It only means specification, education, or tools may need improvement.

Reinstating Preserves Hard-Won Progress

Access for people with disabilities is essential. This does not mean that features should be made obsolete if not all users can fully make use of them but rather that mechanisms that have a foothold must be retained. As Bill Shackleton has stated,

...an essential flaw in the key reasoning, as I understand it, to remove longdesc is in assuming that because its past effectiveness has been limited, it is doing more harm than good. That is to say, that because of poor implementation - by user agents, by content authors, etc. - it should therefore be removed.

I respectfully disagree. Much accessibility work takes time and yes, some of that time includes the need for awareness and training. In my experience, progress in accessibility has rarely been consistent or even linear... And it is definitely not binary.

It progresses in fits and starts and even, unfortunately, backslides. That's why it's important, in this case as in others, to wedge in a backstop to preserve hard-won progress. Fortunately it is fundamental W3C policy that everyone be included (regardless of disability). This means that the burden of proof does not lay with the accessibility community to make the case for maintaining longdesc in the next version of HTML, but with those who wish to remove it.

HTML5's Cool Factor (Future Advancement)

Longdesc has a starting position from which further advances can be made. The hard-won progress that Bill Shackleton speaks of can be advanced further by HTML5. HTML5 has significant buzz and is considered to be "cool". Reinstating longdesc into HTML5 will give:

It's an incentive to get the software fixed.

Because HTML5 is a hot topic, reinstating it will engender longdesc's progress.

No Evidence That Obsoleting Brings Improvement

No evidence has been presented that obsoleting longdesc will provide more accessible content than including longdesc in HTML5. It would strip a useful mechanism from authors who in fact use it and depend on it to provide accessibility.

Conclusion

The Zero Edit/Obsolete change proposal fails to provide (a) any evidence that it would be difficult or impossible for additional browser vendors to make good use of longdesc, (b) an accurate assessment of use cases, (c) any evidence that a substantial number of authors would use other techniques (or use them correctly), and (d) any evidence that obsoleting longdesc would provide more accessible content.

Longdesc solves problems and makes things better. Concrete, ample, and compelling evidence of over two thousand examples in the wild verifies beyond a reasonable doubt that authors do in fact implement longdesc in ways that improve accessibility in practice. Valid use cases clearly and directly support this specific feature of the language. Other proposed solutions do not meet requirements or constraints and do not have an existing critical support base of tools and educational materials.

Longdesc strengthens the language. The only solution that meets all requirements and fullfills all specific use cases is longdesc. Other techniques are retrograde, makeshift substitutes that do not directly provide the valuable native semantics and critical backwards compatibility that longdesc does. No better technical solution exists. The existence of related techniques does not justify obsoleting this attribute. Longdesc is perceivable to its target audience and new spec text will help browser vendors make it more discoverable to others. No negative consequences exist for including longdesc in HTML5.

People with disabilities would be the losers if longdesc were removed from HTML in favor of the Zero Edit/Obsolete change proposal. It would be an unnecessary atrocity on authors and users with disabilities.