aria-describedby

Bridging Technology

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

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.

Lacks Ability to Provide Description in a Separate Document

As explained a description available in a separate document provides efficiency.

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

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

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.

Lacks ARIA Educational Material

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.

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.

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.

Lacks Support for Structured Text

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.

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

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 documents for details of why using these techniques is a bad idea.

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

Even though a user agent might attempt to expose a mechanism for navigating to a description, it 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 not long ones.

Browser Discoverability for Non-AT Users

Discoverability affordances are needed for people who 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).

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 of discoverability tools for non-AT users (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. These supply universality for all.

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

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.

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.

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.

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

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.