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.
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
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:
IDnaming rules wrong.
aria-describedbyreferencing a non-existent
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
ID examples in the W3C WAI-ARIA 1.0
Authoring Practices specification.
hidden tools exist
to help authors in this task, whereas authors possess an array of
longdesc and to check that
longdesc works in browsers.
is complex. In contrast
longdesc is simple. As
Kyle Weems illuminated,
are we going to pretend that using
longdescis 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,
longdescattribute 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.
As explained a description available in a separate document provides efficiency.
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
For instance the CSS
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
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.
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
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
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
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.
longdesc support base exists in the form of
authoring documentation, tutorials,
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,
longdesc support materials will live
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,
aria-describedbyattribute 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:
- The user moves to the object that aria-describedby references
- 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
than they do with
longdesc. People with disabilities
face some unique challenges and barriers. Doubling their on-task
work load is needless and intolerable.
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
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
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-describedbycan 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
@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 supports structured content. Reading keys and
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
As the Association of American Publishers has explained,
aria-describedbycannot 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
a non-starter. None of this is a problem with
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.
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-describedbyto point to, for example, a paragraph just above the image. Users would then likely follow the
aria-describedbyannouncement, expecting to find additional content, but they would arrive, instead, at a paragraph that they have likely just read.
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
documents for details of why using these techniques is a bad
No evidence exists that authoring tools will implement
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-describedbyfeature. 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.
Vlad Alexander has envisioned a user friendly
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
As evidenced he has not only envisioned
longdesc interface, but he also implemented
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=-1is added to elements such as p, div and span when referenced from
aria-labelledbythat reference multiple elements
Firefox 14 attempts to use
long descriptions. As David MacDonald has tested and explained in
14: long description via link associated using
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
only suitable for short descriptions not long ones.
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
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.
This proposed replacement for
longdesc attempts to
duplicate a basic method that has already previously been
This proposed replacement is new and more complicated syntax for the same thing, or for a limited subset.
aria-describedby is new. It has no legacy or
longdesc has legacy content and
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
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
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.
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,
guidelines, laws, policies and standards that have already
longdesc's importance to accessibility will
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
Any proposed solution should be easy for authors who are already
publishing content with
longdesc to retrofit their
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 of accessible long text alternatives
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 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 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.