Suggested Alternatives Are Not Viable Solutions

The Chairs initial decision on longdesc ISSUE 30 stated, "alternatives exists (explicit links, aria-describedby, figure captions)". Since then other solutions have been proposed. These are not viable solutions.

Explicit Links

• Explicit links are not a functional replacement for longdesc.
• In an effort to mitigate damages of user agents that do not yet have a long description feature built directly into them, some sites provide a separate redundant link or a D-link to a long description. These links do not programmatically tie the image to the description.
• It is impossible for an explicit link to be programmatically determinable when that link is already mapped to go to another page or a larger image.
• Explicit links natively force a visual encumbrance on sighted users. Many artists, designers, marketers and authors do not want their visual designs ruined with visual indicators of any sort.

aria-describedby

• aria-describedby is not a functional replacement for longdesc.
• aria-describedby natively forces a visual encumbrance on sighted users. Many artists, designers, marketers, and authors do not want their visual designs changed/ruined with redundant text.
• aria-describedby requires particular necessary content to be included in a given page. While it may be good practice to avoid 'hidden metadata' in some cases, attempts to require this authoring behaviour by specification are doomed to failure. Indeed, since features as microdata are specifically designed to make it possible to carry hidden metadata we can expect authors to simply use a range of ambiguous techniques to provide this data.
• aria-describedby does not support the re-use of a description for an image which is present on more than one page.
• aria-describedby does not support anything richer than plain text. This significantly reduces the author's ability to provide a rich, AT navigable hypertext description, something that longdesc readily supports. Some details:
  • The target provided by aria-describedby's idref is concatenated to the "description" property in the accessibility API, which means AT users receive that information as a string of text. This is outside of ATs' control, so they have no choice but to announce it as a string, rather than allow the user to navigate the content using AT reading keystrokes to investigate rich semantics.
  • aria-describedby kills off links: ARIA 1.0 specifies that anything that aria-describedby points to is presented to the user as if it occurred inside an attribute. Hence, if aria-describedby points to an element which is - or contains - a link, the link will be completely dead - the AT won't inform the user about the link presence.
• As currently implemented aria-describedby forces the user to listen to the description whether they want to hear it or not.
• aria-describedby proposes a new way to solve something where there is an existing answer. It reinvents the wheel. It breaks the guideline of "paving cowpaths", and if it were to be carefully followed breaks both compatibility with existing best practice (and documentation of the same), as well as requiring a range of tools, content, and authoring guidance to be updated in order to achieve compatibility with the replacement - for something meant to solve the same problem, this is an unacceptable cost.
• aria-describedby forces people to read another large specification. This reduces the chances that it will be effectively implemented, by significantly increasing the workload required to understand the new model.
• aria-describedby is not native HTML. Protocols and Formats Working Group (PFWG) "likes the idea of having built in semantics in HTML and in particular would prefer to have common document elements."

figcaption element

While a figcaption may be a useful way to offer an image caption, it cannot replace the functions of the longdesc attribute.

• figcaption is not a functional replacement for longdesc.
• figcaption natively forces a visual encumbrance on sighted users. Many artists, designers, marketers and authors do not want their visual designs changed/ruined with redundant text.
• figcaption semantics are not to provide a long description for an image. The figcaption element represents a caption or legend for a figure.
  • WCAG 2.0 Success Criteria 1.1.1 explains the difference between short and long text alternatives.
• Not all images that require a long description will be in a figure element as not all complex images are figures. The only permitted parent element of figcaption is figure.
• The figure element is restricted. HTML5 makes it impossible for HTML authors to use <figure> as a child of <p>, because <figure> automatically closes <p> in the tree builder.
• figcaption cannot provide one common off page description for the same image repeated on several pages when that image also serves as a link. (i.e. it lacks the ability for an image to appear on multiple pages throughout a site or throughout multiple sites or from an HTML email while at the same time linking to one longdesc document).
• figcaption does not permit pointing to external sources that allow the full use of HTML as well as other markup languages, such as MathML or SVG.
• figcaption "currently provides the same amount of semantic information to AT as a div element. Firefox: exposes element name as an IA2 object attribute, but does not expose the relation between the figure and figcaption elements as an accessible relation."
• To support assistive technology ARIA labeled-by and a unique ID is required for every figure to connect it logically to a figcaption. That is extra effort a lot of developers will not go through. It is too verbose. longdesc is less complex. It is simply a link.
• Assistive technology users are not able to control how they interact with a figcaption (as they can with longdesc).
• figcaption is limited to text that appears in the same document as the image being described.
• figcaption is not backwards compatible. Unlike longdesc, it would not be recognized by existing authoring tools, user agents, assistive technologies, educational material, etc. longdesc has a critical support base that has taken a decade to build and would probably take another to rebuild with a new element. Obsoleting longdesc in favor of a new element would setback progress.

details element

• details is not a functional replacement for longdesc.
• details natively forces a visual encumbrance on sighted users. Many artists, designers, marketers and authors do not want their visual designs changed/ruined with a disclosure widget.
• details semantics are not to provide a long description for an image for a specific audience. It is to "represent a disclosure widget from which the user can obtain additional information or controls."
• An image is not a summary for a description. An image and a description are peers expressed in two different media.
• Not all images that require a long description will be in <details>. Authors are not going to think about details when they want to use a complex image. If they want to use an image they will use img. It is illogical to require img to be encased in details in order to provide a long description.
• details cannot provide one common off page description for the same image repeated on several pages when that image also serves as a link. (i.e. it lacks the ability for an image to appear on multiple pages throughout a site or throughout multiple sites or from an HTML email while at the same time linking to one longdesc document).
• details does not permit pointing to external sources that allow the full use of HTML as well as other markup languages, such as MathML or SVG.
• As demonstrated in the discussion on using details as a pseudo long description, developers wrap images with a link in order to open a larger image. This will conflict with the default behavior of a details disclosure triangle.
• details "Not implemented. Currently provides the same amount of semantic information to AT as a div element."
• Assistive technology users are not able to control how they interact with a details element (as they can with longdesc).
• details is limited to text that appears in the same document as the image being described.
• details is not backwards compatible. Unlike longdesc, details would not be recognized by existing authoring tools, user agents, assistive technologies, educational material, etc. longdesc has a critical support base that has taken a decade to build and would probably take another to rebuild with a new element. Obsoleting longdesc in favor of a new element would setback progress.

aria-describedat

Recently, Protocols and Formats Working Group (PFWG) has discussed introducing a new ARIA attribute - aria-describedat - as a possible addition to a future ARIA specification (ARIA 1.1) for external descriptions. This recent change of focus represents an acknowledgment that the idea to use aria-describedby could not have technically worked.

The main purpose of aria is to generalize functionality already present: aria-label can be used instead of alt, and on all elements. But, despite that, aria-label has not lead to deletion of alt. Likewise 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. The alt attribute also has some features that aria-label does not have - such as that it works in any user agent (UA) with images disabled. Likewise, longdesc already works in many UAs - whereas aria-describedat would not work in the same UAs. In sum:

• aria-describedat reinvents the wheel. longdesc works now.
• ARIA should be used to augment the available semantics of HTML as necessary, not to duplicate a basic mechanism that has already previously been created.
• aria-describedat is vaporware. It currently does not provide external reference functionality. longdesc provides it now.
• In Firefox regardless of what ARIA might do in the future, currently, any "aria-describedat feature" has to be glued to Firefox's longdesc capability.
• aria-describedat would be strictly assistive technology oriented. Whereas @longdesc has even been implemented in Opera, iCab etc.
• aria-describedat is not backwards compatible. aria-describedat would not be recognized by existing authoring tools, user agents, assistive technologies, educational material, etc. longdesc has a critical support base that has taken a decade to build and would probably take another to rebuild with aria-describedat. Obsoleting longdesc in favor of a aria-describedat would setback progress.
• aria-describedat is not native HTML.
• Protocols and Formats Working Group (PFWG) "likes the idea of having built in semantics in HTML and in particular would prefer to have common document elements."

<canvas src>

On March 2, 2011, it was proposed on the Web Hypertext Application Technology Working Group (WHATWG) list that <canvas src> allow images with structured fallback. This recent change of opinion regarding long descriptions represents an acknowledgment that the need for longdesc functionality is valid. However, <canvas src> is not a viable solution in many circumstances because:

• <canvas src> is not a functional replacement for longdesc.
• <canvas src> reinvents the wheel. longdesc works now.
• <canvas src> is vaporware. longdesc works now.
• Requiring the <canvas> element to supply long descriptions would introduce needless complexity. longdesc is a simple link.
  • The linkrot argument is specious.
• <canvas src> is not backwards compatible. Unlike <img longdesc>, <canvas src> is not recognized by existing authoring tools, user agents, assistive technologies, educational material, etc. <img longdesc>, has a critical support base that has taken a decade to build and would probably take another to rebuild with <canvas src>. Obsoleting longdesc in favor of <canvas src> would setback progress.
• <canvas src> semantics are not to provide a long description for an image.
• <canvas src> overloads fallback content.
• <canvas src> would be limited to text that appears in the same document as the image being described. If an image is very complex, it can require providing a long, in-depth, possibly complexly structured content to describe. This should be included in a separate page, but <canvas src> requires all of that to be dumped in the same page. Known use cases require the description to be in a separate page. Visit Describing a Logo, Describing Illustrations, Describing an Email Banner, and Facilitating etext Image Descriptions for examples. Therefore like aria-describedby, <canvas src> does not programmatically tie a single long description to an image while simultaneously allowing for reuse of that long description in multiple out of page venues.
• To display an image, an author would have to create a canvas context. The author doesn't create a canvas context using JS, directly, but assuming the UA will, this is far more complex and intensive than handling of an img element. According to the <canvas src> proposal, both the canvas and the img API are available, so a new context is created.
• <canvas src> does not support right click save of images, and the concept of copy and paste for image elements is not common behavior. When people want to use an image in their sites, they right click on the image, save it, and then upload to their servers. They don't copy and paste the img element or if they do, then they are "hot linking" the image, which is extremely frowned on in developer and designer circles. In fact, many people have server settings that prevent this--if you link to one of my images in your domain, that image will not show.
• The long description would be forced upon the screen reader user. The user should be able to choose to hear the description or otherwise interact with it, or to ignore the description, as users of popular screen readers are able to do today with longdesc.
• <canvas> "required accessibility support is not implemented."
• Not all images that require a long description will be in <canvas>. 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 use img. It is illogical to require img to be encased in canvas in order to provide a long description.
• Accessible does not equate to fallback. They are two different concepts.
  • "Fallback" content is used when the user agent is unable to present the content (because it doesn't implement the required feature).
  • "Fallback" content suggests "that the visual content (the image) is more important than the textual content."

Image Map

The current HTML5 editor's draft says to "use an image map to provide a link from the image to the image's description."

• Image maps are not a functional replacement for longdesc.
• It is impossible for an image map link to serve as a programmatically determinable long description if the image map link already has its hyperlink mapped to another function other than a long description.
• An image map long description link on the full image will clash with a normal hyperlink on the full image to go to another page or a larger image upon activation.
• Not all images that require a long description will be in an image map 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 use img. It is illogical to require img to be encased in an image map in order to provide a long description.
• Requiring image maps to supply long descriptions would introduce needless complexity. This would make it more prone to authoring error. longdesc is a simple link - no coordinates to figure out.
• Image map semantics are not to provide a long description for an image. It is to allow geometric areas on an image to be associated with hyperlinks. The hyperlinks can be anything.
• Overloading the mechanism of image maps with that of providing long text alternatives clashes in the case that you need both, image maps and a long text alternative.
• For a long text alternative provided through a link in an image map to be exposed to AT programmatically would require a special marking on one area, such as a @longdesc boolean attribute.
• Obsolescing longdesc breaks backwards compatibility for numerous company, organizational, governmental, educational, and personal sites throughout the world.

New HTML Attribute

A bug was filed on August 26, 2010 to create a new HTML attribute. It is Bug 10455: Mint a describedby attribute for the img element. It could be named something else if desired (i.e. "describedat" or "closeddescription" or "cdescription" or "closeddesc" or "cdesc" (invisible by default like a television closed-caption but can be opened via the user agent).

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

• A new HTML attribute reinvents the wheel. longdesc works now.
• A new HTML attribute is vaporware. longdesc works now.
• A new HTML attribute is not backwards compatible. Unlike longdesc, a new attribute would not be recognized by existing authoring tools, user agents, assistive technologies, educational material, etc. longdesc has a critical support base that has taken a decade to build and would probably take another to rebuild with a new element. Obsoleting longdesc in favor of a new element would setback progress.
• Obsolescing longdesc breaks backwards compatibility for numerous company, organizational, governmental, educational, and personal sites throughout the world - so you slow down quite considerably getting back to the small but important gains longdesc has given.
• Obsolescing longdesc would cause confusion and result in mixed messages between existing Guidelines, Laws, Policy, and Standards and HTML5.