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.

The Include longdesc in HTML5 Change Proposal provides further rationale for 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 two thousand 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 Adds Visual Clutter

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.

Jonas Sicking publicly acknowledged and accepted that this constraint is valid in his change proposal saying that,

page designers often have quite strict requirements on the visual appearance of the page and it would likely negatively impact the level of accessibility support if contents specifically for for example screen readers had to be provided within those requirements.

A forced visual encumbrance 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 attribute is natively free from a visual encumbrance. It solves a problem as 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 eighteen hundred real world images that do not force a visual encumbrance for a long description by using longdesc. As this compelling pattern evidences, circumstances do indeed exist where page authors need, desire, and utilize longdesc due to this constraint.

Allowing Discoverability Serves Use Cases

Scott Berkun has explained the myth of discoverability,

The myth of discoverability, in concise form: The belief that all good user interfaces make all things in the website or product utterly and extremely discoverable, and any design that makes an element (button, link, etc.) less than extremely discoverable, can't possibly be very good, and should be thrown away, to the embarrassment of the designer...All things can not be easily discoverable because everything is limited.

The fact is that, some people may want or need to consume or access long description content that doesn't force a visual encumbrance but do not use assistive technology (AT). The following sighted people may be aided by access to a longdesc:

Existing Discoverability Tools Fulfill These Use Cases

Discoverability tools exist for longdesc. These tools are used by sighted authors and others. 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.

The Include longdesc in HTML5 change proposal provides a solution to the forced visual encumbrance constraint while specifying discoverability functionality for all who want access to the description. 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.

No discoverability tools exist for proposed solutions such as hidden.

Incentive for More Discoverability Tools

On May 5, 2012, HTML Co-Chair, Maciej Stachowiak stated,

if a UA can give a better experience i think they should be encouraged to try

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. It will encourage them to improve support. As Anne van Kesteren has said, examples in the specification serve as an incentive to vendors:

It's an incentive to get the software fixed.

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.

Semantics Improve Communication

Semantic elements and attributes provide 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.

HTML5 Precedent

The rationale that HTML5 should have built-in semantics was successfully used to keep <figure>, <aside>, <details>, and hidden in the specification. The Retain several newly-introduced semantic elements, attributes, and controls change proposal stated,

Semantics are universal. Expressing semantics with native elements promotes Universal Access better than expressing semantics just to users of AT by using ARIA attributes.

The decisions on those issues set the precedent that native HTML semantics is a strong determining factor of what is included in the language.

WAI-ARIA Provides Missing Semantics

The bridging technology, aria-describedby, and aria-describedat sections of this document provide full explanation of why ARIA is not viable. Shirking off the responsibility of providing long description semantics to ARIA is retrograde. In other words, the premise is entirely backward. ARIA should be used to augment missing native semantics of HTML as necessary, not as an excuse to kill and to replace them.

As the Accessible Rich Internet Applications (ARIA) specification states,

WAI-ARIA is intended to provide missing semantics

HTML is Not Missing Native Semantics

HTML is not missing long description semantics. It possesses native, built-in long description semantics that are conveyed to assistive technologies as well as other technologies with longdesc.

The longdesc attribute is unequivocally the most clear, direct, explicit, and strong semantic with the broadest support base for providing a long description of an image above and beyond any other attribute or element.

This undeniable semantic requires no heuristics to interpret which consequently enables precise programmatic determinability to take place.

Using a Bridging Technology is Backward

Bridging technologies are not intended to replace native HTML semantic features. Detouring accessibility technical requirements into an "Accessible Rich Internet Applications" bridging specification is backward.

The Introduction to ARIA clearly states,

WAI-ARIA is intended to be used as a supplement for native language semantics, not a replacement. When the host language provides a feature that provides equivalent accessibility to the WAI-ARIA feature, use the host language feature.

The Protocols and Formats (PF) Working Group's Charter states,

Note that WAI-ARIA is intended to be a bridging technology. It is expected that, over time, host languages will evolve to provide semantics for objects that currently can only be declared with WAI-ARIA.

This was reinforced by Al Gilman, prior PF Chair, on behalf of that Working Group,

The working group likes the idea of having built in semantics in HTML and in particular would prefer to have common document elements, such as widgets built in to the markup. This reduces download size and the effort required to make a web page accessible. For these reasons, we would promote the use of such markup over the ARIA approach.

The idea was that native mechanisms would enrich the vocabulary of the language, thus rendering ARIA increasingly unnecessary.

As Derek Featherstone has stated, "ARIA is designed to provide accessibility at a technical level - what you might call 'programmatic accessibility' - where it doesn't already exist". Longdesc exists.

WAI-ARIA Goal and Dangers

A significant goal of WAI-ARIA is to:

help stimulate the emergence of more semantic and accessible markup. When native semantics for a given feature become available, it is appropriate for authors to use the native feature and stop using WAI-ARIA for that feature.

WAI ARIA should only be used as a last resort when content can't be made accessible using the host language. Everett Zufelt commented on HTML5 Doctor,

There are huge dangers in using ARIA instead of natively supporting accessibility in HTML5, these are not technical in nature. The longer the broader development community, such as the HTMLWG, ignores accessibility, or thinks that others like the PFWG / WAI will take care of it for them, the longer we will need technologies like ARIA to fill in the blanks.

Karl Groves illuminated the main point in his article "Confusion over HTML5 & WAI-ARIA",

The HTML specification is the shortest path to true accessibility

HTML is the direct route.

Henri Sivonen has stated,

the whole point of ARIA is to make semantic abuse accessible as an afterthought.

In other words ARIA is bandage meant to patch.

It is perhaps Ian Hickson who states the case best when he says that ARIA,

is not intended for use by authors who are trying to convey the very semantics that HTML can already convey.

Shirking Off Long Description Semantics to ARIA

HTML has native, built-in long description semantics with longdesc.

Keeping it core to the language keeps valuable semantics in HTML. It provides forethought, which thereby reduces the need for ARIA to be used as an accessibility afterthought.

The idea of HTML obsoleting longdesc, a native semantic attribute, and shirking off the responsibility of providing long description semantics to ARIA is retrograde. In other words, the premise is entirely backward.

ARIA should be used to augment missing native semantics of HTML as necessary, not as an excuse to kill and to replace them.

Author Skill Sets Differ

People of Limited Skill Set Use longdesc

Use cases demonstrate that people of limited skill set use longdesc. The primary actors in use cases 1, 2, 5, 6, 7, 8, 9b, and 10 are not skilled developers but content authors, namely a:

These use cases demonstrate that people of limited skill set use HTML's longdesc. It offers a solution for run of the mill content authors/web designers whereas other solutions do not. Obsoleting longdesc would strip a useful mechanism from authors of limited skill set who are using it to improve accessibility.

Need for Simplicity

Complexity confuses and leads to errors. This is especially true when complexity is imposed directly on run of the mill content authors/web designers. longdesc is simple. As Kyle Weems illuminated,

are we going to pretend that using longdesc is difficult? Yes, people may use it wrong without some correction, but simply saying "Hey, put a URL there," is not complex at all

The Association of American Publishers (AAP) concurs. In regard to their production processes and quality assurance the AAP has provided first-hand testimony to the working group stating,

The longdesc attribute is easy to code.

As a rule, the more complex the markup pattern, the more likely authors are to make mistakes when implementing it. We should strive to find the simplest markup patterns that satisfy requirements.

Need for Support Tools

Without WYSIWYG authoring tools run of the mill content authors/web designers authors would be disenfranchised. They rely on tools to author and test long descriptions.

It has been well established that numerous WYSIWYG web designer authoring tools support longdesc. An array of tools exist to author longdesc and to check that the longdesc works.

Authors rely on tools to test long descriptions. Two browsers (Opera, iCab) natively support longdesc link testing (three if we count Home Page Reader which is currently still in use in Japan). longdesc has a growing arsenal of extensions, configurations, and plugins that are used for testing including Jim Thatcher's powerful long description favelet, which provides universal functionality of longdesc in browsers such as Chrome, FireFox, Internet Explorer, and Safari.

No tools for other solutions such as aria-describedby/hidden exist to allow authors to create and test long descriptions.

Indeed, authoring tool vendor Vlad Alexander has provided first-hand testimony stating,

Authoring tool vendors are likely to find it difficult (or even impossible) to build user-friendly interfaces that use the aria-describedby feature. This is likely to result in confusion and little use of the feature.

He confirmed on July 5, 2011 that,

As an authoring tool vendor, we will not be supporting ARIA for content in XStandard, and I cannot see that many other tool vendors will support it either. Implementing ARIA for content does not make business sense for authoring tool vendors, because the non-technical content authors who buy our tools will find it far too complex to use, and because using ARIA for content does not produce better results than existing accessibility features.

Need for Educational Materials

A longdesc support base exists in the form of authoring documentation, tutorials, books etc.

No evidence exists that substantial ARIA documentation or tutorials are in place and ready to educate developers. In fact, on June 18, 2011 Paul Irish said,

Most developers have no idea how to implement ARIA. The W3C Primer that looks like a spec is just.. laughable.. not at all appropriate for a web developer audience.

This situation has not changed. On June 1, 2012 Paul Irish repeated that statement,

Most developers have no idea how to implement ARIA. The W3C Primer that looks like a spec is not at all appropriate for a web developer audience.

In contrast a longdesc support base already exists in the form of authoring tools, tutorials, books etc. These longdesc support materials will live on.

Training Budget Limitations

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.

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

Different Techniques Require Different Skills

Pitting ARIA and longdesc against each other is counter-productive to accessibility. It should not be an either/or situation.

ARIA Skill Set

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.

It is recommend [Freedom Scientific 2012 (doc file)] that Web page authors,

read the ARIA best practices guide carefully before adding ARIA markup to their pages.

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.

ARIA adds needless complexity, As Christian Heilmann stated,

If you dive into ARIA you will realise very quickly that it is a lot of work, hard to understand concepts and above all a lot of code to write. Instead of having accessibility as an integral part of HTML5, we have to deal with two parallel standards. One to achieve things quickly and move the web from documents to applications and another one to keep it available for everyone out there. This is not a good place to be in. Accessibility happens when you embrace it from the very start.

The fact is that it is far more complicated for ordinary authors and designers to author hidden relationships than provide a simple link via a longdesc attribute.

No one would want redundant text on-screen, as it would state what is visually evident. So to use aria-describedby, a person would have to write the content, then hide it, and then reference the hidden text with aria-describedby using hidden relationships. That's so burdensome that surely even the most enthusiastic ARIA supporter should realize that the longdesc attribute is far more efficient.

Vlad Alexander thoroughly explains in the article Is ARIA for content doomed to failure? how the aria-describedby technique is far too complex. The capacity for author error is great. Likely errors include but are not limited to:

The potential for confusion is rife especially for ordinary content authors and designers and the result is that accessibility will suffer. In fact even ARIA experts have gotten ID naming wrong and publish incorrect ID examples in the W3C WAI-ARIA 1.0 Authoring Practices specification.

The aria-describedby/hidden technique is complex. Longdesc is easier to understand and put into practice. No evidence has been presented that authors will get aria-describedby correct more often than longdesc.

Cascading Style Sheet Skill Set

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.

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

The repercussions for ordinary authors of HTML5 having to resort to CSS was pointed out on February 19, 2012 in Bug 16026. It states that HTML5 is,

unnecessarily biased towards integration with CSS, and is considerably more complicated and thus incredibly inaccessible to most average casual users of the web.

Hiding long description indicators and descriptions 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 previously explained, 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 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. This technique 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.

Forcing Descriptions on Users is Harmful

Forcing users to listen to long descriptions is an extremely negative and harmful user-experience, as John Foliot has explained

The ability to (mentally and literally) pause, step outside of the page flow to get a description of a complex image (because you cannot see it) and then return to the content flow AT EXACTLY THE SAME PLACE YOU LEFT OFF is a design feature, not a flaw. The key point about @longdesc (for screen readers) is that they are given a *choice* as to whether or not they want to hear what some might consider extraneous data or not - it is the difference between glancing at a sophisticated pie chart (for example) versus studying it. You, as a sighted user, have that choice (to glance or study), yet insisting that the full-on textual description be inserted into the content flow because the user is blind is tantamount to me holding your head in a fixed position and insisting that you explain aloud to me that pie chart before I allow you to continue reading the rest of the page.

@longdesc is about user-choice!

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

As the Association of American Publishers states,

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.

In addition AAP goes on to explain what a confusing user experience this can create,

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.

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. Non-sighted users (using a screen reader that supports longdesc) are presented with a) advice/notification that a longer description is available, and b) the opportunity/choice to either pursue that longer description, or skip past it and continue with the normal page content. This choice is a critical user-requirement.

Structured Markup Facilitates Critical Functionality

Structured markup encodes information about the structural role of elements that in turn enables functional long description content. It is apparent [Jordan, 2006] that,

For accessibility, structural markup is important because software can use structure to perform functions for the user and provide better access to page content. For example, software that reads web pages, such as voicing browsers and screen reader software, can audibly differentiate headings from other text so that the information structure of the page is communicated to non-visual users. In addition, software can provide optional views such as heading lists, which display a list of headings; or heading reading mode, which reads only headings, giving non-visual users a means to quickly skim a document.

Screen readers help their users find and jump to the information that they need more quickly by using keyboard shortcuts for headings, tables, lists etcetera.

JAWS Examples

JAWS (Job Access for Windows and Speech) is a popular screen reader program created by Freedom Scientific that allows people who are blind to gain access to information on their computers. It utilizes structural markup to enable keyboard commands that provide users functionality. The following are some examples.

Headings
Function Keyboard Command
List Headings INSERT+F6
Next Heading H
Prior Heading SHIFT+H
First Heading INSERT+ALT+HOME
Last Heading INSERT+ALT+END
Next Heading at Level 1 through 6
Prior Heading at Level SHIFT+1 through 6
First Heading at Level INSERT+ALT+CTRL+1 through 6
Last Heading at Level INSERT+ALT+CTRL+SHIFT+1 through 6
Paragraphs
Function Keyboard Command
Prior Paragraph CTRL+UP ARROW
Next Paragraph CTRL+DOWN ARROW
Current Paragraph CTRL+NUM PAD 5
Lists and Divisions
Function Keyboard Command
Next List L
Prior List SHIFT+L
Select List F8
List All Ordered, Unordered, and Definition Lists INSERT+CTRL+L
Next Item in a List I
Prior Item in a List SHIFT+I
Next Division Z
Prior Division SHIFT+Z
List Divisions INSERT+CTRL+Z
Elements
Function Keyboard Command
Next Same Element S
Prior Same Element SHIFT+S
Next Different Element D
Prior Different Element SHIFT+D
Move to Beginning of the Current Table, List, or Element WINDOWS Key+HOME
Move to End of the Current Table, List, or Element WINDOWS Key+END
Next Element SHIFT+PERIOD
Prior Element SHIFT+COMMA
Select Entire Element F8
Display Element Information INSERT+SHIFT+F1
Display Detailed Element Information INSERT+CTRL+SHIFT+F1

Key board shortcuts have always provided critical table functionality. In July 2012 JAWS 13 introduced a new simplified layer for navigating tables, which streamlines the process even further. Press and release INSERT+SPACEBAR, followed by T to get to the table layer. Then press any of the following keystrokes.

Tables
Function Keyboard Command
Move by cell ARROW Keys
Move to beginning or end of a column or row CTRL+ARROW
Move to beginning or end of the current row HOME or END
Jump to first cell in a table CTRL+HOME
Jump to last cell in a table CTRL+END
Read the current cell NUM PAD 5
Read the current row SHIFT+UP ARROW
Read from current cell to the end of the row SHIFT+PAGE UP
Read from beginning of the row to the current cell SHIFT+HOME
Read current column SHIFT+NUM PAD 5
Read from the current cell to the bottom of the column SHIFT+PAGE DOWN
Read from the top of the column to the current cell SHIFT+END
Return to the prior table cell WINDOWS Key+J
Move to the next or previous table CTRL+ENTER or CTRL+SHIFT+ENTER
List the keystrokes you can use in this layer QUESTION MARK
Plain String Text Voids This Functionality

Due to the August 13, 2012 Chairs' decision on Issue 204, spec text from Allow ARIA Attributes to Reference Hidden Elements changes HTML5 to state,

...authors SHOULD NOT reference hidden content which would lose essential meaning when flattened.

Even though it can point to structured content such as headings, lists, paragraphs, and tables and the new spec text from the Allow ARIA Attributes to Reference Hidden Elements proposal encourages user agents to expose the full semantics of hidden elements to assistive technology, as implemented aria-describedby/hidden is limited in its ability to process structured content. Accessibility APIs that aria-describedby maps to do not support structured content due to key-binding focus requirements for sighted keyboard users who cannot use a mouse. Sighted keyboard users need to know where their focus is so they do not become disoriented. Focused items need to be visible.

Consequently off-screen controls are not included in the tab order, exposed in the accessibility tree, listed in enumerations of controls (e.g. JAWS link list), or available to skip commands.

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

As the WAI-ARIA 1.0 Authoring Practices explains using aria-describedby to point to a hidden link would be futile because a user would not be able to to navigate to and activate the link:

When the author does not desire the entire descriptive text to be located on the main page, aria-describedby can also be used to point to a link to another page.

<div id="figuretitle">Figure 1-1: Entity Relationship 
  Diagram showing EMP and DEPT
</div>
  <img src="foo" aria-labelledby="figuretitle" 
    aria-describedby="link1">
   <a href="descriptionLocation.html" id="link1">
    Description of Figure 1-1: Entity Relationship 
    Diagram showing EMP and DEPT</a>
</div>

It is not good practice to use the above pattern when the describing elemen - the <a> tag with @id='link1'- is hidden , since there is no way for a user to navigate to and activate the link. Use the technique only when the description is not hidden.

None of this is a problem with longdesc. Longdesc supports structured content. Reading keys and links work.

Examples in the Wild Utilize Structured Markup

Sites in the wild utilize structural markup in long description pages. For instance Aboriginal Affairs and Northern Development Canada, ACCESS-ed: University of Wisconsin - Milwaukee, Accessibilité du Web, Affaires autochtones et Développement du Nord Canada, California Department of Fish and Game, Camera Obscura, Canada's Department of Justice, Canadian Grain Commission, Canadian Space Agency, Centers for Disease Control and Prevention (CDC), Cornell University, Commonwealth of Massachusetts, Connexions, Correctional Service Canada, Courts Administration Service (Canada), CSS Work, CSS Squirrel, Daegu Metropolitan Office of Education (South Korea), Department of Sustainability, Environment, Water, Parcs Canada, Parks Canada, Population and Communities (Australia), Department of Transportation (Taiwan), dizABLED, Elections Canada, Free Technology Academy, Giheung-Gu Yong-in City (South Korea), Graphical Object Server for Non-Visual Interaction (GONVI), Grinning Planet, Hamilton College, Hawaii Public Schools, Health and Safety Executive (UK), Health Resources and Services Administration, Hipocampo, IBM, Immigration and Refugee Board of Canada, IDCnet: Inclusive Design Curriculum Network, Indiana University-Purdue University Indianapolis Common Core Curriculum Committee, Iris Fernandez: BETA Weblog, educación y tecnología en Argentina, Kilkee, County Clare, Ireland, Korea Employment Information Service (South Korea), Kyungpook (South Korea), Local Government Commission, Lusophone countries - Convention on the Rights of Persons with Disabilities (Portuguese), Marine National Park (Taiwan), Mesothelioma Center, Michigan State University, Ministère des Relations internationales - Gouvernement du Quèbec, Monterey County, National Center for the Dissemination of Disability Research, National Institute of Information and Communications Technology (Japan), National Institute of Standards and Technology (NIST) , National Institutes of Health (Canada), National Institutes of Health (United States), National Transportation Safety Board, New Zealand Department of Labor, Northern Ireland Planning Service, Object Description, Office of the Commissioner of Review Tribunals, Ohio Dental Clinics, Ohio Dental Clinics, Ohlone College, Oriental Hospital of Daejeon University (South Korea), PARIS WEB, Province of Gyeongsangbuk (South Korea), Public Safety Canada, Rebuilding The Web,Régie des rentes du Québec, Resources naturelles Canada, Sésame Province de Luxembourg (Belgium), San Diego University, Social Security Online, Specific Claims Tribunal Canada, Special Education Support Center (South Korea), Statistics Canada, Statistique Canada, Texas Comptroller of Accounts, Susan Combs, Texas State Library, Trace Center, Transportation Safety Board of Canada Tribunal des revendications particulières Canada, Transportation Safety Board of Canada, Treasury Board of Canada Secretariat, Reports on Plans and Priorities, U.S. Department of Health and Human Services, Assistant Secretary for Planning and Evaluation, U.S. Department of Transportation Federal Highway Administration, U.S. General Services Administration, U.S. Patent and Trademark Office, U.S. State Department, UK Blind Piano Tuners, Universal Remote Console Consortium, University of Minnesota Duluth, W3C HTML5 Accessibility Bugs, W3C Rich Web Applications Backplane Incubator Group, Web Content Accessibility Guidelines (WCAG), Wrexham County Borough Council (UK), Yasui (Japan), and Zew all use structural markup.

Description Available in a Separate Document Provides Efficiency

One external file provides and controls the description for multiple docs.

Using one global document to provide descriptions for multiple instances of the same image is a powerful, portable, re-usable technique. It provides efficiency and scalability making authoring and maintenance easy wherever instances of the same image are used in multiple locations. It is analogous to the power of external style sheets.

The technique saves time and money by:

Global long descriptions can be applied across multiple sites, or across an entire site, or across a subset of pages, and doing so means that you only need to update one file if you need to make a change.

HTML5 should not unduly obstruct authors in this regard.

As documented by the use cases and evidenced by real world examples a description available in a separate document provides easy reuse of the targeted description from multiple sources (i.e. ability for an image to appear in multiple documents throughout a site or throughout multiple sites or from an HTML email while at the same time linking to one longdesc document).

Other "solutions" such as figcaption, details, and aria-describedby as implemented lack this functionality. They are hamstrung to on-page descriptions.

Examples in the Wild

The CSS Squirrel, SEO Design, the Lambda Theta Phi Latin Fraternity, the Texas State Library, and the University of Minnesota Duluth use images in separate documents that share the same long description page. This technique is key to the logo description use case and the lightbox description use case as evidenced through examples in the wild. Geoff Freed has 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 externally store descriptions to facilitate etext descriptions and describe etext Images.

Of long description techniques, using a separate document is a prevalent design pattern/cowpath with authors who supply descriptions. Less than two-dozen on-page long descriptions via anchor were found out of over two thousand examples in the wild.

Code and User Interface Patterns

The code and UI patterns for how to navigate to an external page with a longdesc are well established (and used for example by JAWS and Opera).

Equal Access to Dual Functionality

Blind users deserve to be afforded a programmatically determinable way to obtain equal access to a long description of content images as well as decorative images whenever an image already has a link which is mapped to another function.

Dual Functionality Provides 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 they deserve the opportunity for an equal experience.

Being 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 SpaceBar, or by mouse click), so that a linked image retains the expected behavior in response to user interaction while a discrete mechanism is used to retrieve the long description provides accommodation for blind users.

This functionality is taken for granted by sighted users as they automatically see what an image looks like while being able to directly access a parent <a> element mapped to a different task.

One Link Cannot Take a User to Two Locations

Attempting to force dual functionality into single functionality is unworkable because it is impossible for one link to take a user to two locations.

ARIA provides no mechanism for separating out what contributes to the accessible description and a navigational link.

Disallowing Equal Access is Unacceptable

Removing the possibility for direct, dual, programmatic access to both a long description and a separate a href on an <img> element would be:

Breaking Backwards Compatibility is an Intolerable Cost

Breaking 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 a replacement for longdesc - for something meant to solve the same problem, is an intolerable cost. It would be an illogical undue burden and unacceptable to authors and organizations that have already made investments in the use of longdesc in terms of tools, content and documentation. All other "solutions" introduce a non-backwards compatible change which negatively affects existing tools, existing content, existing documentation. The vision of HTML5 was to extend the Web without breaking it; evolution rather then revolution.

Existing Tools

Longdesc is implemented in authoring tools, assistive technology, and user agents.

Not everyone can afford to throw away tools to get the newest model. For instance run of the mill content authors/web designers rarely can afford to throw away their WYSIWYG editor to get the newest model. They rely on existing tools to author and test long descriptions. It has been well established that WYSIWYG tools simplify authoring longdesc. An array of tools exists to author longdesc and to check that the longdesc works. Authors rely on tools to test long descriptions. Two browsers (Opera, iCab) natively support longdesc link testing (three if we count Home Page Reader which is currently still in use in Japan). longdesc has a growing arsenal of extensions, configurations, and plugins that are used for testing including Jim Thatcher's powerful long description favelet, which provides universal functionality of longdesc in browsers such as Chrome, FireFox, Internet Explorer, and Safari.

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.

Existing Content

It has been substantially evidenced via the documentation of over two thousand real world examples of longdesc that authors do indeed use longdesc 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.

For an image that is fully accessible and compliant today to suddenly be flagged as non-compliant is counter to the backwards-compatibility and interoperability objectives of HTML5.

For example, during the past year alone, numerous organizations such as the A11y Bugs Project, Aboriginal Affairs and Northern Development Canada, Alienor, Assisted Human Reproduction 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), Cornell University, 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), Immigration and Refugee Board of Canada, Marden Neighbourhood Plan, Marine National Park (Taiwan), Michigan State University, National Center on Birth Defects and Developmental Disabilities, National Institute of Standards and Technology (NIST), National Institute on Drug Abuse, Object Description, Office of the Commissioner of Review Tribunals, 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 , Procréation assistée 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, Transport Canada, Transportation Safety Board of Canada, 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.

Expecting authors to rewrite deployed 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. 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.

Existing Documentation

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.

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.

Gregory J. Rosmaita a longdesc consumer who fully supports this objection document wrote the following to me on August 1, 2012. It is reprinted here with his permission,

ever since i first started working with the W3C, i've been attempting to explain that while a picture may be worth a thousand words, that doesn't mean i want to hear all one-thousand words all at once or at this particular moment... i do, however, absolutely need to know that: 1) the author has inserted an image here, so it is probably relevant to the content (the purpose of "alt"); 2) that there is a long description of the image available should i need/want it; 3) that i can use familiar structural navigational features and commands to obtain the description's contents, with the ability to stop speech and review in detail (i.e. by character) or by structure (i.e. current list item, next list item, list item x out of y) the structured content used to provide the long description; and 4) the confidence that when i am satisfied with the amount of information obtained from the long description, i can and will return to the exact place in the main content from which i initiated exposition of the long description.

longdesc fulfills all my requirements and needs, and i fully support its retention in HTML5.

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 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, Alienor, Assisted Human Reproduction 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), Cornell University, 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, Immigration and Refugee Board of Canada, Kyungpook (South Korea), Marine National Park (Taiwan), Michigan State University, National Center on Birth Defects and Developmental Disabilities, National Institute of Standards and Technology (NIST), National Institute on Drug Abuse, Object Description, Office of the Commissioner of Review Tribunals , 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 , Procréation assistée 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, Transport Canada, Transportation Safety Board of Canada, 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.

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

Long Description Favelet

A longdesc favelet by James Thatcher first announces the number of images on a page that has longdesc attributes. Then it highlights each image on the page that has a longdesc and provides on-screen text links to each corresponding description. It provides universal functionality of longdesc in browsers such as Chrome, FireFox, Internet Explorer, and Safari. For the functional favelet drag longdesc to your bookmarks.

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

On May 5, 2012, HTML Co-Chair, Maciej Stachowiak stated,

if a UA can give a better experience i think they should be encouraged to try

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. It will encouraged to them to improve support. As Anne van Kesteren has said, examples in the specification serve as an incentive to vendors:

It's an incentive to get the software fixed.

Alternative Techniques Are Not Viable

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, aria-describedat, aria-describedby, canvas, figcaption, href, details, iframe, imagemap, or a new HTML attribute are not viable solutions. The following matrix delineates how proposed solutions meet long description requirements.

Requirement and Solution Matrix
Requirement longdesc aria- describedat aria- describedby canvas figcaption href details iframe imagemap New HTML Attr rel
No forced a visual encumbrance Pass Fail [3] Fail Fail Fail Fail Fail Fail Pass Fail [3] Fail
Discoverability tools exist when there is no forced visual encumbrance. Pass Fail [3] Fail Fail Fail Fail Fail Fail Fail Fail [3] Fail
Programmatically ties a set of structured content that is external to the document to an <img> element. Pass Fail [3] Fail Fail Fail Fail [1] Fail Pass Pass Fail [3] Pass
Programmatically determinable when an image already has a link which is mapped to go to another page or a larger image. Pass Fail [3] Pass Fail Pass Fail Pass Pass Fail Fail [3] Fail
Provides easy reuse of the targeted description from multiple sources. Pass Fail [3] Fail Fail Fail Fail [1] Fail Pass Pass Fail [3] Pass
Provides the choice to consume. As currently implemented, the description is not forced upon screen reader users. Pass Fail [3] Fail Fail Fail Fail [1] Fail Unknown [4] Unknown [4] Fail [3] Unknown [4]
Does not require reengineering ARIA. Pass Fail Fail Pass Pass Pass Pass Pass Pass Pass Pass
Is not a bridging technology. Pass Fail Fail Pass Pass Pass Pass Pass Pass Pass Pass
Provides WYSIWYG tool support for authors of limited skill set. Pass Fail [3] Fail Unknown [4] Unknown [4] Pass Unknown [4] Pass Pass Fail Fail
Does not force people to read another large specification. Pass Fail [3] Fail Pass Pass Pass Pass Pass Pass Pass Pass
Provides ease of use. Pass Fail [3] Fail Fail Fail Fail [1] Fail Pass Pass Fail [3] Unknown [4]
Provides ease of authoring. Pass Fail [3] Fail Fail Fail Fail [2a] Fail Fail Fail Fail [3] Unknown [4]
Provides native HTML long description semantics. Pass Fail Fail Fail Fail Fail [2] Fail Fail Fail Fail [3] Pass
Provides backwards compatibility and no need to retrofit. Pass Fail Fail Fail Fail Fail Fail Fail Fail Fail Fail
Is recognized by existing authoring tools, user agents, assistive technologies. Pass Fail Fail Fail Fail Fail Fail Pass Unknown [4] Fail Fail
Numerous tutorials and documentation throughout the world explain how to use this technique for complex image descriptions. Pass Fail Fail Fail Fail Fail Fail Fail Fail Fail Fail
Is law in various countries. Pass Fail Fail Fail Fail Fail Fail Fail Fail Fail Fail
Is a standard in numerous organizations and companies. Pass Fail Fail Fail Fail Fail Fail Fail Fail Fail Fail
Is policy in many organizations and companies in throughout the world. Pass Fail Fail Fail Fail Fail Fail Fail Fail Fail Fail
Is in numerous guidelines throughout the world. Pass Fail Fail Fail Fail Fail Fail Fail Fail Fail Fail
Does not reinvent the wheel. Pass Fail Fail Fail Fail Fail Fail Fail Fail Fail Fail
Provides solutions to all specific use cases. Pass Fail [3] Fail Fail Fail Fail Fail Fail Fail Fail [3] Fail

The only solution that meets all requirements and fulfills all specific use cases is longdesc.

The following information provides further rationale as to why the existence of these techniques does not justify killing off longdesc.

aria-describedat

aria-describedat Status

On March 21, 2012 an unofficial aria-describedat document surfaced. It is a public working draft of a potential specification. aria-describedat has no official standing of any kind and does not represent the support or consensus of any standards organization.

It is unknown if or when specification aria-describedat would be complete. Possible introduction of aria-describedat in a future ARIA version, does not require the abolition of longdesc. Rather, it acknowledges that the idea behind longdesc is good.

aria-describedat Use Cases

No use cases for aria-describedat have been presented that are not already satisfied or could be satisfied by longdesc.

aria-describedat is a Bridging Technology

If aria-describedat ever does becomes an ARIA attribute it would remain a bridging technology.

Shirking off the responsibility of providing long description semantics to ARIA is retrograde. In other words, the premise is entirely backward. ARIA should be used to augment missing native semantics of HTML as necessary, not as an excuse to kill and to replace them. For full rationale please consult the bridging technology section of this document.

aria-describedat Forces a Visual Encumbrance

By default aria-describedat as described in the unofficial/unsupported draft violates the forced visual encumbrance constraint.

Different Authors Have Different Skill Sets

Pitting aria-describedat and longdesc against each other is counter-productive to accessibility. It should not be an either/or situation. 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.

It is recommend [Freedom Scientific 2012 (doc file)] that Web page authors,

read the ARIA best practices guide carefully before adding ARIA markup to their pages.

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 as role="application" removes the screen reader's navigation methods.

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 and binary thinking. It would be discriminatory if only ARIA skilled developers are able to publish an accessible image on the Web.

aria-describedat Lacks Educational Material

No evidence exists that substantial ARIA documentation or tutorials are in place and ready to educate developers. In fact, on June 18, 2011 Paul Irish said,

Most developers have no idea how to implement ARIA. The W3C Primer that looks like a spec is just.. laughable.. not at all appropriate for a web developer audience.

This situation has not changed.

In contrast a longdesc support base already exists in the form of authoring tools, tutorials, books etc. These longdesc support materials will live on.

aria-describedat Lacks Backwards Compatibility

The aria-describedat would be void of all backwards compatibility. It is not:

For further rationale please consult the backwards compatibility section of this document.

aria-describedat has No Examples in the Wild

No examples in the wild of accessible long text alternatives with aria-describedat have been presented.

aria-describedat Lacks Implementations

aria-describedat has no implementations.

aria-describedat Reinvents the Wheel

Attempting to use aria-describedat for long descriptions would reinvent the wheel by duplicating a basic method that has already previously been created.

aria-describedat No Evidence of Improvement

No evidence has been presented that aria-describedat would produce more accessible content for long descriptions than longdesc.

aria-describedby

aria-describedby is a Bridging Technology

Shirking off the responsibility of providing long description semantics to ARIA is retrograde. In other words, the premise is entirely backward. ARIA should be used to augment missing native semantics of HTML as necessary, not as an excuse to kill and to replace them. For full rationale please consult the bridging technology section of this document.

aria-describedby Adds Needless Complexity

No evidence has been presented that authors will get aria-describedby correct more often than longdesc.In fact it is far more verbose and complicated for ordinary authors and designers to author hidden relationships than provide a simple link via a longdesc attribute.

This workaround would be very cumbersome and error prone. No one would want redundant text on-screen, as it would state what is visually evident. So to use aria-describedby, a person would have to write the content, then hide it, and then reference the hidden text with aria-describedby using hidden relationships. That's so burdensome that surely even the most enthusiastic ARIA supporter should realize that the longdesc attribute is far more efficient.

Vlad Alexander thoroughly explains in the article Is ARIA for content doomed to failure? how the aria-describedby technique is far too complex. The capacity for author error is great. Likely errors include but are not limited to:

The potential for confusion is rife especially for ordinary content authors and designers and the result is that accessibility will suffer. In fact even ARIA experts have gotten ID naming wrong and publish incorrect ID examples in the W3C WAI-ARIA 1.0 Authoring Practices specification.

No aria-describedby/hidden tools exist to help authors in this task, whereas authors possess an array of tools to author longdesc and to check that longdesc works in browsers.

The aria-describedby/hidden technique is complex. In contrast longdesc is simple. As Kyle Weems illuminated,

are we going to pretend that using longdesc is difficult? Yes, people may use it wrong without some correction, but simply saying "Hey, put a URL there," is not complex at all

The Association of American Publishers (AAP) concurs. In regard to their production processes and quality assurance the AAP has provided first-hand testimony to the working group stating,

The longdesc attribute is easy to code.

As a rule, the more complex the markup pattern, the more likely authors are to make mistakes when implementing it. We should strive to find the simplest markup pattern that satisfies requirements.

aria-describedby Lacks Ability to Provide Description in a Separate Document
aria-describedby Use Cases

As documented by the use cases and evidenced by real world examples a description available in a separate document provides easy reuse of the targeted description from multiple sources (i.e. ability for an image to appear in multiple documents throughout a site or throughout multiple sites or from an HTML email while at the same time linking to one longdesc document).

The CSS Squirrel, SEO Design, the Lambda Theta Phi Latin Fraternity, the Texas State Library, and the University of Minnesota Duluth use images in separate documents that share the same long description page. This technique is key to the logo description use case as evidenced on numerous sites. Geoff Freed has indicated that professional content producers (such as those involved in the ePub initiative, and the US federally-funded project) are interested and ready to use longdesc to externally store descriptions to facilitate etext descriptions and describe etext Images.

aria-describedby as implemented lacks this direct functionality. It is limited to on-page descriptions. ARIA provides no mechanism for separating out what contributes to the accessible description and a navigational link.

Global control for all instances is a powerful technique. It makes maintenance easy wherever instances of the same image exist in numerous locations. This is akin to the power of external style sheets.

In addition if long descriptions were hamstrung to on-page only, it would add page weight inhibiting performance and slow pages. Longdesc allows for leaner code overall - you only do your http transport on demand, resulting in smaller, faster pages, and reduced bandwidth consumption.

Different Authors Have Different Skill Sets

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.

It is recommend [Freedom Scientific 2012 (doc file)] that Web page authors,

read the ARIA best practices guide carefully before adding ARIA markup to their pages.

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 as role="application" removes the screen reader's navigation methods.

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 and binary thinking. It would be discriminatory if only ARIA skilled developers are able to publish an accessible image on the Web.

aria-describedby Lacks ARIA Educational Material

No evidence exists that substantial ARIA documentation or tutorials are in place and ready to educate developers. In fact, on June 18, 2011 Paul Irish said,

Most developers have no idea how to implement ARIA. The W3C Primer that looks like a spec is just.. laughable.. not at all appropriate for a web developer audience.

This situation has not changed.

In contrast a longdesc support base already exists in the form of authoring tools, tutorials, books etc. These longdesc support materials will live on.

Two-Step Retrieval Instead of One-Step Retrieval with aria-describedby

The effort for users to retrieve a description is significantly and negatively impacted. The Association of American Publishers has provided the working group first-hand testimony on this matter stating,

Since the aria-describedby attribute points to a link or to other content on the same page, its structure implies a two-step process to reach the text alternative. Compared with longdesc, the two step process is more tedious:

  1. The user moves to the object that aria-describedby references
  2. If the object is or contains a link or a button, the user interacts with that object to move to the text alternative.

This means that screen reader users would need to exert double the effort to retrieve an aria-describedby description than they do with longdesc. People with disabilities face some unique challenges and barriers. Doubling their on-task work load is needless and intolerable.

aria-describedby Lacks Support for Structured Text

As previously explained even though it can point to structured content such as bulleted lists and paragraphs as implemented aria-describedby/hidden can only process structured content as string-text. Please refer to Plain String Text Voids This Functionality for further information.

aria-describedby Is Forced Upon Users

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. 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. Non-sighted users (using a screen reader that supports longdesc) is presented with a) advice/notification that a longer description is available, and b) the opportunity/choice to either pursue that longer description, or skip past it and continue with the normal page content. This choice is a critical user-requirement. 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.

aria-describedby Forces a Visual Encumbrance

aria-describedby technique would force a visual encumbrance on sighted users unless additional code (in the form of CSS or hidden) were added in order to hide the visual indicator. This would exacerbate aria-describedby's inherent complexity. Please refer to the Cascading Style Sheets and hidden sections of this document for details of why using these techniques is a bad idea.

aria-describedby Lacks Vendor Support
Authoring Tools

No evidence exists that authoring tools will implement aria-describedby.

Indeed, authoring tool vendor Vlad Alexander has provided first-hand testimony stating,

Authoring tool vendors are likely to find it difficult (or even impossible) to build user-friendly interfaces that use the aria-describedby feature. This is likely to result in confusion and little use of the feature.

He confirmed on July 5, 2011 that,

As an authoring tool vendor, we will not be supporting ARIA for content in XStandard, and I cannot see that many other tool vendors will support it either. Implementing ARIA for content does not make business sense for authoring tool vendors, because the non-technical content authors who buy our tools will find it far too complex to use, and because using ARIA for content does not produce better results than existing accessibility features.

However, Vlad Alexander has envisioned a user friendly longdesc authoring tool. He stated,

As a WYSIWYG developer, I can imagine a user-friendly interface that can encourage not only the use but also correct use of longdesc. I cannot say the same for aria-describedby for images.

As evidenced he has not only envisioned an improved longdesc interface, but he also implemented one.

User Agents

No evidence exists that user agents will implement aria-describedby uniformly and in the manner intended by its designers. For example as tested and reported by Steve Faulkner the

latest versions of NVDA and JAWS used with IE 9 will not announce descriptions unless tabindex=-1 is added to elements such as p, div and span when referenced from aria-describedby or aria-labelledby that reference multiple elements

Firefox 14 attempts to use aria-describedby for long descriptions. As David MacDonald has tested and explained in Firefox 14: long description via link associated using aria-describedby, the aria-describedby attribute is

a poor imitation of Longdesc, not well supported, does very similar thing but not as well, it requires an extra step, and it is a little difficult for the user to return to the original image. They wouldn't know it's opening to a new tab...

That a user agent might attempt to expose a mechanism for navigating to a description doesn't mean authors can safely refer to content that cannot be easily consumed when its structure and semantics are stripped away to plain text.

For all intents and purposes aria-describedby is only suitable for short descriptions. ARIA provides no mechanism for separating out what contributes to the accessible description and a navigational link.

That some UAs might additionally expose a mechanism for navigating to the accessible description doesn't mean you can safely refer to content that cannot be easily consumed when its structure and semantics are stripped away to plain text.

Basically aria-describedby is only suitable for short descriptions. ARIA provides no mechanism for separating out what contributes to the accessible description and a navigational link.

Browser Discoverability for Non-AT Users

No evidence has been presented that any browser makes hidden content referred to by aria-describedby discoverable to those who do not use accessible technology. As Matt Garrish stated [Accessible EPUB 3, February 2012] only persons using accessible technologies will easily find it,

Images present a challenge for a variety of disabilities, and the means of handling them are not new, but HTML5 has added a new barrier in taking away the longdesc attribute for out-of-band descriptions... The problem is that HTML5 doesn't replace these removals with any mechanism(s) to allow the discovery of the same information, instead deferring to the aria-describedby attribute to point to the information (see the scripting section for more on WAIARIA). This attribute however, may make the information even less generally discoverable to the broader accessibility community, as only persons using accessible technologies will easily find it.

Safari is a typical example of a browser that does not make aria-describedby/hidden discoverable to non-AT users. On August 15, 2012 Apple representative Maciej Stachowiak confirmed,

In Safari, aria-describedby (and aria properties in general) are only exposed via output-side assistive technologies.

The fact is that new spec text from the Allow ARIA Attributes to Reference Hidden Elements change proposal changes HTML5 to disallow user agents from rendering hidden content. It states:

User agents should not render elements that have the hidden attribute specified.

In contrast, longdesc has an existing support base (two browsers that natively support it, three if we count Home Page Reader which is currently still in use in Japan). It has a growing arsenal of extensions, configurations, and plugins that enable discoverability and provides the required functionality.

No ARIA features to date have been implemented in a way that can be used by non AT users, this appears to be by design as those who influence implementations believe that ARIA should only affect the 'accessibility layer' not mainstream aspects of content display and behaviour. Ian Hickson has stated,

ARIA is intended to only affect accessibility API mappings (and thus ATs). Features such as alt="", however, are relevant far beyond AT users, for example to text browsers. It would be wrong, therefore, to make solutions that exclusively affect accessibility APIs be a suitable alternative for solutions that are necessary for UAs that do not use accessibility APIs.

Furthermore by specifying UA behavior for longdesc as accomplished by the Include longdesc in HTML5 Change Proposal we uphold the Priority of Constituencies and give all users the benefit of this useful attribute.

aria-describedby Reinvents the Wheel

This proposed replacement for longdesc attempts to duplicate a basic method that has already previously been created.

This proposed replacement is new and more complicated syntax for the same thing, or for a limited subset as it restricts the description to be on the same page.

aria-describedby Lacks Backwards Compatibility

aria-describedby is new. It has no legacy or provenance. Whereas, longdesc has legacy content and legacy support.

Expecting authors to rewrite their content in order to support a technique that (a) does not work for authors or users, (b) reinvents the wheel, (c) lacks vendor support, (d) attempts to obsolete vital core host language semantics with a bridging technology, and (e) is simply a cumbersome "hack", is nonsensical and totally unrealistic : such attempts will serve only to infuriate and alienate both those authors and the accessibility community as a whole.

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 copious array of books, 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

aria-describedby Retrofitting Problem

Any proposed solution should be easy for authors who are already publishing content with longdesc to retrofit their existing pages. aria-describedby possesses a radically different, inherently complex, two-step authoring pattern than longdesc. Because of this, as well as its on-page limitations, retrofitting with aria-describedby would be difficult, labor intensive, and error prone. No retrofitting is required for longdesc as it is an existing HTML feature not a new one.

aria-describedby No Examples in the Wild

No examples in the wild of accessible long text alternatives with aria-describedby have been presented for any of the use cases. No evidence exists that authors have or will use it for accessible long text alternatives.

No Evidence of Improvement with aria-describedby

No evidence has been presented that aria-describedby produces more accessible content for long descriptions than longdesc or that more authors would use it correctly. It is an inferior long description solution possessing no benefits over longdesc.

The longdesc attribute possesses the ability to provide both on-page and off-page descriptions while retaining all rich content in the long description. It does not force itself upon users. The longdesc attribute unequivocally and directly provides native semantics and critical backwards compatibility.

canvas

canvas is an Illogical Long Description Technique

Authors are not going to think about canvas when they want to use a complex image. If they want to use an image they will simply use img.

It is illogical to require img to be encased in canvas in order to provide a long description.

canvas Long Description Semantics

Semantic elements and attributes improve communication. For details please consult the semantics section of this document.

The semantics of canvas element does not provide a clear, direct, explicit, and strong semantic for an image long description.

canvas Adds Needless Complexity

Requiring canvas to supply long descriptions would introduce needless complexity.

This in turn would make it more prone to authoring error as complexity confuses and leads to errors. longdesc is a simple link - no coordinates to figure out.

Overloads canvas

canvas overloads fallback content.

No canvas Examples in the Wild

No examples in the wild of accessible long text alternatives with canvas have been presented for any of the use cases. No evidence exists that authors have or will use this technique.

canvas Lacks Educational Material

No tutorials, books, or documentation exists that explain to authors how to make an accessible long text alternative with canvas.

No Evidence of Improvement with canvas

No evidence has been presented that canvas produces more accessible content for long descriptions than longdesc or that more authors would use it correctly.

canvas Lacks Backwards Compatibility

Any canvas technique for long descriptions lacks backwards compatibility. It is not:

For further rationale please consult the backwards compatibility section of this document.

canvas Retrofitting Problem

Any proposed solution should be easy for authors who are already publishing content with longdesc to retrofit their existing pages. canvas possesses a radically different, authoring pattern than longdesc. Because of this, retrofitting with canvas would be difficult. No retrofitting is required for longdesc as it is an existing HTML feature.

Cascading Style Sheets

Cascading Style Sheets (CSS) have been suggested as a solution for hiding long description indicators or long description content. This suggestion:

Violates Search Engine Guidelines

Search engines do not seem to leave any room for text that is hidden (or off screen) for good reasons like long descriptions.

Google's guideline on hidden text states:

If you do find hidden text or links on your site, either remove them or, if they are relevant for your site's visitors, make them easily viewable. If your site has been removed from our search results ... Once you've made your changes and are confident that your site no longer violates our guidelines, submit your site for reconsideration..

The penalty for a site using hidden text may be removed from the Google index, and will not appear in search results pages.

Yahoo!'s search engine has a similar content quality guideline:

...examples of the types of content that Yahoo! does not want included...The use of text or links that are hidden from the user...

Long descriptions that utilize the longdesc attribute have no such search engine penalties imposed. longdesc is a simple link.

CSS Adds Needless Complexity, Page Weight, and Inconsistency

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.

Different CSS techniques for hiding have very different results. Elements styled with "display:none" or "visibility:hidden" are not included in the accessibility tree. They are always hidden from screen readers and browsers. [McCathieNevile 2012 test case]

However, other declarations for hiding such as "left: -9999px; top: -9999px;" is rendered to screen reader users just as any other currently visually visible element on the screen is but it is stripped of all interactivity and semantic structure.

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

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. 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. As Marco Zehe recently stated,

Elements styled with "display:none" or "visibility:hidden" are always hidden from screen readers as well. This is true for screen readers on Windows like NVDA or JAWS, and has been so for at least the last ~7 years. Orca on Linux, VoiceOver on OS X and iOS also adhere to this rule. JAWS has consistently supported this since version 7, which was released in 2005. All other screen readers I know do this right, too, and have been for ages. Why this rumor that one can provide extra content to screen readers via elements styled with "display:none" keeps sticking around, I have no clue. It is definitely wrong! Screen readers completely ignore elements styled with "display:none" or "visibility:hidden;" .

Daegu Metropolitan Office of Education is an example of an organization mistakenly using this technique. Fortunately they also used longdesc, which does work.

The Paciello Group recently illuminated various techniques to hide content. They detail the correct technique to hide interactive (focusable) content from visible display with CSS, but still have it in the tab order. As stated,

Focusable content should only be hidden from visible display if the focusable element becomes visible when it receives focus:

Example code:

a.offscreen
{position:absolute;
left:-10000px;
top:auto;
width:1px;
height:1px;
overflow:hidden;}
 
a.offscreen:focus 
{position:relative; 
left:0px; 
width:auto; 
height:auto; 
overflow:auto; 
}

This technique is required to correctly hide long descriptions that contain interactivity and semantic structure. The two sister sites Statistics Canada and Statistique Canada are examples of an organization that incorrectly use positioning off screen position: absolute; top: -100px without a focus technique for interactive semantic content. Fortunately they also used longdesc, which preserves all interactivity and semantic structure.

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 authors hide long description indicators/link text with 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.

Structure is Stripped From Hidden Content Referenced by ARIA

As explained, structured markup facilitates critical functionality.

Due to the August 13, 2012 Chairs' decision on Issue 204, spec text from Allow ARIA Attributes to Reference Hidden Elements changes HTML5 to state,

...authors SHOULD NOT reference hidden content which would lose essential meaning when flattened.

Even though it can point to structured content such as headings, lists, paragraphs, and tables and the new spec text from the Allow ARIA Attributes to Reference Hidden Elements proposal encourages user agents to expose the full semantics of hidden elements to assistive technology, as implemented aria-describedby/hidden is limited in its ability to process structured content. Accessibility APIs that aria-describedby maps to do not support structured content due to key-binding focus requirements for sighted keyboard users who cannot use a mouse. Sighted keyboard users need to know where their focus is so they do not become disoriented. Focused items need to be visible.

Consequently off-screen controls are not included in the tab order, exposed in the accessibility tree, listed in enumerations of controls (e.g. JAWS link list), or available to skip commands.

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

As the WAI-ARIA 1.0 Authoring Practices explains using aria-describedby to point to a hidden link would be futile because a user would not be able to to navigate to and activate the link:

When the author does not desire the entire descriptive text to be located on the main page, aria-describedby can also be used to point to a link to another page.

<div id="figuretitle">Figure 1-1: Entity Relationship 
  Diagram showing EMP and DEPT
</div>
  <img src="foo" aria-labelledby="figuretitle" 
    aria-describedby="link1">
   <a href="descriptionLocation.html" id="link1">
    Description of Figure 1-1: Entity Relationship 
    Diagram showing EMP and DEPT</a>
</div>

It is not good practice to use the above pattern when the describing elemen - the <a> tag with @id='link1'- is hidden , since there is no way for a user to navigate to and activate the link. Use the technique only when the description is not hidden.

None of this is a problem with longdesc. Longdesc supports structured content. Reading keys and links work.

No Evidence of Improvement with CSS

No evidence has been presented that using Cascading Style Sheets (CSS) to hide long description indicators or long description content produces more accessible content for long descriptions or that more authors would use it correctly.

figcaption

Incorrect figcaption Semantics

Semantic elements and attributes provide a higher level of communication. While a figcaption can be used as a valid replacement for alt to supply a context dependant caption of an image constrained to being inside of a figure, it does not provide an explicit, and strong semantic for an image long description. Terse and verbose descriptors differ. As Gregory J. Rosmaita aptly explained,

alt text is the brief "at a glance" or "cognative thumbnail"... alt text needs to be terse for a number of reasons, including usability, extremely limited viewports, small amount of video "real estate" (iPad and smaller devices) etc.

The prevailing rationale for keeping figure/figcaption change proposal stated, that figcaption was not a long description but rather a short description:

The figcaption element exposes a short description of the figcaption content, which may be read out to help a user determine if they wish to look at the content of figcaption now or later.

figcaption Lacks Support

With the one exception of Firefox on Windows figcaption is not accessibility supported semantics wise. HTML5 accessibility states that it,

provides the same amount of semantic information to AT as a div element.

figcaption Forces a Visual Encumbrance

The figcaption technique would force a visual encumbrance on sighted users unless additional code (in the form of CSS or hidden) were added in order to hide the visual indicator. Please refer to the Cascading Style Sheets and hidden sections of this document for details of why using these techniques is a bad idea.

figcaption Lacks Ability to Provide Description in a Separate Document

The figcaption technique lacks the key functional requirement of providing a long description in a separate document.

figcaption Reinvents the Wheel

Attempting to use figcaption to provide a long description reinvents the wheel by duplicating a basic method that has already previously been created.

No use cases of figcaption for a long description has been presented that are not already satisfied by longdesc.

figcaption Lacks Educational Material

No tutorials, books, or documentation exists that explain to authors how to make an accessible long text alternative with figcaption.

No Examples in the Wild for figcaption

No examples in the wild of accessible long text alternatives with figcaption have been presented for any of the use cases. No evidence exists that authors have or will use it for accessible long text alternatives.

figcaption Lacks Backwards Compatibility

The figcaption technique lacks all backwards compatibility. It is not:

For further rationale please consult the backwards compatibility section of this document.

figcaption Retrofitting Problem

Any proposed solution should be easy for authors who are already publishing content with longdesc to retrofit their existing pages. figcaption possesses a radically different authoring pattern than longdesc. Because of this as well as its on-page limitations, retrofitting with figcaption would be difficult, labor intensive, and error prone. No retrofitting is required for longdesc as it is an existing HTML feature.

No Evidence of Improvement with figcaption

No evidence has been presented that figcaption produces more accessible content for long descriptions than longdesc or that more authors would use it correctly.

hidden

The hidden attribute has been suggested as a solution to hide descriptions.

Users Who Do Not Use Assistive Technology

Some people may want or need to consume long description content that doesn't force a visual encumbrance but do not use assistive technology (AT). The following sighted people may be aided by access to a longdesc:

No Discoverability Specified for hidden

The hidden technique is void of any discoverability specification and shuts out all people who do not use AT but who do want or need access to the description.

As Microsoft stated May 24, 2012,

exposing the content of a hidden referenced element *only* in the accessibility tree, without any UI, is a bad user experience.

In contrast the Include longdesc in HTML5 change proposal provides a solution to the forced visual encumbrance constraint while specifying mainstream discoverability functionality for all who want access to the description.

No Discoverability Tools for hidden

No discoverability tools exist for hidden. No browser vendor has said that this situation will change. In fact with regard to discoverability Apple representative and HTML Co-Chair Maciej Stachowiak explained Apple's aria-describedby/hidden implementation,

I don't think a mouth-stick user who is not visually impaired would ever be exposed to the link, because they would not have access to the description. At least in Safari, aria-describedby is only ever exposed via output-side assistive technologies. If we implemented the "encouraged" behavior, I would not expect that to change.

He further clarified Apple's position,

To be clear, here is what I would expect us to do, if we were to implement the "encouraged" rich semantics functionality in WebKit.

(1) Sighted user, using either keyboard or pointing device to manipulate the content, and with no screen reader or assistive technology running:
- The aria-describedby description would not be exposed to such a user at all. They would neither see it nor be able to tab into it.

(2) Same as #1, but using a custom input accommodation, such as a mouth-stick or sticky keys.
- Same experience as #1 - the description is not exposed at all.

Maciej then tested the following markup and reported,

<img alt="the reddit logo" 
 aria-describedby="hidden-link"
 src="http://d.thumbs.redditmedia.com/-6cwonBxQa40zpxo.png">
 <span hidden id="hidden-link">The 
   <a href="http://reddit.com/">reddit
   </a> logo, showing the reddit alien mascot.
 </span>

(1) For a sighted user using the keyboard (or other alternative input):
- The image shows up, and none of the associated text is read out loud, and the link is not in the tab cycle.

aria-describedby/hidden fails the discoverability constraint.

In contrast discoverability tools exist for longdesc. Sighted authors, people with cognitive or visual impairment, and others use these tools. 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.

Tools to provide a visual user interface for other users (i.e., people with motor disabilities, low vision, authors etc.) to interact with or test hidden content are nonexistent.

Structure is Stripped From Hidden Content

As explained, structured markup facilitates critical functionality.

Due to the August 13, 2012 Chairs' decision on Issue 204, spec text from Allow ARIA Attributes to Reference Hidden Elements changes HTML5 to state,

...authors SHOULD NOT reference hidden content which would lose essential meaning when flattened.

Even though it can point to structured content such as headings, lists, paragraphs, and tables and the new spec text from the Allow ARIA Attributes to Reference Hidden Elements proposal encourages user agents to expose the full semantics of hidden elements to assistive technology, as implemented aria-describedby/hidden is limited in its ability to process structured content. Accessibility APIs that aria-describedby maps to do not support structured content due to key-binding focus requirements for sighted keyboard users who cannot use a mouse. Sighted keyboard users need to know where their focus is so they do not become disoriented. Focused items need to be visible.

Consequently off-screen controls are not included in the tab order, exposed in the accessibility tree, listed in enumerations of controls (e.g. JAWS link list), or available to skip commands.

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

As the WAI-ARIA 1.0 Authoring Practices explains using aria-describedby to point to a hidden link would be futile because a user would not be able to to navigate to and activate the link:

When the author does not desire the entire descriptive text to be located on the main page, aria-describedby can also be used to point to a link to another page.

<div id="figuretitle">Figure 1-1: Entity Relationship 
  Diagram showing EMP and DEPT
</div>
  <img src="foo" aria-labelledby="figuretitle" 
    aria-describedby="link1">
   <a href="descriptionLocation.html" id="link1">
    Description of Figure 1-1: Entity Relationship 
    Diagram showing EMP and DEPT</a>
</div>

It is not good practice to use the above pattern when the describing element - the <a> tag with @id='link1'- is hidden , since there is no way for a user to navigate to and activate the link. Use the technique only when the description is not hidden.

None of this is a problem with longdesc. Longdesc supports structured content. Reading keys and links work.

No Accessible Object Representing the Text Description is Exposed in the Accessibility API

As Richard Schwerdtfeger has said,

text is loaded into the accessible description string in an accessible object even though no accessible object representing the text description is exposed in the accessibility API.

hidden is Hidden From its Target Audience

Most common screen readers in use today will ignore elements that have been hidden using the display:none; declaration. When material is hidden from visual display on a screen in this manner, it is hidden it from screen readers. As Roger Johansson explained,

Setting an element's display CSS property to none makes it completely invisible. It doesn't generate a box, it doesn't take up any place, it doesn't affect the layout. display:none hides the element - and its descendants - visually, and it also hides the element from screen readers.

In both Gecko-based (Firefox, Seamonkey, ...) and Webkit-based (Safari, ...) browsers the hidden attribute is implemented by applying CSS display:none. The The Paciello Group recently illuminated HTML5 hidden effects,

HTML5 hidden effects:

  • In supporting browsers the content is not displayed to any user.
  • semantic indicator of state in HTML code (hidden attribute)
  • CSS style of display:none applied by browser.
  • Focusable content is not included in tab order.
  • Not included in the accessibility tree.

This means that the long description using the proposed hidden technique would be hidden from its target audience.

hidden Violates Search Engine Guidelines

Search engines do not seem to leave any room for text that is hidden (or off screen) for good reasons like long descriptions.

Google's guideline on hidden text states:

If you do find hidden text or links on your site, either remove them or, if they are relevant for your site's visitors, make them easily viewable. If your site has been removed from our search results ... Once you've made your changes and are confident that your site no longer violates our guidelines, submit your site for reconsideration..

The penalty for a site using hidden text may be removed from the Google index, and will not appear in search results pages.

Yahoo!'s search engine has a similar content quality guideline:

...examples of the types of content that Yahoo! does not want included...The use of text or links that are hidden from the user...

Long descriptions that utilize the longdesc attribute have no such search engine penalties imposed. longdesc is a simple link.

No Authoring Tools exist for hidden

No authoring tools for hidden exist to allow authors to create and test long descriptions.

Without WYSIWYG authoring tools run of the mill content authors/web designers authors would be disenfranchised. They rely on tools to author and test long descriptions.

It has been well established that numerous WYSIWYG web designer authoring tools support longdesc. An array of tools exist to author longdesc and to check that the longdesc works.

Authors also rely on tools to test long descriptions. Two browsers (Opera and iCab) natively support this testing (three if we count Home Page Reader which is currently still in use in Japan). longdesc has a growing arsenal of extensions, configurations, and plugins that are used for testing.

hidden is a Confusing and Complex Technique

Due to the August 13, 2012 Chairs' decision on Issue 204, spec text from Allow ARIA Attributes to Reference Hidden Elements will be applied to HTML5. This causes confusion as the specification states:

The hidden attribute must not be used to hide content that could legitimately be shown in another presentation...

It goes on to say:

if something is marked hidden, it is hidden from all presentations, including, for instance, screen readers...

Now Issue 204 introduces a paradox as hidden doesn't mean hidden anymore. A new addition to the spec states:

It would be fine, however, to use the ARIA aria-describedby attribute to refer to descriptions that are themselves hidden. While hiding the descriptions implies that they are not useful alone, they could be written in such a way that they are useful in the specific context of being referenced from the images that they describe.

Although the new aria-describedby paragraph could provide some highly skilled ARIA developers a limited technique, it is ambiguous.

The spec text explicitly says that hidden must not be used to hide content. Then it turns around and asserts it is okay to use it with aria-describedby to point to hidden content.

Possessing more than one possible meaning inherently causes uncertainty. It is error prone, and would be difficult to comprehend and put into practice especially for novice or run of the mill content authors. Author error will increase exponentially especially when combined with identified aria-describedby problems.

In contrast longdesc is simple and does not require a hidden hack.

No hidden Examples in the Wild

No examples in the wild of accessible long text alternatives with hidden have been presented for any of the use cases.

hidden Lacks Backwards Compatibility

The hidden technique is new. It lacks all backwards compatibility. It is not:

hidden Retrofitting Problem

Any proposed solution should be easy for authors who are already publishing content with longdesc to retrofit their existing pages. Because of hidden's inherent complexity retrofitting would be difficult, labor intensive, and error prone. No retrofitting is required for longdesc as it is an existing HTML feature.

No Evidence of Improvement with hidden

No evidence has been presented that hidden produces accessible content for long descriptions or that more authors would use it correctly.

a href

a href Semantics

Semantic elements and attributes improve communication. For details please consult the semantics section of this document.

The semantics of an href does not provide a clear, direct, explicit, and strong semantic for a long description.

a href Not Programmatic Determinable

Programmatic determinability aids accessibility.

A normal link below or near an image or in another part of the document is not programmatically determinable. Without programmatically determinability no explicit relationship exists to indicate that a long description has anything to do with an image.

Impossible for One Link to Have Two Destinations

The fact is a href only works on a limited subset of use cases as it is impossible for one link to take a user to two locations. An href 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 on the web that need long descriptions not to have a parent <a> element mapped to a different task unrelated to a long description is unrealistic, i.e., a thumbnail <img> that links to a larger .jpg as evidenced by National Institute of Dental and Craniofacial Research.

a href Forces a Visual Encumbrance

An href forces a visual encumbrance on sighted users unless additional code (in the form of CSS or hidden) were added in order to hide the visual indicator. Please refer to the Cascading Style Sheets and hidden sections of this document for details of why using these techniques is a bad idea.

No Evidence of Improvement with a href

No evidence has been presented that an href produces more accessible content for long descriptions.

iframe

Incorrect Semantics

Semantic elements and attributes improve communication. For details please consult the semantics section of this document.

The semantics of an iframe does not provide a clear, direct, explicit, and strong semantic for an image long description. An iframe provides a generic link.

Forces a Visual Encumbrance

The iframe technique would force a visual encumbrance on sighted users unless additional code (in the form of CSS or hidden) were added. Please refer to Cascading Style Sheets and hidden for details of why using these techniques are a bad idea.

An iframe using CSS or hidden Lacks Discoverability

Allowing for discoverability serves other use cases.

Adds Needless Complexity

Using an iframe to supply long descriptions would introduce needless complexity. Complexity confuses and leads to errors.

longdesc is a simple link.

Reinvents the Wheel

Attempting to use iframe to provide a long description reinvents the wheel by duplicating a basic method that has already previously been created.

No use cases of iframe for a long description has been presented that are not already satisfied by longdesc.

Lacks Educational Material

No tutorials, books, or documentation exists that explain to authors how to make an accessible long text alternative with iframe.

No Examples in the Wild

No examples in the wild of accessible long text alternatives with iframe have been presented for any of the use cases. No evidence exists that authors have or will use it for accessible long text alternatives.

Lacks Backwards Compatibility

The iframe technique lacks backwards compatibility. For further rationale please consult the backwards compatibility document.

Retrofitting Problem

Any proposed solution should be easy for authors who are already publishing content with longdesc to retrofit their existing pages. Retrofitting with iframe would be difficult, labor intensive, and error prone.

No retrofitting is required for longdesc.

No Evidence of Improvement

No evidence has been presented that iframe produces more accessible content for long descriptions than longdesc or that more authors would use it correctly.

imagemap

imagemap is an Illogical Technique

Authors are not going to think about image maps when they want to use a complex image. If they want to use an image they will simply use img.

It is illogical to require img to be encased in an imagemap in order to provide a long description.

imagemap Semantics

Semantic elements and attributes improve communication. For details please consult the semantics section of this document.

The semantics of an imagemap href does not provide a clear, direct, explicit, and strong semantic for an image long description. An imagemap href is a generic link.

imagemap Adds Needless Complexity

Requiring image maps to supply long descriptions would introduce needless complexity.

This in turn would make it more prone to authoring error as complexity confuses and leads to errors. longdesc is a simple link - no coordinates to figure out.

imagemap Programmatic Determinability

Programmatic determinability aids accessibility.

For a long text alternative provided through a link in an image map to be exposed to assistive technology programmatically would require a special marking on one area, such as a longdesc boolean attribute.

Impossible for One Link to Have Two Destinations

Overloading the mechanism of image maps with that of providing long text alternatives clashes in the case that you need both, an image map and a long text alternative.

The fact is image map syntax only works on a limited subset of use cases. It is impossible for one link to take a user to two locations. It 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 images that need long descriptions to not have a different task unrelated to a long description is unrealistic. Attempting to force dual functionality into single functionality is unworkable.

No imagemap Examples in the Wild

No examples in the wild of accessible long text alternatives with an imagemap have been presented for any of the use cases. No evidence exists that authors have or will use for accessible long text alternatives.

imagemap Retrofitting Problem

Any proposed solution should be easy for authors who are already publishing content with longdesc to retrofit their existing pages. imagemap possesses a radically different authoring pattern than longdesc. Because of this, retrofitting with imagemap would be difficult, labor intensive, and error prone.

No long description imagemap Educational Material

No tutorials, books, or documentation has been presented that explains to authors how to make an accessible long text alternative with an imagemap href.

No Evidence of Improvement with imagemap

No evidence has been presented that an imagemap produces more accessible content for long descriptions than longdesc or that more authors would use it correctly.

New HTML Attribute

New HTML Attribute Status

Creating a new HTML attribute could possibility rectify HTML5's failure of not providing native longdesc functionality and semantics.

Bug 10455 was filed on August 26, 2010 to create a new HTML attribute. Since then some discussion of introducing a new long description attribute has occurred.

However, to date nothing has been specified. Nothing has been implemented.

New HTML Attribute Reinvents the Wheel

Specifying a new element for long descriptions would reinvent the wheel by duplicating a basic method that has already previously been created.

No Evidence of Improvement with a new HTML Attribute

No evidence has been presented that a new attribute would produce more accessible than longdesc.

Use Cases for a new HTML Attribute

No use cases have been articulated or presented that are not already satisfied or could be satisfied by longdesc.

No Examples in the Wild for a new HTML Attribute

No examples in the wild have been presented of a new long description attribute.

A new HTML Attribute Lacks Vendor Support
No Authoring Tools and a new HTML Attribute

No evidence exists that authoring tools would implement a new attribute.

User Agents and a new HTML Attribute

No evidence exists that user agents would implement a new attribute or in a manner intended by its designers.

A New HTML Attribute Lacks Educational Material

No evidence exists that substantial documentation or tutorials are in place and ready to educate developers for a new attribute.

In contrast a longdesc support base already exists in the form of authoring tools, tutorials, books etc. These longdesc support materials will live on.

A New HTML Attribute Lacks Backwards Compatibility

A new attribute would be void of all backwards compatibility. It would not:

For further rationale please consult the backwards compatibility section of this document.

rel="longdesc"

rel="longdesc" Semantics

Semantic elements and attributes provide a higher level of communication. The semantics of an a href alone does not provide a clear, direct, explicit, and strong semantic for an image long description. An a href is a generic link. It is not an explicit link to a long description. Adding rel="longdesc" would provide explicit semantics. However, this technique is riddled with problems.

Impossible for One Link to Have Two Destinations
rel="longdesc" Use Cases

No use cases of rel="longdesc" have been presented that are not already satisfied by longdesc. Whereas use cases for longdesc have been presented that are not satisfied by rel="longdesc".

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.

rel="longdesc" Forces a Visual Encumbrance

rel="longdesc" fails because a href forces a visual encumbrance on sighted users unless additional code (in the form of CSS or hidden) were added in order to hide the visual indicator. Please refer to the Cascading Style Sheets and hidden sections of this document for details of why using these techniques is a bad idea.

rel="longdesc" Reinvents the Wheel

rel="longdesc" attempts to reinvent the wheel by duplicating a basic method that has already previously been created. This proposed replacement is new syntax for the same thing, or for a limited subset as It is impossible for one link to have two destinations.

No Examples in the Wild for rel="longdesc"

No examples in the wild of accessible long text alternatives with rel="longdesc" have been presented for any of the use cases. No evidence exists that authors have or will use it for accessible long text alternatives.

No Improvement with rel="longdesc"

No evidence has been presented that rel="longdesc" produces more accessible content for long descriptions than longdesc or that more authors would use it correctly.

No Implementations exist for rel="longdesc"

No user agent takes advantage of rel="longdesc" semantics. None inform users that a rel="longdesc" link leads to a description page.

No evidence exists that authoring tools will implement rel="longdesc".

In contrast user agents that support longdesc differentiate between longdesc and an a href. Moreover the new spec text for the rendering section will help even more user agents do so.

rel="longdesc" Lacks Backwards Compatibility

rel="longdesc" is new. It has no legacy or provenance. Whereas, longdesc has legacy content and legacy support. It lacks all backwards compatibility. It is not:

For further rationale please consult the backwards compatibility section of this document.

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

summary/details

summary/details Semantically Incorrect

Semantic elements and attributes provide a higher level of communication. The semantics of summary/details does not provide an explicit and strong semantic for an image long description. This technique provides incorrect semantics for long descriptions of images. The HTML specification states,

The summary element represents a summary, caption, or legend for the rest of the contents of the summary element's parent details element, if any.

An img element isn't a summary, caption, or legend. An img element is an image. An image and a long description are peers: the same thing expressed in two different mediums.

summary/details Forces a Visual Encumbrance

The summary/details technique would force a visual encumbrance on sighted users unless additional code (in the form of CSS or hidden) were added in order to hide the visual indicator. Please refer to the Cascading Style Sheets and hidden sections of this document for details of why using these techniques is a bad idea.

summary/details Lacks Ability to Provide Description in a Separate Document

The summary/details technique lacks the key functional requirement of providing a long description in a separate document.

summary/details Assistive Technology Support Support

summary/details is not accessibility supported semantics wise. HTML5 accessibility states that this technique,

Currently provides the same amount of semantic information to AT as a div element.

summary/details Lacks Backwards Compatibility

The summary/details technique for long descriptions lacks backwards compatibility. It is not:

For further rationale please consult the backwards compatibility section of this document.

summary/details Retrofitting Problem

Any proposed solution should be easy for authors who are already publishing content with longdesc to retrofit their existing pages. summary/details possesses a radically different authoring pattern than longdesc. Because of this as well as its on-page limitations, retrofitting with summary/details would be difficult, labor intensive, and error prone. No retrofitting is required for longdesc as it is an existing HTML feature.

No Examples in the Wild exist for summary/details

No examples in the wild of accessible long text alternatives with summary/details have been presented for any of the use cases. No evidence exists that authors have or will use for accessible long text alternatives.

No Evidence of Improvement with summary/details

No evidence has been presented that summary/details produces more accessible content for long descriptions than longdesc or that more authors would use it correctly.

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
  • AccessAbility
  • Accessibilité du Web
  • Accessibility Task Force Bug Comparisons
  • Alienor
  • Assisted Human Reproduction Canada
  • Axel Schäfer, SPD Abgeordneter im Deutschen Bundestag für Bochum
  • Cornell University
  • Camera Obscura
  • Center for the Study of Religion and American Culture
  • Commonwealth of Massachusetts
  • Conseil supérieur de la langue française
  • CSS Squirrel
  • Dhammadana
  • dizABLED
  • easyALBUM
  • Environment Canada
  • Federal Motor Carrier Safety Administration
  • Financial Transactions and Reports Analysis Centre of Canada
  • Grinning Planet
  • Hawaii Public Schools
  • Indiana University-Purdue University Indianapolis Common Core Curriculum
  • Interacciones
  • Korea Employment Information Service
  • Kyungpook (South Korea) Michigan State University National Institute of Information and Communications Technology
  • National Adult Literacy Database
  • National Institute of Dental and Craniofacial Research
  • National Institutes of Health
  • National Institute of Standards and Technology (NIST)
  • Natural Resources Canada
  • nota-ben
  • Object Description
  • Oracle
  • Paris Web
  • Procréation assistée Canada
  • Public Service Commission of Canada
  • Rebuilding the Web
  • Régie des rentes du Québec
  • Research and Innovative Technology Administration / US Department of Transportation
  • San Diego University
  • Santa Barbara Public Library
  • Securian
  • SIGBerrien Metal Products, Inc.
  • Snowdon Award Scheme
  • South West Institute of TAFE
  • SPD Abgeordneter im Deutschen Bundestag für Bochum
  • Statistics Canada
  • Statistique Canada
  • State of California
  • tech.burningbird
  • Texas State Library
  • The Organisation Development Company
  • U.S. Department of Health and Human Services
  • University of Minnesota Duluth
  • 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.

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.

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.

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:

  • AccessAbility SIG
  • Berrien Metal Products, Inc.
  • Center for the Study of Religion and American Culture
  • Hamilton College
  • 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 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 is not viable, please consult the aria-describedby section of this document 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.

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 is not viable, please consult the aria-describedby section of this document 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

As explained longdesc is perceivable.

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 is not viable, please consult the aria-describedby section of this document 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.

  • Accessibility Task Force Bug Comparisons
  • Accessibilité du Web
  • Assisted Human Reproduction Canada
  • 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
  • Procréation assistée 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

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:

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

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 is not viable, please consult the aria-describedby section of this document 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.

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

Author Skill Sets Differ

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

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 is not viable, please consult the aria-describedby section of this document 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:

  • 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

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.

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.

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 is not viable, please consult the aria-describedby section of this document 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.

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 use it and depend on it to provide 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 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 fulfills 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 this proposal. It would be an unnecessary atrocity on authors and users with disabilities.

Notes

[1] Fails whenever link is used for another function. And it is not automatically announced to users of screen readers like JAWS, SuperNova/Hal or WindowEyes that a long description is available.

[2] Fails because link semantics are already well-defined.

[2a] To provide proper semantics rel="longdesc" would be needed. But rel="longdesc" is not implemented by existing tools.

[3] This proposed solution fails as it is neither formally specified or nor implemented.

[4] Unknown. No evidence presented.