Issue 30 Change Proposal: Include longdesc in HTML5

I would surely be remiss if I did acknowledge the many people who helped to make this document possible. Among those, special thanks are due to Charles McCathieNevile, John Foliot, Gregory Rosmaita, and Leif Halvard Silli for their contributions.

Summary

Include the longdesc attribute from HTML 4 in HTML5 as an allowed attribute on images.

Rationale

Use Cases

A number of use cases for semantically rich, structured descriptions of images were provided, however those use cases are abstract and don't directly and specifically require the support of a longdesc attribute...Overall, the lack of identified use cases was found to be a strong objection.

Uses cases have been identified that directly and specifically require longdesc.

New Formal Use Cases Requiring longdesc

Recent research finds a number of distinct use cases covering the needs of authors, users, and organizations. These use cases all point to the longdesc attribute as being the most efficient and appropriate choice, and further the only choice to meet identified constraints and functional requirements. They also demonstrate how and why other proposed alternatives to longdesc fail on one or more constraints or functional requirements.

For an explanation of use case elements including constraints and scenarios please consult the Use Case Key.

Primary Use Case Overview

Longdesc affords authors the native capability to provide information that is essential for blind and visually impaired users but would be redundant for sighted users and unacceptable to visual designers' aesthetics.

It is an accommodation mechanism for people who are blind or have a visual impairment and use a screen reader. It is a tool to supply programmatically determinable descriptions of images such as data visualization (i.e. charts and graphs), diagrams, cartoons, logos drawings, illustrations, maps, photographs, etcetera when:

An image's content is visually apparent and typically redundant to a sighted person, and/or

It is unacceptable to a marketing department or web author to use another technique due to aesthetic considerations. Many artists, designers, and marketers do not want their visual designs changed/ruined with visible link text. (Longdesc is natively free from a visual encumbrance.), and/or

The image also serves as a link. With longdesc it is programmatically possible to separate the activation of the longdesc for exposure from the UA's universal link activation action (which is usually activated with the ENTER key, the SpaceBar, or by mouse click), so that the linked image retains the expected behavior in response to user interaction while a discrete mechanism is used to retrieve the long description. , and/or

@Nick - With the exception of this most recent comic, all the comics are made for sighted users and navigable via the previous/next links below the comic. Those links are targetable by the sort of technology a physically-disabled person would use to navigate most links.

The issue at hand was directed at a piece of technology made for non-sighted users, however, so this comic provided an exception to deal with that specific experience.

@Mattur - I have no qualms with other people using hyperlinks where they desire to provide alternate text. However, as a designer, I object to being told I must use those links myself. As you've pointed out on Twitter, the current design of the comic page would certainly support a hyperlink wrapping around the comic. However, my upcoming design already has functionality mapped to clicking the comic, and won't have space for a large "transcript here" hyperlink sitting around in plain sight (which would be distracting for the 99% of my users that are sighted). In that scenario, longdesc can and does serve my needs.

Also, 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, and most of longdesc's non-use is a lack of awareness or caring (most non-longdesc websites simply don't offer alt text at all.)"

Other Use Cases

The content in a longdesc's target explains what is visually evident. This is similar to an audio description of a video being redundant to people who can see. Audio descriptions describe items and/or actions that take place visually which are needed for complete understanding to people who can't see. Sighted users don't typically need them. The same is true of longdesc.

However, the following sighted people may be aided by access to a longdesc:

Users who have a cognitive or visual impairment, who do use a screen reader.

Users who have small screens (e.g. mobile phone or screen magnifiers).

Users who turn off images to decrease bandwidth use in order to lower their Internet usage fees.

Authors, for ease of authoring and maintenance purposes.

Access to the content of the longdesc attribute for the sighted should be similar to television closed captions. Closed captions are encoded or invisible to the sighted by default and must be decoded or made visible. There is a reason that closed captions (as opposed to open captions) are the default on televisions. Sighted people rarely require them. To them, they are visual noise. Clutter. Redundant. But if a sighted person wants to enable closed captions (longdesc is not hidden meta-data) they can do so via a user preference built into the system menu. It is a user choice. Televisions do not have a default on-screen visual indicator. There is no forced visual encumbrance. This is by design.

New Usage Information

Recent research finds that obsoleting longdesc specifically breaks the web for over 150 sites in the wild that are using it to describe images. Both authors and users have expectations that longdesc will continue to support existing content.

Obsoleting longdesc Breaks the Web

The longdesc attribute is in current use on company, organizational, governmental, educational, and personal sites throughout the world, including but not limited to:

Argentina

Australia

Austria

Belgium

Canada

China

England

France

Germany

Ireland

Italy

Japan

Malta

Myanmar

New Zealand

Portugal

Spain

South Korea

United Kingdom

United States

80/20 Rule

Numbers alone must not be the driving factor for technology decisions. Both mainstream (80/20) and edge-case requirements must be addressed, because for online information, there is:

No standardized user, and

No standardized device (browser or other user agent) for accessing information.

Some commentors have suggested that in order to sustain a small
language there have to be some screening factors, and frequency of
use in the as-is Web is the screening factor to use.

The WAI position on this is roughly "that is like saying that the
builder of a high-rise building should decide whether or not to
include fire-stairs based on whether the previous buildings at that
street address had burned down or not."

We don't build fire stairs just enough to evacuate 80% of the occupants.

Accessibility features address failure modes that are infrequent, but
critical when they occur.

Popularity among authors should be used to select between _functionally
complete_ alternative strategies for supporting required functionality.

Hidden Meta-data Fallacy

"Hidden meta-data" is not an accurate description of attributes such as longdesc. Rather the term should be "discoverable meta-data", for which user agents and authoring tools can and should offer access according to user preference. Today, longdesc is available to any user agent that wants to make it available to its users.

Germane to the "hidden meta-data" fallacy is the fact that the Web is not a visual medium. It never has been. It's an electronic communication medium, both audio and visual, both print and screen etc. It is multi-modal. Perhaps some web developers concentrate on a particular media type more than another. And perhaps on many web sites, sighted, dexterous, able-bodied users outnumber users with a disability. But the strengths, the beauty of the web, what makes it unique as a medium of communication, is that it isn't limited to a single output.

Something for Everyone, Not Everything For Anyone

The primary markup language of the World Wide Web should aim to extend the range of communication and make the web more accessible, universal, and inclusive. This however, does not equate to one size always fitting everyone. Technology provides a great opportunity of personalization and customization of content.

Two quotes sum this idea up:

accessibility is something for everyone, not everything for anyone, it's the content that's important not the interface - Adrian Higginbotham

The rationale for personalisation for accessibility is clear. Accessibility is essentially dealing with diversity - personalisation avoids the always flawed attempt of doing so by a "one size fits all" solution. - Martyn Cooper

The longdesc attribute is a mechanism that makes this idea a reality. It affords users a method to receive information in accordance to their needs and capabilities. Because one size doesn't always fit all, HTML5 should not obsolete features if not all users can fully make use of them but rather alternative/equivalent mechanisms like longdesc should be provided. Ensuring access to information for those who would otherwise be locked out and lose their opportunity to use the Web is the socially responsible and right thing to do.

Recent Research on Online Tutorials and Documentation

Recent research finds that a multitude of Tutorials, Documentation, and books exist. Obsoleting longdesc would cause all of these to be obsolete wasting an outlandish amount of time, money, and effort, which was used to prepare them. This critical support base has taken a decade to build and would take another decade to rebuild with a different mechanism. Obsoleting longdesc in favor of a new mechanism would setback progress.

Obsoleting longdesc would cause confusion to all who encounter these tutorials and documentation as they will expect longdesc to be a technique as described in the tutorials. These types of materials have a way of living on.

Recent Research on Guidelines, Laws, Policy, and Standards

Obsoleting longdesc would cause confusion and result in mixed messages between these existing guidelines, laws, policy, and standards and HTML5.

Implementation

In the Chairs initial decision, a number of arguments and counter-arguments were addressed. Under the heading "Implementation", the Chairs noted:

Overall, it was found that while this attribute is implemented, it is

not implemented widely. This necessarily makes this objection a weak

objection.

"Implementation" was possibly misrepresented, since recent research provides evidence of both GUI based browsers as well as authoring tools and adaptive technology software that have native implementation today for the longdesc attribute, demonstrating far wider implementation than first suggested. Alternative implementations/support also include Universal Feed Parser by Mark Pilgrim and Sam Ruby's Planet Venus.

Recent Research on Assistive Technology

Recent research finds that modern screen readers have good support of the longdesc attribute. They typically announce the presence of a long description when available, and provide users with the option of reading it by executing a specified keystroke. Support includes:

Recent Research on Browsers

Opera (native support) -- exposition of the longdesc is exposed by a right click on the image for which the longdesc has been defined) -- it has been requested that the IMG for which longdesc has been defined, be included in the tab order so that navigation to and exposition of longdesc is device independent

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 the long description. This link does notprogrammatically tie the image to the description. With proper implementation in browsers all such links could be solely longdesc.

Recent Research on Authoring Tools

Recent research finds that many authoring tools support longdesc. Among them are:

Galleria One of the files of the 'gallery software' says, "Setting this to true will open any image links in a new window. You can add image links using the longdesc attribute (default) or customize it using data_config".

WAVE -- detects whether the longdesc value is structured as a proper URL. This feature was implemented January 2009. Jared Smith from WebAIM expects in a new release of WAVE to have implemented longdesc URL checking that looks for even more of the common errors.

Other Tools Supporting Longdesc

Providing functionality natively allows for its use within syndication feeds and other contexts in which HTML is stripped of its associated styles and scripts. Recent research has found alternative implementations/support of longdesc:

These responses show a strong usefulness of the longdesc attribute, which is currently under debate for omission from HTML5. Also of note is that 22.7% of respondents do not know the usefulness of longdesc, suggesting a need for better education or presentation of this functionality in screen readers."

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

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

aria-describedby will annotate text in the target id referenced by the idref. This means assistive technology users would not be able to control how they interact with the long description (as they can with longdesc). It is read aloud without any user intervention, forcing the longer description on the user whether they want it or not.

aria-describedby is limited to text that appears in the same document as the image being described.

As, by definition, a long description is in fact long, aria-describedby is not good solution for a longdesc.

The content associated using aria-describedby as currently implemented, is limited to unstructured text. AT treats aria-describedby target content as though it does not have any mark-up. It is treated as a string of text.

aria-describedby is not backwards compatible. Unlike longdesc, aria-describedby 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 aria-describedby would setback progress.

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 even inform the user about the link presence.

It is unlikely that many content creators or developers 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. (reference Cliff Tyllick)

figcaption element

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

Not all images that require a long description will be in a figure element. 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.

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

Not all images that require a long description will be in a details element.

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.

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.

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.

It is unlikely that many content creators or developers 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. (reference Cliff Tyllick)

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

The <canvas src> proposal implies that the problem with longdesc is copy/paste errors. It is not. Some browser vendors have a problem in not affording users the option of accessing longdesc content. This could be corrected if they followed User Agent Accessibility Guidelines.

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

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

Image Map

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.

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.

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.

Related Solutions Do Not Negate the Need for longdesc

longdesc is being used properly today, is a valid HTML 4 attribute, is a viable choice that is supported by the majority of screen reading software, and when used properly, it provides a needed and useful solution to real problems.

Provides a method for the long description to be programmatically determinable when an image already has a link which is mapped to go to another document or a larger image.

Provides easy reuse of the targeted description from multiple sources (i.e. ability for an image to appear on multiple documents throughout a site or throughout multiple sites or from an HTML email while at the same time linking to one longdesc document).

Permits pointing to external sources that allow the full use of HTML as well as other markup languages, such as MathML or SVG.

Allows screen reader users freedom of choice. The description is not forced upon them whether they want it or not. They can interact with it at their own will. With other solutions like aria-describedby this is not possible.

Allows structured content in its target.

Strengthens HTML5's capacity to express semantics. A longdesc's purpose is to provide a long description.

Is backwards compatible.

Is recognized by existing authoring tools, user agents, assistive technologies, educational material, etc. It has an existing base that if taken away would slow down quite considerably getting back to the small but important gains longdesc has given.

Unlike options such as using <object data=image><markup/></object> (or <canvas src>), longdesc does not require any change or "messing" with the ARIA role or of the <img> element.

Exposition of longdesc would help authors debug. Reference: Adam Sampson.

Details

Main Spec Changes:

The 4.8.1 img element section of the spec would also become interactive content with longdesc present. i.e. add "or longdesc" after "usemap" in the phrase "If the element has a usemap attribute" under the 'Categories' item. The longdesc attribute would be listed as an attribute for the element. i.e. Add "longdesc" to the list of content attributes, and
"attribute DOMString longdesc;" to the attributes listed in the DOM
Interface for the img element.

The longdesc attribute is described already in HTML 4 and the description can be re-used, although it should be made clear that the URI to which longdesc refers can be a relative reference to some part of the same page (in order to be explicit about which content is associated with the image), or a different page.
I.e. in the first sentence at 1, add text such as "which may refer to a point within the current page or to a different page" after the word "link".

The example, which references an image but appears to provide useless alt text should not be copied from HTML 4.

Changes for other sections:

The following should all mention that a longdesc may be used to provide a detailed description of the image, e.g. to help a person who cannot see to understand and appreciate image content from a description.

4.8.1.1.10 A key part of the content should mention that where an image is a key part of the content, it should have sufficient text in the alt attribute to replace the image, and using the longdesc attribute for critical information is a mistake. However, it can be used for additional information if desired.

Impact

This has no impact on existing HTML-4 browsers, many of which fail to make longdesc accessible other than via the DOM. Failure to make this change
will have an impact on assistive technologies such as screen readers, which use the longdesc attribute to find descriptions of images.

This would require conformance checking to accept the attribute as valid, and would imply maintaining the existing requirement on Authoring Tools to allow the author to use this functionality. It would maintain conformance of HTML-4 tools and content, rather than the current expected change leaving them non-conforming.

HTML4 longdesc = uri: "This attribute specifies a link to a long description of the image. This description should supplement the short description provided using the alt attribute. When the image has an associated image map, this attribute should provide information about the image map's contents. This is particularly important for server-side image maps. Since an IMG element may be within the content of an A element, the user agent's mechanism in the user interface for accessing the "longdesc" resource of the former must be different than the mechanism for accessing the href resource of the latter...The alt attribute provides a short description of the image. This should be sufficient to allow users to decide whether they want to follow the link given by the longdesc attribute to the longer description, here "sitemap.html".

HTML5 on longdesc

longdesc is currently listed as an obsolete feature in the HTML5 editor's draft. It advises to "Use a regular a element to link to the description, or (in the case of images) use an image map to provide a link from the image to the image's description."

Web Content Accessibility Guidelines 2.0 on longdesc

Technique H37: "When an image contains words that are important to understanding the content, the alt text should include those words. This will allow the alt text to play the same function on the page as the image. Note that it does not necessarily describe the visual characteristics of the image itself but must convey the same meaning as the image. If the text in the image is more than can fit in a short text alternative then it should be described in the short text alternative and a longdesc should be provided as well with the complete text."

User Agent Accessibility Guidelines 2.0 on longdesc

3.1.2 Configurable Default Rendering: The user has a global option to specify which types of alternative content by default...

3.1.3 Browse and Render: The user can browse the alternatives, switch between them, and render them according to the following (Level A)...non-synchronized alternatives (e.g., short text alternatives, long descriptions) can be rendered as replacements for the original rendered content.

Open Publication Structure (OPS) on longdesc

Open Publication Structure (OPS) 2.0.1 - "For greater accessibility, it is strongly recommended that OPS Content Document authors include a URI reference in the optional longdesc attribute referencing a resource (such as another OPS Content Document in the Publication) describing the image in finer detail. Reading System developers are also strongly urged to recognize and render in an appropriate fashion (and with accessibility in mind) the resource specified in longdesc. For further information on the use of this attribute and related accessibility attributes, see http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/#gl-provide-equivalents."

3.30.3 longdesc - "Value should be a URI pointing to a long description, typically more detailed than, but complementary to, alt. Use of this attribute is strongly recommended because it can greatly enhance accessibility for print-disabled users."

Glossary

Functional Replacement

A solution that provides the same utility that the current (longdesc) solution provides.

Programmatically Determinable

A long description needs to be programmatically determinable. This relates to the information in web content. If technologies that are accessibility supported are used properly, then assistive technologies and user agents can access the information in the content (i.e., programmatically determine the information in the content) and present it to the user. For instance longdesc as an attribute should be used as a hook by user agents and asssistive technologies in order to notify the user that a long description exists, so even if longdesc is applied to an image that also serves as a link, it is programmatically determinable to separate the activation of the longdesc for exposure from the UA's universal link activation action (which is usually activated with the ENTER key, the SpaceBar, or by mouse click), so that the linked image retains the expected behavior in response to user interaction while a discrete mechanism is used to retrieve the long description. HTML4 puts it this way, "Since an IMG element may be within the content of an A element, the user agent's mechanism in the user interface for accessing the 'longdesc' resource of the former must be different than the mechanism for accessing the href resource of the latter."