Extended Description Analysis

The tables below relate information about requirements and implementations of etended descriptions. This is intended to help the community settle on a path. Known relevant resources from which this draws:

Technological Approaches

The following table outlines proposed approaches to provide extended descriptions. Along with a brief description, the table presents pros, cons, and possible ways of mitigating the cons. Whether an approach meets use cases comprehensively enough is a pro / con but that is addressed in the following table, use cases and technological approaches5. Approaches also only work if they are implemented6, detailed in the third table.

Description Pro Con Mitigation
description links Author provides a link to a desciption near the object. Link text is by convention but not requirement "[D]".
  • Requires no special implementation
  • Long-established technique
  • Simple for authors
  • Creates undesired visible links
  • Desciption not programatically associated with object
  • User must follow link and potentially lose place
  • CSS can hide links from default display, but erases universality benefit
  • Description could be associated via an attribute, though the obvious aria-describedby has been ruled out
longdesc URI to a description is provided in the "longdesc" attribute of the <img> element.
  • Long-established technique
  • Only works for <img>
  • Not liked by implementers
  • Usually (though not inherently) still requires user to follow link
  • Indeterminate processing model for URIs to a description on the same page, yet many advocate this pattern
  • Few authors use it
aria-describedby Pointer to a description on the same page provided on any object via the "aria-describedby" attribute. This is automatically exposed to the accessibility API.
  • Description in same page
  • Description available to all users
  • Description lacks rich exposure to user
  • Description bloats page if it's not considered primary content
  • Specify that UA can follow arc to rich description (but massively changes how this has been implemented)
  • Allow a URI in the value (but creates big processing confusion potential)
aria-describedat URI to a description is provided in the "aria-describedat" attribute of any object.
  • Description not loaded if not needed
  • Not liked by some implementers
  • Being a generalization of longdesc, it is questionable if many authors would use it (just as they do not use longdesc)
figure with details <figure> contains a <figcaption> which contains a <details> providing the description.
  • Leverages existing proposed HTML feature
  • Feature still in proposal stage
  • Overloads the details element
  • Doesn't support external descriptions
  • Comparatively complex to author
  • May be complex to implement or depend on script support long-term for optimal user experience
  • Add role attribute to clarify overloading
  • Add src attribute to allow external descriptions
figure with details and embedded iFrame <figure> contains a <figcaption> which contains a <details> which contains an <iframe> that loads the description.
  • Leverages existing proposed HTML features
  • Supports external description
  • External description always loads
  • May require special support to get desired user experience
figure with details with src and role attributes <figure> contains a <figcaption> which contains a <details> which loads an external description from the "src" attribute and clarifies it's a description with the "role" attribute
  • Leverages existing proposed HTML features with some modification
  • Supports external description
  • Less overloading of <details>
  • Requires additional engineering of an already only proposed element (<details>)
  • Comparatively complex to author
accessible SVG Native SVG features provide description.
  • Most closely associates description with image
  • Not all describable objects are in SVG
SVG wrapping bitmap SVG with description loads a raster image for the presentation.
  • Keeps description with image
  • Requires SVG and bitmap processing
link in figure caption Description link provided in <figcaption>.
  • Simple for authors
  • Description available to all
  • Not all describable objects have captions
hidden iframe
  • Uses existing technology
  • Kludges the iframe
image map
web annotations Description treated as an annotation, externally stored and related to the object.
  • Description completely separate from object, yet clearly associated with it
  • Multiple descriptions (languages, level of detail) easily supported
  • Nascent technology
  • Requires an annotation server?

Use cases and technological approaches

The grid below is intended to map known extended description requirements to technological ways to meet them. Approaches that meet more use cases will generally be preferred, though the other pros and cons also need to be considered.

Note from Dpub: We are looking at these elements as they are currently defined in existing specifications. We are not analyzing the ability of these elements with potential, unwritten changes to address the use cases.

Note from Dpub: We are also not looking at the current functionality of existing AT and UA. We are looking at what the specification would allow existing AT and UA to implement reasonably.

Note from DPub: We assert that the rows "Discoverable by AT", "Available on demand to AT users," and "Skippable by AT" should be collapsed into a single wrote "Exposed to accessibility APIs meaningfully". We then assert that the row "Not required to be visible in standard content view" is unnecessary. Our reasoning follows:

The requirement from the digital publishing perspective is that there be an element that

  1. Is reported to the accessibility APIs and the user agent as an extended description
  2. The element can be hidden from the visible view, or exposed, depending on user agent or AT settings or functionality
  3. The element can be meaningfully skipped.

Given our reasoning, this is the reason we would like to replace these four rows with "Exposed to the accessibility APIs meaningfully": In our table below, we are replacing these four rows with "Exposed to the accessibility APIs and UAs meaningfully". To maintain some of the information which was in them, we are adding the following table beneath, with rows for the current state of the world with there rows:

Note from Dpub: If we changed an item in existing cell, we indicated that in the cell. However, if we weren't sure of the answer to something, and the table was pre-populated with an answer, we left the pre-populated answer untouched; there is no visual /semantic indication in this table differing between the cells we agree with and the cells we don't have enough information about. Particularly, we don't have enough information about the two SVG proposals to truly understand what is being proposed.

Note from Dpub: We are withdrawing the requirement "able to pass structured content to an additional specialized user agent." We don't think this is the appropriate place to solve that problem.

According to specifications, as currently existing, with the caveats that some of these specifications are still in draft (eg. annotations).
description links
Note from Dpub: Could you confirm that by "description link" you mean <link> or <a> elements?		 longdesc aria-describedby aria-describedat figure with details figure with details and embedded iFrame figure with details with src and role attributes accessible SVG SVG wrapping bitmap link in figure caption hidden iframe image map
Note from Dpub: The map element contains no element that would hold a description outside of any other legal flow content, so we weren't sure how this example was intended to be used.		 web annotations web components
Note from Dpub: Mark Hakkinen's investigating this
Not restricted to images
Note from Dpub: For clarity, we suggest rephrasing to "Works for non-image content"		 yes no yes yes yes
Note from Dpub: Figure can be a wrapper around any flow content. 		yes
Note from Dpub: Figure can be a wrapper around any flow content. 		yes
Note from Dpub: Figure can be a wrapper around any flow content. 		no no yes
Note from Dpub: Figure can be a wrapper around any flow content. 		yes no yes ?
Can hold rich content yes yes no yes yes yes yes to an extent to an extent yes yes ? yes ?
Same technique for different objects yes no yes yes yes
Note from Dpub: Figure can be a wrapper around any flow content. 		yes
Note from Dpub: Figure can be a wrapper around any flow content. 		yes
Note from Dpub: Figure can be a wrapper around any flow content. 		no no yes
Note from Dpub: Figure can be a wrapper around any flow content. 		yes no yes ?
Reusable in multiple content Note from Dpub: "contexts"? yes yes no yes no yes yes no no yes yes no yes ?
Description clearly associated with object no yes yes yes yes yes yes yes yes yes no yes? yes ?
Clear which associated object is the description no yes yes yes no no yes yes yes no no yes? yes ?
Not bloat primary content page yes yes no yes no yes yes no no yes yes no yes ?
Exposed meaningfully to the accessibility APIs and UA no yes yes yes no no no no no no no no yes? ?

For reference, to clarify the current state of the world, for current spec, and some current AT and UA.
description links
Note from Dpub: Could you confirm that by "description link" you mean <link> or <a> elements?		 longdesc aria-describedby aria-describedat figure with details figure with details and embedded iFrame figure with details with src and role attributes accessible SVG SVG wrapping bitmap link in figure caption hidden iframe image map web annotations web components
Note from Dpub: Mark Hakkinen's investigating this
Discoverable meaningfully by any current AT. no yes no no no no no no no no no no no no
Skippable meaningfully by any current AT no yes no no no no no no no no no no no no
Hideable from the visual meaningfully by any current AT no yes yes no no no no no no no no no no no
Able to be accessed without using a screen reader in any current UA yes no yes no yes yes yes no no yes no no no no

Technological Approaches Implementation

Information about the known implementation of particular approaches is provided here. An approach that has, or is expected soon to have, more implementation will tend to be preferred. Note: implementation information below refers to implementation needed to make the description available to assistive technology, not simply implementation of the base feature in mainstream user agents.

Webkit Blink Gecko IE Edge
description links N/A N/A N/A N/A N/A
longdesc No ? ? ? ?
aria-describedby ? ? ? ? ?
aria-describedat No ? ? ? ?
figure with details ? ? ? ? ?
figure with details and embedded iFrame Yes? Yes? ? ? ?
figure with details with src and role attributes No ? ? ? ?
accessible SVG ? ? ? ? ?
SVG wrapping bitmap ? ? ? ? ?
link in figure caption ? ? ? ? ?
hidden iframe ? ? ? ? ?
image map ? ? ? ? ?
web annotations ? ? ? ? ?

Implementation Complexity

Information about how difficult it is likely to be to implement, both for authors (who must implement a lot) and user agents (who must implement once, but with attention to impacts).

Authors UA
description links low N/A
longdesc med low
aria-describedby med med
aria-describedat med low
figure with details med low
figure with details and embedded iFrame highmed med
figure with details with src and role attributes highmed med
accessible SVG high high
SVG wrapping bitmap med high
link in figure caption low low
hidden iframe med low
image map med low
web annotations high high

Implementation Approach

Information about how difficult it is likely to be to implement, both for authors (who must implement a lot) and user agents (who must implement once, but with attention to impacts).

Uses AAPI Requires Script
description links no no
longdesc yes no
aria-describedby yes no
aria-describedat yes no
figure with details no ?
figure with details and embedded iFrame no ?
figure with details with src and role attributes no ?
accessible SVG yes no
SVG wrapping bitmap yes no
link in figure caption no no
hidden iframe no ?
image map no no
web annotations no yes?