Objection to the Proposal:Zero Edit/Obsolete longdesc

Summary

I object to the Zero Edit/Obsolete longdesc proposal for a multitude of reasons as detailed in this document.

My objection to the "Keep the longdesc attribute for the img element deprecated" proposal provides further rationale for this objection, as does the Include longdesc in HTML5 Change Proposal. Both of these documents are also relevant to this objection. People with disabilities would be the losers if longdesc is made obsolete.

longdesc Improves Accessibility in Practice

It has been substantially evidenced via the documentation of over fourteen hundred real world examples of longdesc that authors do indeed use this attribute in practice to improve accessibility. This is a non-negligible number of example <img> elements that utilize longdesc in meaningful ways. All of the images in those examples would be significantly less accessible (some even totally inaccessible) without it. By using longdesc these real world examples provide programmatically determinable long descriptions of content in accordance with a target audience's needs. Example sites using longdesc include but are not limited to:

longdesc Provides Authors With a Solution While Allowing for Constraints

The Zero Edit/Obsolete longdesc Change Proposal fails to recognize that use cases evidenced by examples in the wild along with first person testimony establishes that real constraints restrict the degree of freedom in providing solutions.

The constraints are effectively global requirements, such as limited resources or a decision by management or expected user functionality that restricts the way a solution can be provided. (e.g., technical requirement, business rule, etc.)

Forced Visual Encumbrance

A recurring constraint through the majority of use cases is that forcing a visual encumbrance on sighted users by adding long description text in-page or adding a visual link indicator in-page to a long description adds visual clutter for sighted users. This is a critical and significant constraint for designers, visual artists, and marketers because of usability and aesthetics.

Clutter is an important phenomenon in our lives, and an important consideration in the design of user interfaces and information visualizations. Many existing visualization systems are designed to reduce clutter by filtering what objects or information the user sees... Tips for designing web pages, maps, and other visualizations often focus on techniques for displaying a large amount of information while keeping clutter to a minimum through careful choices... [Rosenholtz et al., Feature Congestion: A Measure of Display Clutter (PDF)]

For sighted users, the consequences of adding a redundant visual text description is information overload which wastes time and taxes attention at the content's peril. It would be akin to having the value of the alt attribute visible by default or providing visible indicators of it. Making such features visible by default would cause needless work for designers to hide them or frustration to the majority of sighted users if designers didn't hide them.

Removing such visual clutter increases understanding and actual time-on-task for the majority of sighted users. This is where visual design plays an increasingly important role. It is well known that reducing clutter improves usability.

The statement from cartoonist Kyle Weems provides first-hand author testimony that a default visual indicator on-screen is unacceptable due to this constraint. As Kyle explained, designers object to being told to use visible links. In this use case it is illogical and redundant to recreate the dialog of a series of cartoon speech bubbles directly after the cartoon from a visual design perspective. In these types of cases the aesthetic principle of the artist will always trump 'data' requirements when those requirements become onerous. Aesthetic principles restrict the way a solution can be provided. Ignoring such author constraints is ignoring reality.

Natively Free from a Visual Encumbrance Solves a Problem

A longdesc's aim is to be a substitute for the image. It is natively free from a visual encumbrance. It solves the problem. It allows accommodation, customization, and personalization of content in accordance with a target audience's needs and capabilities.

As Suzanne Taylor and Ed McCoyd, Esq., of the Association of American Publishers (AAP) testified to the HTML working group,

The longdesc attribute does not impact the visual design. So, authors do not have to worry about how the text might impact the visual user experience. Authors can, therefore, focus on the experience of students and instructors with visual impairment while they write text alternatives. This focus on the primary audience helps authors create text that is well-suited for its purpose.

AbilityNet discuses how hiding content from view optimizes browsing experiences for two user groups,

Hiding content from view but enabling it to be read out by screen readers enables the web developer to provide additional information that is helpful for the screen reader user. This would enable the screen reader user to understand the content of the web page or the way the web page is constructed without compromising on design. This is particularly useful for elements and areas where there is not enough text describing the area or element ...Hiding content from view can enhance the usability of the website for screen reader users without compromising on design. Visual users will have no indication that these design elements are present resulting in visual and non-visual users having the optimum browsing experience.

This constraint has been amply evidenced with the documentation of over One thousand real world images that do not force a visual encumbrance for a long description by using longdesc. As evidenced, circumstances do indeed exist where page authors need, desire, utilize longdesc due to this constraint.

Programmatic Determinability Aids Accessibility

Programmatic determinability aids accessibility. This means that a specific value can be determined in a standard, machine or software readable form. Assistive technology does not have to guess about it, or use heuristics. It is authoritative, precise, and provides unambiguous specificity.

As Jason Kiss has explained,

When content is properly marked up in HTML, its semantic structure and relationships are in the markup itself. That is, they can be programmatically determined. Because this information is in the code, as it were, supporting technologies can programmatically retrieve it and present it to users in different ways. The information can be "transformed...into different sensory formats (e.g., visual, auditory) or styles of presentation needed by individual users.

An image with longdesc is programmatically determinable. It is catalytic, returning obvious value back to the user. When a long description is marked up via a longdesc attribute it allows software, including assistive technology, to extract and present the information in different modalities. It can be identified by assistive technology as being a long description beyond doubt. In turn, assistive technology can pass on the information to the user. Without programmatic determinability no explicit relationship exists to indicate that a long description has anything to do with an image.

Modern screen readers take advantage of the programmatic determinability of longdesc. They announce its presence as being a long description and provide the user with the option of reading it.

In JAWS 11 and up one can also use the list of graphics contained in the document in order to retrieve longdescs, by using the Graphics List to move focus to an individual graphic, the longdesc of which can then be accessed by hitting the "enter" key.

Additionally, longdesc is used in popular screen readers as a hook in order to notify the user that a long description exists, so even if longdesc is applied to an image that also serves as a link, it is programmatically possible to separate the activation of the longdesc for exposure from the UA's universal link activation action (which is usually activated with the "enter" key, the space bar, or by mouse click), so that the linked image retains the expected behavior in response to user interaction while a discrete mechanism is used to retrieve the long description.

As Christophe Strobbe has said:

With @longdesc the relationship between an image and its long description can be programmatically determined. I think this is one of the best arguments in favour of this attribute. This is because the tendency in HTML has been towards higher degrees of semantics and programmatically determinable relationships, for example:

  • before HTML 4, form fields could not be associated with labels because HTML had no label element; HTML 4 introduced the label element and a mechanism to associate labels with form fields in a way that can be programmatically determined;
  • before HTML 4, table data cells were not explicitly associated with header cells; HTML 4 added @id and @headers to TD and TH elements to enable explicit association;
  • before XForms and HTML5, there was no way to mark form fields as required, so developers resorted to JavaScript behaviours to work around this;
  • before XForms and HTML5, there was no way to define data types for form fields, so developers resorted to JavaScript behaviours to work around this.

The list can probably be expanded, but the point should be clear: not adding @longdesc to HTML 5 is a step backwards because it goes against the tendency to more semantics and programmatically determined relationships.

Because the relationship between an image and its long description can be programmatically determined with longdesc, it provides higher level of accessibility than techniques that are not programmatically determinable. With techniques that are not programmatically determinable a screen reader user may never know that any long description information exists.

Author Skill Sets Differ

The primary actors in use cases 1, 2, 5, 6, 7, 8, and 10 are not skilled developers but content authors, namely a:

These use cases show that people of limited skill set use HTML's longdesc. It offers a solution for these types of authors. Other solutions do not. Obsoleting longdesc would strip a useful mechanism from authors of limited skill set who are using it to improve accessibility.

As explained in my objection to the "Keep the longdesc attribute for the img element deprecated" proposal, different techniques require different skills.

Pitting aria-describedby and longdesc against each other is counter-productive to accessibility. It should not be an either/or situation. Longdesc is needed and aria-describedby is needed. A different skill set exists between JavaScript library/app developers and the run of the mill content authors/web designers e.g. advanced skill set versus basic skill set. One group may learn ARIA to develop "Accessible Rich Internet Applications" the other will use basic HTML to put up a web page or a web site.

As Cliff Tyllick has said, it is unlikely that many content creators or web designers will learn ARIA (something not native HTML). They already feel like they've learned far more than they should have to know under their job description. And in many cases, their supervisors agree. Cliff goes on to say,

And the use case for needing this to be inherent to HTML5 is simply this: Many people who put content on the Web have training in nothing more than html. If you call any technique by a different name - whether it's Java, AJAX, or ARIA - they will not learn it. So if the means for attaching this information to an image is not within html, they won't use it.

Content creators/basic authors should not be forced to read another large spec besides HTML5 to make content accessible. These authors may know basic HTML and be willing to put in longdesc for complex images but most are not going to delve into other specs. ARIA is not an option for them. If content is to be made accessible by both groups of authors we need both mechanisms.

Most basic content authors are not going to learn two languages to make images accessible. When accessibility is not relegated to a separate spec but integrated into the host language, it is viewed as a mainstay rather than as an afterthought or add-on. Educators have a hard enough time teaching HTML, and an even harder time teaching the need for accessibility (and the means to address those needs). Pile on yet another layer and the difficulties will increase exponentially.

ARIA is powerful technology. If HTML5 forces ARIA upon basic content authors in order to make content accessible, what these authors will end up doing with it is unknown. Encouraging people who don't intend to learn ARIA thoroughly to dabble in it could have unintended consequences. For instance, make a counter a live region - disaster - but it seems logical. Mark a section of your page as an "application" because to you it is an application - seems great. But if you don't handle every keyboard command - it's another disaster.

Two types of authors are recognized, differentiated, and provided for separately by other standard organizations. For example, in 508-255 Refresh (ANPRM) the Access Board provides Chapter 5 for document authors and Chapter 4 for app developers. They state,

Advisory 501.1 Scope. The provisions of this chapter apply to electronic documents, which are mostly static, read-only, non-interactive electronic content. Examples include Word files, PDFs, PowerPoint presentations, Excel spreadsheets, and simple web pages (which do not contain Flash). However, electronic documents may also contain interactive content, such as hypertext links, buttons, and form elements or fields. All of these elements are covered in this chapter. Electronic content covered by this chapter includes most non-paper documents and web content, regardless of format.

This chapter is oriented towards document authors, rather than developers.

Provisions relevant to more robust user interaction, including scripting, are found in Chapter 4 (Platforms, Applications, and Interactive Content). Additional requirements for audio and video content are found in Chapter 6 (Synchronized Media Content and Players).

Both advanced developers and the run of the mill content authors/web designers deserve to have suitable tools at their disposal for providing long descriptions. Both need to be provided for. Anything else is a false choice. It would be discriminatory if only ARIA skilled developers are able to publish an accessible image on the Web.

Not Being Forced Upon Users

As explained in my objection to the "Keep the longdesc attribute for the img element deprecated" proposal,

With aria-describedby the description is forced upon screen reader users whether they want it or not. They cannot interact with it at will. aria-describedby is read aloud without any user intervention, forcing the screen reader user to listen to it each and every time they encounter the image whether they want to or not. The user is not able to control how they interact with the long description.

As the Association of American Publishers has explained,

aria-describedby cannot be silent by default in screen readers when used on images, compromising its use to illustrate that the content of an image is already available on the page.

Such behavior makes aria-describedby a non-starter. None of this is a problem with longdesc as it supplies descriptions on-demand and not by force. Longdesc is an "escapable structure" as Janina Sajka illuminated.

Distracting and Frustrating Circular User Experience

AAP goes on to explain that,

Developers may not realize the distracting and frustratingly circular user experience that this would cause and might use aria-describedby to point to, for example, a paragraph just above the image. Users would then likely follow the aria-describedby announcement, expecting to find additional content, but they would arrive, instead, at a paragraph that they have likely just read.

Supporting Structured Text

As explained in my objection to the "Keep the longdesc attribute for the img element deprecated" proposal,

Even though it can point to structured content such as bulleted lists and paragraphs aria-describedby can only process structured content as string-text. This is because the accessibility APIs that aria-describedby maps to do not support structured content due to tab focus requirements.

This means that assistive technology treats aria-describedby target content as though it does not have any mark-up. It is treated as a string. All structure is stripped clean. A user's reading keys will not work. Users are not able to interact with the content. All links are dead.

This is not a problem with longdesc. Longdesc supports structured content. Reading keys and links work.

longdesc is Useful to Users

In recent research the majority of screen reader users declared longdesc useful. Over 60 percent of the 1090 respondents found it somewhat to very useful. No evidence has been provided that the majority of the longdesc attribute target user group do not benefit from it.

The AAP has directly testified that longdesc enhances the user experience by increasing learnability. They stated,

Students and instructors will find the same user interface throughout all materials, so they will not need to learn new interfaces product-to-product, which takes time and attention away from the learning content.

The Zero Edit/Obsolete longdesc Change Proposal fails to provide concrete evidence that longdesc creates a bad accessibility experience. As stated in the original decision the supposed "problems with longdesc" are highly anecdotal or non-scientific.

longdesc Strengthens the Language

Content should be marked up based on what it is. The longdesc attribute best reflects a long description.

Longdesc strengthens the language. It adds semantics, which provides a higher level of communication. Communication is pretty much the point of language design. Lay people looking only at how a page displays may never get that additional communication, but machines can. Providing that extra meaning allows machines to translate it for people.

Semantic HTML is important to authors because as John Allsopp has explained,

We need mechanisms in HTML that clearly and unambiguously enable developers to add richer, more meaningful semantics-not pseudo semantics-to their markup. This is perhaps the single most pressing goal for the HTML 5 project.

But it’s not as simple as coming up with a mechanism to create richer semantics in HTML content: there are significant constraints on any solution. Perhaps the biggest one is backward compatibility. The solution can’t break the hundreds of millions of browsing devices in use today, which will continue to be used for years to come. Any solution that isn't backward compatible won’t be widely adopted by developers for fear of excluding readers. It will quickly wither on the vine.

Longdesc provides semantic richness to the language while being backwards compatible. Dropping longdesc from the newest version of HTML would drop meaningful semantics and weaken the language.

The rationale that HTML5 should have built-in semantics was successful rationale used to keep <figure>, <aside>, <details>, and hidden="". The decisions on those issues set the precedent that native HTML semantics is a determining factor of what is included in the language.

For further rationale regarding semantics, please refer to my objection to the Keep the longdesc attribute for the img element deprecated proposal.

longdesc Provides Backwards Compatibility

Expecting authors to rewrite their content in order to support techniques that (a) do not work for authors or users, (b) are not programmatically determinable, (c) ignore aesthetics and other constraints, and/or (d) are simply cumbersome "hacks", is nonsensical and totally unrealistic : such attempts will serve only to infuriate and alienate both those authors and the accessibility community as a whole.

As explained in my objection to the "Keep the longdesc attribute for the img element deprecated" proposal,

It is much less invasive to make longdesc fully conforming. This approach removes an illogical undue burden and will be acceptable to authors and organizations that have made investments in the use of longdesc. This attribute has made content accessible to users on company, organizational, governmental, educational, and personal sites throughout the world. It is implemented in user agents, authoring tools, and assistive technology. Content owners should not have to re-author content, already being delivered to legacy devices as well as to today's leading-edge browsers and assistive technology, in order for it to be valid and accessible HTML5.

Longdesc-related features in existing authoring tools should continue to output valid content : both authors and users have perfectly reasonable expectations that longdesc will continue to be supported by existing tools, and will continue to have its current (i.e., intended) effect in existing content.

Obsoleting longdesc would result in mixed messages between existing documents and HTML5. Such messages can serve only to confuse. Those who encounter the array of books, online tutorials, guidelines, laws, policies and standards that have already recognized longdesc's importance to accessibility will expect longdesc to continue to function as described. Materials such as these have a way of living on; they will not be obsoleted in the foreseeable future, and therefore neither must longdesc.

Obsoleting longdesc would break both compatibility with existing best practice (and documentation of the same), as well as requiring a wide range of tools, content, and authoring guidance to be updated in order to achieve compatibility with the replacement - for something meant to solve the same problem, this is an intolerable cost. Backwards compatibility is absolutely necessary.

longdesc is Experiencing Increased Usage in the Wild

Even though it is most useful for a small group of users and not needed by the majority who have the luck to live on this planet with two healthy eyes, longdesc is experiencing increased usage in the wild.

For example, during the past year alone, numerous organizations such as the A11y Bugs Project, Aboriginal Affairs and Northern Development Canada, Axel Schäfer, SPD Abgeordneter im Deutschen Bundestag für Bochum, CSS Squirrel, Canada Virtual Museum of Valentines, Canadian Department of Justice, Canadian Space Agency, Correctional Service Canada, Department of Transportation (Taiwan), Courts Administration Service (Canada), Daegu Metropolitan Office of Education (South Korea), Office of the Superintendent of Financial Institutions Canada, Elections Canada, Environment Canada, Griffith University (Australia), Hipocampo, HTML Accessibility Task Force, HTML5 Multimedia, Kyungpook (South Korea), Marine National Park (Taiwan), Michigan State University, National Center on Birth Defects and Developmental Disabilities, Object Description, Ohlone College, University (South Korea), Oracle, Oriental Hospital of Daejeon University (South Korea), Panel on Responsible Conduct of Research (Canada), Paris Web, Parliament of Canada , Public Safety Canada, Public Works and Government Services Canada, Rebuilding The Web, Social Security Online, Special Education Support Center (South Korea), Statistics Canada, Statistique Canada, Substance Abuse & Mental Health Services Administration, tech.burningbird, Treasury Board of Canada Secretariat, Texas State Library, U.S. Department of Health & Human Services, and the University of Minnesota have used it in reports and publications.

Notably the two sister sites Statistics Canada and Statistique Canada began consistently using longdesc in "The Daily" publication. "The Daily" produces statistics on a business-day basis that help Canadians better understand their country, its population, resources, economy, society and culture. Please refer to Statistics Canada and Statistique Canada for detailed evidence.

On July 29, 2011 Suzanne Taylor and Ed McCoyd, Esq., of the Association of American Publishers attested:

We are using longdesc increasingly in our products.

On March 11, 2011 Geoff Freed indicated that professional content producers (such as those involved in the ePub initiative, and the US federally-funded DIAGRAM Project) are interested and ready to use longdesc to meet their existing requirements, thereby increasing the pool of useful and well constructed longdesc descriptions in richly structured documents.

User Agent Support

Any user can access a longdesc by using a user agent that supports it. Recent research finds that modern screen readers have good support for the longdesc attribute. A collection of tools that provide support for longdesc exists for those that need or require that support, and individual users who want to access long descriptions supplied via longdesc, whether they are sighted or not, have a choice of options to do so. The claim that longdesc isn't exposed to some users is outweighed by the concrete examples of it being exposed in accessible ways and is as ludicrous as suggesting that the <img> element should be removed from HTML5 because its graphic contents cannot be disclosed to users who elect to use Lynx or similar.

On March 11, 2011, professional content producers at the Digital Image and Graphic Resources for Accessible Materials Center (DIAGRAM) addressed longdesc support for other users. Their testimony states:

features developed to help people with specific disabilities also assist other users, and this is true for long image descriptions. Today, for example, Firefox and Opera allow the user to open a context menu over an image and choose to see the long description on the screen, if @longdesc is included with the image. This is an excellent tool for assisting sighted students with learning disabilities who need textual reinforcement when deciphering the contents of a complicated image. Also, as image descriptions become more widely used, it is expected that search engines can take advantage of descriptions in locating relevant images.

Growth in User Agent Support

Since March 11, 2011 user agent implementation has grown. The following examples clearly demonstrate this and how longdesc is machine readable.

longdesk

The Zero Edit/Obsolete longdesc proposal inaccurately states,

To be successful longdesc needs to have an activation mechanism as easy and intuitive to use as a normal link, which is probably impossible.

It is not impossible. A new longdesk FireFox extension has been developed that adds a link to the longdesc under images that provides one. It makes the longdesc activation easy and intuitive for sighted users who wish access.

TellMeMore

For those who would like an indication of when longdescs are available on a page without interfering with page design, a new TellMeMore Opera extension has been developed. It respects visual design and does not force an on-page visual encumbrance. Instead it provides an icon in the chrome to indicate when descriptions exist. Then, upon activating the icon, the user is presented with a popup containing a list of all descriptions available along with their thumbnail images.

Scripted Implementations

New direct replacement functionality has been provided via a scripted implementation. easyALBUM utilizes programmatic determinability as evidenced in several recent photo albums.

Internet Explorer Solution

Internet Explorer can now be configured to handle longdesc.

The Future and User Agent Support

The Zero Edit/Obsolete longdesc Change Proposal fails to provide any evidence that it would be difficult or impossible for user agents to identify and make good use of longdesc. In fact, a FireFox browser vendor responded to a question asking "Would it be possible to make longdesc a global attribute?" by saying, "This is software, anything is possible".

To help browser vendors in this effort in the future, new text has been specified for the 10.6.1 rendering section. which illustrates how longdesc can be made discoverable.

Alternative Techniques

Overview

The Zero Edit/Obsolete longdesc Change Proposal suggests that the existence of alternative/related long description techniques is rationale to drop longdesc from HTML. The alternatives are retrograde, makeshift substitutes for longdesc.

As delineated one-by-one in the Include longdesc in HTML5 Change Proposal, an explicit link, aria-describedby, figcaption, details, aria-describedat, image map, or a new HTML attribute are not viable solutions. Please refer to that document and the how proposed solutions meet some common long description requirements matrix for details.

The following information regarding rel="longdesc", cascading style sheets, and aria-describedby provides further rationale as to why the existence of these techniques does not justify killing off longdesc.

rel="longdesc"

rel="longdesc" has been suggested as a "progressive enhancement" solution for supplying long descriptions and a reason to obsolete longdesc. Accessibility is not "progressive enhancement"; it is core functionality.

The fact is rel="longdesc" syntax only works on a limited subset of use cases. It is impossible for one link to take a user to two locations. As Julian Reschke has explained,

<a href=* rel=longdesc href=URL><img src=* alt=*></a> only works when the <img> element doesn't already have a parent <a> element, which is something which is used a lot.

rel="longdesc" is not programmatically determinable when an image already has a link which is mapped to go to another page or a larger image. Expecting all <img> elements that need long descriptions not to have a parent <a> element mapped to a different task unrelated to a long description is unrealistic. Attempting to force dual functionality into single functionality as proposed in the Zero Edit/Obsolete longdesc proposal is unworkable.

For example, if an image already has a link that takes the user to another page (i.e., a logo image that links to a home page, one cartoon in a series of cartoon images that links to the next comic strip page, a thumbnail image in a gallery that links to a larger version of an image, etc.), it is impractical and most times nonsensical for the destination page to shoehorn in a long description. It would provide a confusing and inferior user experience.

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.

In addition, obsoleting longdesc in favor of rel="longdesc":

In sum this suggestion is unworkable and not an excuse to drop longdesc from HTML. Its existence does not negate the need for longdesc.

Cascading Style Sheets

Cascading Style Sheets (CSS) have been suggested as a solution for hiding long description indicators in combination with other alternative solutions such as rel="longdesc" or a non-programmatically determinable explicit link. Requiring authors to use CSS to hide the indicator when longdesc already does this natively, not only adds needless complexity, page weight, and inconsistency, it also is error prone and disenfranchises authors of limited skill set.

As pointed out in my objection to the "Keep the longdesc attribute for the img element deprecated" proposal,

The Association of American Publishers (AAP) has attested that piecemeal, workarounds for not forcing a visual encumbrance creates complexity, inconsistency, and unreliability. In particular they point out that hiding long description link text visually,

would require custom CSS or scripting. The mechanism for hiding the link would therefore differ product-to-product, making browser extensions or features to show the links more complex to code and less reliable for users.

CSS rules such as img{border:0;} for a long description link on an image is a needless, circuitous kludge. Older native HTML syntax is simple. Requiring CSS would add page weight and slow pages. Authors have voiced these facts. For instance, on October 13, 2011, Barry Kintner beseeched the HTML working group:

Please do not drop recognition of older (simpler) HTML vocabulary. I find far too many people are over-using CSS etc - not really knowing or understanding the needs of the visitor...

I find I've been able to re-create business web pages - with all functionality retained - that are 60-90% smaller in file size, by using so-called 'older' standards. Retain all the old codes that had been usable before (from 3.2-4.x).

Hiding long description indicators and link text with CSS adds needless complexity and is error prone. The potential for confusion is rife.

Even authors versed in CSS have problems hiding long description indicators with CSS in a manner that is accessible. As explained in my objection to the "Keep the longdesc attribute for the img element deprecated" proposal, the declaration display:none is hidden from screen readers. Not many authors know that fact. They use it to hide long description link text and it does not work for their target audience. For instance, Snowdon Award Scheme, and Zew have mistakenly used display:none for long description link text indicators. However, this common mistake was mitigated in these three examples because they also used longdesc, which works.

Another example of an inaccessible CSS technique is using visibility:hidden. This declaration should not be used for content that is to be read by screen readers because it hides content from them. Daegu Metropolitan Office of Education is an example of an organization mistakenly using this technique. Fortunately they also used longdesc, which does work.

Hiding long description indicators and link text with CSS would especially place an undue burden on authors of limited skill set. They will not know how to use CSS let alone know which techniques may be accessible and which definitely are not. With longdesc this is not an issue because it is natively free from a visual encumbrance.

If HTML5 obsoletes longdesc and an author's only choice to hide long description indicators/link text is relegated to CSS, many will use the wrong techniques. Requiring the use of CSS when longdesc is already natively free from a visual encumbrance reinvents the wheel. It is an inefficient, inelegant , and clumsy "hack" that not only adds needless complexity, confusion, page weight, and inconsistency, it also is error prone and disenfranchises authors of limited skill set. All told, it would result in less accessible content.

aria-describedby

aria-describedby is explicitly addressed in my objection to the aria-describedby change proposal. Please refer to it for rationale of why it is not workable. And even if it were, that would not negate the need for longdesc. Killing off longdesc in the name of ARIA is a false choice and an unwarranted conclusion.

No Proof of Better Authorability

The Zero Edit/Obsolete longdesc Change Proposal fails to provide any evidence that authors would use or get alternative techniques correct more often than longdesc.

Rebuttals to Use Case Comments

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:

  • A11y Bugs Project
  • Accessibilité du Web (Canada)
  • Axel Schäfer, SPD Abgeordneter im Deutschen Bundestag für Bochum
  • CSS Squirrel
  • Commonwealth of Massachusetts
  • Conseil supérieur de la langue française
  • Daegu Metropolitan Office of Education (South Korea)
  • Dhammadana
  • Digital Inspiration
  • dizABLED
  • easyALBUM
  • Elections Canada
  • Environment Canada
  • Federal Motor Carrier Safety Administration
  • Financial Transactions and Reports Analysis Centre of Canada
  • Griffith University
  • Grinning Planet
  • Hawaii Public Schools
  • IBM Corporation
  • Interacciones
  • Korea Employment Information Service
  • Lexdis
  • Michigan State University
  • My Opera
  • National Institute of Information and Communications Technology National Adult Literacy Database
  • National Institutes of Health
  • Natural Resources Canada
  • nota-ben
  • Oracle
  • Paris Web
  • Public Service Commission of Canada
  • Rebuilding The Web
  • Research and Innovative Technology Administration / US Department of Transportation
  • San Diego University
  • Snowdon Award Scheme
  • Statistics Canada
  • Statistique Canada
  • Texas State Library
  • The Organisation Development Company
  • The Original Teaching of Buddha
  • University of Minnesota Duluth
  • U.S. Department of Health and Human Services

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.

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 authors freedom of choice. Authors are already providing this functionality, as evidenced by real world examples.

Equal Access

No evidence has been provided that blind users do not deserve or want access to the long description of a logo whilst at the same time being given direct access to the link to (e.g.,) an organization's home page.

This functionality is taken for granted by sighted users as they automatically see what a logo looks like while being able to directly access a home page link. Longdesc provides this same functionality for screen reader users. It is an accommodation.

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". 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 either case, longdesc provides the user the with the opportunity for an equal experience.

Separate Logo Link Is Not Programmatically Determinable

Programmatic determinability aids accessibility as previously explained. 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.

Real World Sites Implement longdesc on Logos

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

  • AccessAbility SIG
  • Alpen
  • anblik
  • Center for the Study of Religion and American Culture
  • Fundación Sidar - Acceso Universal (Spain)
  • haecceitas
  • Indiana University-Purdue University Indianapolis Common Core Curriculum
  • Santa Barbara Public Library
  • Securian
  • tech.burningbird
  • ZEW

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

Users Who Desire Access Can Have It

As previously 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

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.

Alternative Techniques

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

Other Approaches:

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 previously 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. For example, Dayton Art Institute's accessart site uses/used the longdesc for the long description and an a href to go to a different "dialogue with the director" page. The longdesc attribute was used for all images in the tours to describe images. The site seems currently seems to be down. But they Wayback Machine provides examples: Museum Highlights From the WayBack Machine and Long Description: Joy of Waters 1917 from the Wayback Machine).
  2. When the aesthetic constraints prevail. Ignoring aesthetic considerations is ignoring reality. Longdesc affords efficient reuse of one long description for both the large and small image. This helps content authors as they only have to author the description content once and can reuse it on multiple images. Reuse is powerful and a valuable pattern found in other languages for instance external cascading style sheets.

Alternative Techniques

As previously explained the suggested alternatives are not viable. They fail artwork use case constraints 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 previously explained, any user who wants to access to 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

As explained longdesc is perceivable.

Alternative Techniques

As previously explained, the suggested alternatives are not viable; most are not programmatically determinable; they fail screenshot use case constraints; they do not meet requirements.

Other Approaches:

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

Users Who Desire Access Can Have It

As previously 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 previously 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 previously 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 previously explained, the suggested alternatives are not viable. They do not meet requirements.

Other approaches:

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.

  • Accessibility Task Force Bug Comparisons
  • Accessibilité du Web
  • Commonwealth of Massachusetts
  • Federal Motor Carrier Safety Administration
  • Environment Canada
  • Financial Transactions and Reports Analysis Centre of Canada
  • Griffith University
  • Hawaii Public Schools
  • Korea Employment Information Service
  • Michigan State University National Institute of Information and Communications Technology
  • National Adult Literacy Database, National Institutes of Health, National Institutes of Health
  • Natural Resources Canada
  • Public Service Commission of Canada
  • Research and Innovative Technology Administration / US Department of Transportation
  • Statistics Canada
  • Statistique Canada
  • U.S. Department of Health and Human Services
  • San Diego University

As previously mentioned 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 previously explained, any user who wants to access a longdesc can do so by using tools that support longdesc.

Alternative Techniques

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

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:

  • The fact that the email's format is a short digest.
  • Organization's design guidelines or branding requirements preclude it.

These constraints are evidenced by 2011 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.

Alternative Techniques

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

Users Who Desire Access Can Have It

As previously 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

who wants to access an email longdesc can do so by using tools that support longdesc.

Author Skill Sets Differ

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

For detailed rationale regarding author skill set please refer to my objection the Zero Edit/Obsolete proposal.

In addition, training budgets for organizations such as libraries have been slashed, for instance, Jacksonville mayor cuts library's travel and training budgets, Ohio Libraries have cut staff training, Proposed Budget in Texas Nearly Zeros Out Key State Library Funds, Texas Governor Signs Budget Cutting State Funding for Library Services by 88 Percent, Texline 265: Proposed Budget Demolishes Statewide Library Programs Eliminates the Technology Allotment at TEA, 'Depression' Era Budget Cuts Could Shutter Libraries, State budget cuts hit rural libraries hard. 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

Other approaches:

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

Other international working groups, such as those developing recommendations for digital talking books (DTB) and e-books (EPUB), look to HTML5 for guidance and conformance. Without a specified method for providing long descriptions, it is entirely possible that HTML documents, e-books and DTBs will wind up providing long or detailed descriptions in independent and perhaps incompatible ways. Such confusion in the delivery of long descriptions will undoubtedly result in a delay and/or reduction in the accessibility of textbooks with obvious negative impacts for students with print disabilities. Furthermore, as textbooks, electronic media content, Web browsers, mainstream e-readers and assistive technology continue to merge and are used interchangeably, a single universal standard for providing high-quality detailed image descriptions is essential.

Removing @longdesc from HTML5 without replacing it with superior technology puts people with print disabilities at a severe disadvantage. It is not possible to overstate the importance of having long-description support in HTML5. In its current state, @longdesc is the only method for authors to provide externally stored descriptions in a non-visual manner to users with print disabilities. @longdesc is in widespread use (http://www.d.umn.edu/~lcarlson/research/ld.html), and it is supported by widely available access technologies. Because @longdesc can point to external resources, it can deliver high-quality, detailed descriptions in a method that no other element, attribute or property can provide today. Without this attribute, authors of Web sites, electronic textbooks and other digital resources have no way to efficiently deliver long image descriptions to users with print disabilities. Access to educational materials, some of which are mandated by national laws, will be disrupted for countless blind and visually impaired students worldwide.

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.

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

  • The description file is in a single central location, which simplifies creation by a group.
  • When an external longdesc is used, one description file can globally control all instances of an image. This is powerful. It makes maintenance quite easy when a number of images exist in numerous books.
  • Lowers costs by lowering bandwidth use. Longdesc allows for leaner code overall - you only do your http transport on demand, resulting in smaller, faster pages, and reduced bandwidth consumption. Those who don't need the description are spared the extra bandwidth. etext sizes are smaller, quicker to load.
  • etext markup reduced in complexity as descriptions are external to the book.

Alternative Techniques

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

Users Who Desire Access Can Have It

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

Describing a Newspaper Image

Where an image is cropped has no bearing on the validity of the use case. A use case in software engineering and systems engineering, is

a description of steps or actions between a user (or "actor") and a software system which leads the user towards something useful.

The actors in the newspaper Image use scenario added value to their work in step-by-step action while adhering to constraints. The result is that both sighted and unsighted audiences are well served. Content is customized in accordance with user needs and capabilities making this a valid use case.

Alternative Techniques

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

Users Who Desire Access Can Have It

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

A Direct Functional Replacement is the Wrong Approach

This Zero Edit Change Proposal: Keep Longdesc Non-Conforming had one thing correct. A direct functional replacement is the wrong approach. It reinvents the wheel. Longdesc provides the needed functionality.

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

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 have and are using it to improve accessibility.

Conclusion

I object to the Zero Edit/Obsolete longdesc proposal for a multitude of reasons as detailed in this document.

The Zero Edit/Obsolete longdesc 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 1400 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. 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 this proposal. It would be an unnecessary atrocity on authors and users with disabilities.