Objection to the Proposal: Keep the longdesc attribute for the img element deprecated

Summary

I object to this proposal because it is misleading and fails to meet requirements. It does not fulfill use cases. "Hacking" away with aria-describedby and hidden is a retrograde "solution" that doesn't work in practice for authors or users. It reinvents the wheel, lacks vendor support, and backwards compatibility. It attempts to obsolete vital core host language semantics with a bridging technology.

Misleading

This proposal is misleading. It is titled "Keep the longdesc attribute for the img element deprecated". However, it does not deprecate longdesc. It obsoletes it entirely. The concept "deprecate" does not exist in HTML5.

According to the HTML5 specification obsolete features must not be used by authors. Obsolete features trigger errors. An error for a proper longdesc is simply wrong. People should not be reprimanded for doing the right thing. On the contrary, they should be applauded.

Incremental renovation and improvement is more productive than "bulldozing" a feature flat.

Fails Requirements

aria-describedby fails to meet long description requirements. Among those requirements are:

In particular the following problems make this proposal a non-starter.

No Evidence of Use Case Fulfillment

No evidence exists that aria-describedby satisfies the use cases.

Does Not Work for Authors

Not Being Displayed Visually is a Key Designer Requirement

The history of longdesc goes back to a time when designers (not engineers) expressed a need to provide the functionality that non-sighted users required, without it impacting the visual design of their page/content. The reason for the creation of longdesc in the first place was that designers wanted a means to ensure longer descriptions could be provided without having a visual encumbrance on their page. The longdesc attribute was developed to address this designer need, based on designer feedback.

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.

It is appreciated that this proposal acknowledges and attempts to address this requirement.

However, not only do serious problems with pointing inside hidden elements exist but also no evidence has been presented that WYSIWYG authoring tools support the proposed aria-describedby/hidden technique. It has been well established that numerous WYSIWYG web designer authoring tools support longdesc, an attribute that by design does not force a visual encumbrance upon sighted users.

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 complicated for ordinary authors and designers to author hidden relationships than provide a simple link via a longdesc attribute.

The workaround presented in this proposal 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.

Description Available in a Separate Document is a Key Author Requirement

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

For instance the CSS Squirrel, 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 DIAGRAM 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 functionality. It is limited to on-page descriptions.

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.

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.

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

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

Does Not Work for Users

Problems with Pointing Inside Hidden Elements

The hidden Hack is Nonsensical Double-Speak

The HTML specification currently states,

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

This change proposal changes the hidden attribute's spec text to,

Elements that are not hidden should not link to or refer to elements that are hidden. However, ARIA attributes are exempted from this rule and are allowed to point to contents inside hidden elements.

Hence the editors draft was changed in January 2012 to state,

The hidden attribute must not be used to hide content that could legitimately be shown in another presentation... if something is marked hidden, it is hidden from all presentations, including, for instance, screen readers...

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.

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. This double-speak not only adds ambiguity and confusion for authors, the hack directly subverts the hidden attribute's meaning without consideration of repercussions.

This technique sets an unacceptable double standard because the hidden content would not only be legitimately relevant to screen reader users, it could be vital.

Layering this hack on top of the inherent complexity of aria-describedby would increase author error exponentially. In contrast longdesc is simple and does not require a hidden hack. If this text is left in the spec, some developers would be provided a complex technique. However, it introduces inconsistency and confusion. It is ambiguous, error prone, and would be difficult to comprehend and put into practice especially for novice authors.

No Discoverability Requirements

This purposed spec text,

Elements that are not hidden should not link to or refer to elements that are hidden. However, ARIA attributes are exempted from this rule and are allowed to point to contents inside hidden elements.

does not provide any requirements on user agents to help interested users like authors or people with low vision who may be aided by access to the long description discover hidden elements. In contrast the Include longdesc in HTML5 Change Proposal specifies this needed functionality.

hidden is Hidden From Screen Readers

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 recently 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. This means that the long description using the proposed hidden technique would be hidden from its target audience.

Consequently it is obviously wrong to point inside hidden elements.

Two-Step Retrieval Instead of One-Step Retrieval

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.

Even if the link worked (which it wouldn't), 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.

Supporting Structured Text is a Key User Requirement

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

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

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

Not Being Forced Upon Users is a Key User Requirement

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

As the Association of American Publishers has explained,

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

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

Distracting and Frustrating Circular User Experience

AAP goes on to explain that,

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

Lacks Vendor Support

Authoring Tools

No evidence exists that authoring tools will implement aria-describedby or hidden="".

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 or hidden="" 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

Browsers

No evidence has been presented that any browser makes hidden content referred to by aria-describedby and hidden="" discoverable to all users. This need is entirely missing from this proposal.

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.

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.

Is a Bridging Technology

The original decision on Issue 30 specifically addressed Accessible Rich Internet Applications (ARIA). It said that the "native feature would be preferred over ARIA bridging" argument would apply to the decision if the feature had known use cases. Ample longdesc use cases have now been supplied to the Working Group. So the ARIA bridging argument now applies.

ARIA is not meant to replace native HTML accessibility. 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 assumption 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.

HTML does not require a bridging technology to provide host language long description functionality for images as longdesc already provides it natively.

The fact that ARIA is a bridging technology and HTML5 should have built-in native semantic features was successful rationale used to keep <figure>, <aside>, <details>, and hidden="" in HTML5. The decisions on those Issues set precedent that native HTML is preferred over a ARIA, a bridging technology.

Side-streaming accessibility technical requirements into an "Accessible Rich Internet Applications" specification is not a workable, long-term solution. The more content authors and application developers have to think specially about something called "accessibility", the more it will remain unimplemented in at least a sizable proportion of cases. To succeed, it really has to be core.

In fact one 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.

As Karl Groves illuminated in his article "Confusion over HTML5 & WAI-ARIA",

The HTML specification is the shortest path to true accessibility...

WAI ARIA should only be used as a last resort when content can’t be made accessible using the host language.

Obsoleting longdesc and resorting to a separate bolt-on language by importing ARIA to provide equitable content to users would not only be a giant step backwards but a disgrace to the language. It would shift responsibility and segregate requirements into a corner labeled "accessibility".

Semantics

longdesc strengthens the language. A longdesc's purpose is to provide a long description.

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

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.

For further rationale regarding semantics, please refer to my objection to the Zero Edit/Obsolete proposal.

Attempts to Reinvent 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.

Lacks Backwards Compatibility

aria-describedby and hidden are new. They have 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.

No Evidence of Improvement

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

Expanding longdesc Use

The Keep the longdesc attribute for the img element deprecated proposal states,

The aria-describedby attribute designed by WAI has several advantages over the longdesc attribute. The first one is that it is much more generic than longdesc. Longdesc is only available on <img> and the various frame elements. Aria-describedby on the other hand is allowed to be used on any HTML element

No decisive use cases based on real world examples have been presented that long descriptions are needed on other elements. This supposition has no concrete evidence.

No evidence has been presented that a generic container is well suited to a DOM-based language (as HTML has indeed become in most practice) because it isn't clear what APIs should be available (it makes sense to be able to access the longdesc programmatically for an image, but for audio or a plugin there are different things you may want).

However, after it is reinstated in HTML, if use cases are presented, the longdesc attribute could very well fulfill those use cases by being made a valid attribute on elements that need a semantic, programmatic determinable long description or if warranted by being made a global attribute. This would enable developers of tools producing HTML to use the same native HTML mechanism for adding descriptions.

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

Conclusion

I object to this proposal because it is misleading and fails to meet requirements. It does not fulfill use cases. "Hacking" away with aria-describedby and hidden is a retrograde "solution" that doesn't work in practice for authors or users. It reinvents the wheel, lacks vendor support, and backwards compatibility. It attempts to obsolete vital core host language semantics with a bridging technology.

The Include longdesc in HTML5 Change Proposal as well as my objection to the Zero Edit/Obsolete proposal provides further rationale for this objection and explains how longdesc solves problems and makes things better.

People with disabilities would be the losers if longdesc were removed from HTML in favor of this proposal.