Warning:
This wiki has been archived and is now read-only.

ChangeProposals/imagedescription

From HTML WG Wiki
Jump to: navigation, search

Issue 30 Change Proposal: Provide a dedicated description mechanism for images in HTML5

The following is a Change Proposal for ISSUE 30 which has been reopened.

Date: March 31, 2011.

Editors: laura carlson, steve faulkner & john foliot.

Summary

Include a specific mechanism for unambiguously associating a description of an image with an image.

Contents

Rationale

Use Cases

The Chairs' initial August 11, 2010 decision stated,

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 a dedicated mechanism for associating a description that may require structured content and may require the description to be located on a separate page to the image its describes.

New Formal Use Cases Requiring a dedictaed description mechanism

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 formal use cases, please visit Long Description Research: Use Cases. They include:

  1. Describing a Logo
  2. Describing a Cartoon
  3. Describing Artwork
  4. Describing Screenshots
  5. Describing a Chart
  6. Describing a Photograph
  7. Describing an Email Banner
  8. Describing Illustrations
  9. Facilitating etext Image Descriptions

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
  • The description is external to the document.

On August 17, 2010 the cartoonist Kyle Weems (aka CSS Squirrel) explained:

@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.
  • 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:

  1. No standardized user, and
  2. No standardized device (browser or other user agent) for accessing information.

Longdesc usage is not and will never be widespread because:

  • People with disabilities are a minority.
  • Images that need longdesc are a minority.

As Al Gilman said a few years ago,

80%-rule-NOT

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.

Recent Research on "Misuse"

On March 27, 2011, Karl Groves released a longdesc study. The findings state that the "vast majority of longdesc values are conforming". His data summary:

  • Across 10,200 URLs, I found 129 instances of the longdesc attribute
  • Of those, 89% of the instances were non-empty
  • 21% of the longdesc attributes were incorrect (read as: not of type URI, per the HTML 4.01 Recommendation)
  • 79% of the longdesc attributes were correct. In other words they did point to a URI

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

Recent research finds that a multitude of Guidelines, Laws, Policy, and Standards exist.

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

Recent research finds that longdesc has been implemented as follows:

  • Opera, Firefox, Chromium, and Internet Explorer all support longdesc DOM reflection.
  • Opera (native support) - exposition of the longdesc is exposed by a right click on the image for which the longdesc has been defined.
    • TellMeMore Opera extension Respects a web page's visual design yet provides critical functionality. It will "Find things that have more description available, and show them on demand. Where images (or something else) have a longdesc attribute, the extension notifies by changing its icon and title, and enables the user to see a list of the descriptions available, in its popup. When the user selects an item in the popup, a new window opens with the description in it."
  • iCab has native support for longdesc
  • FireFox - partial native support via the image context menu, which displays the URI of the longdesc attribute
    • Longdesc Firefox Extension by Patrick H. Lauke - adds a "View Image Longdesc" option to the image context menu that activates the link to the long description (over 23,000 downloads)
    • Longdesc for Linux for Firefox 4 by Patrick H. Lauke - allows one to view image's longdesc from the context menu
  • Internet Explorer when used together with assistive technology like JAWS makes longdesc accessible to the AT user.
  • Home Page Reader has native support of longdesc and is still used in Japan for longdesc.

Recent Research on Authoring Tools

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

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:

Recent Research on Users

On February 28, 2011 WebAIM released the results of their latest independent user survey which asked a question regarding the longdesc attribute.

The majority of respondents declared longdesc useful. The report states:

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

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

  • 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.
  • 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.
  • 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."
  • 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.
  • 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.
  • 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."
  • It is unlikely that many content creators or developers will learn anything with an ARIA prefix. 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 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.
  • <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> 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.

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

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

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.

The existence of related solutions does not negate the need for HTML5 to offer longdesc as a tool for authors. It provides them a unique tool when they determine it is needed. In many circumstances it is the right tool for the job. For instance Gail, Wylie, Toby, Clara, Naomi, Arvid, and Bill, as well as groups large and small all choose it. As do many others.

Stripping it from the author's toolbox would be a disservice.

Conclusion: longdesc Should be Included in HTML5

In conclusion, longdesc should be included in HTML5 as an allowed attribute on images because it:

Details

Main Spec Changes:

(Previous version of longdesc spec text based on Chaals' original proposal)

Changes for other sections:

Impact

  • Makes longdesc more useful, robust, and encourages better user agent implementation.
  • Requires 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.

References

Requirements

Requirements

New Information

Recent Research has been conducted and new information collected. It includes:

HTML 4 on longdesc

  • HTML4 16.4.2 Long descriptions of frames: The longdesc attribute allows authors to make frame documents more accessible to people using non-visual user agents.
  • HTML4 Index of Attributes: longdesc "link to long description (complements alt)".
  • 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".
  • HTML4 A.3 Changes for accessibility "Authors may provide long descriptions of tables, images, and frames (see the longdesc attribute)."

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

User Agent Accessibility Guidelines 2.0 on longdesc

From the Implementing User Agent Accessibility Guidelines 2.0, Editors' Draft 11 March 2011:

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

Issue 30

Previous Proposals

Formal Objections to ISSUE 30 Decision

Request to Reopen HTML-ISSUE-30

Minutes

Related Bugs

  1. HTML Bug 10015: longdesc URL checking - Status RESOLVED WONTFIX.
  2. HTML Bug 10016: longdesc and @role (ARIA) - Status RESOLVED WONTFIX.
  3. HTML Bug 10017: longdesc and @aria-describedby (ARIA) - Status VERIFIED INVALID.
  4. HTML Bug 10019: Native user agent support for exposing longdesc to all users - Status RESOLVED WONTFIX.
  5. HTML Bug 10434: Mint a link type for pointing to long descriptions (rel="longdesc") - Status RESOLVED WORKSFORME.
  6. HTML Bug 10455: Mint a describedby attribute for the img element - Status RESOLVED WONTFIX.
  7. HTML Bug 10853: HTML5 lacks a verbose description mechanism - Status RESOLVED WONTFIX.
  8. HTML Bug 10967: Add @desclink, a description link attr. for any embedded element + figure - Status RESOLVED WONTFIX.
  9. HTML Bug 11012: Also say that <area>/image maps is an alternative to @longdesc - Status: RESOLVED FIXED.
  10. HTML Bug 12243 - Warn when ARIA-describedby/-labelledby points to interactive/form associated content - Status: NEW.

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

Acknowledgments

Thanks to Adrian Higginbotham, Aryeh Gregor, Artur Ortega, Catherine Roy, Charles McCathieNevile, Cliff Tyllick, Christophe Strobbe, Dan Conley, Daniel Glazman, Debi Orton, Denis Boudreau, Dirk Ginader, Everett Zufelt, Geoff Freed, Gregory Rosmaita, Henri Sivonen, James Nurthen, Jason White, John Foliot, John Middleton, Karl Groves, Keith Parks, Kyle Weems, Lachlan Hunt, Leif Halvard Silli, Marco Ranon, Martin Kliehm, Martyn Cooper, Michael Fields, Monika Trebo, Philip TAYLOR, Robert Burns, Roger Johansson, Sean Hayes, Sarah Bourne, Shelley Powers, Stephane Deschamps, and Steve Faulkner.

Retrieved from "https://www.w3.org/html/wg/wiki/index.php?title=ChangeProposals/imagedescription&oldid=10407"