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 because of issues regarding support and education
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) Being a generalization of longdesc, authors will face the same roadblocks to using it: UA/AT support, lack of exposure to non-screen reader users, and education. Note that these potential roadblocks apply to every potential solution.
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?
web components	Web components allows for a highly customizable user experience where the user can control which alternative is selected via a provided UI or externally to the component.	Web Components can provide their own user interface or interoperate with Web application configuration facilities, including personal needs/preferences profiles. No “native” implementation is required (of the image alternatives/descriptions feature) in either UA or AT. The source markup is clear, concise and expressive.	The use of Web Components to provide alternatives to images is not yet standardized - that is, there can be multiple implementations which may be inconsistent between Web sites/applications; the semantics of the markup are not conveyed to AT, which therefore can’t provide its own user interface for the image and its alternatives (though perhaps this isn’t desirable anyway)?

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.

Definition used in DPub comments.

Meaningful: Used in a way that the API and UA can understand the referred to element is further description. Examples in existing specs: longdesc and aria-describedby both give enough information to say that this is specifically a description of the referred-to object. Longdesc says "this is further description, beyond the basics. Aria-describedby says "this is a basic description". How the user agents and AT deal with that meaningful information is another issue. However, DPub asserts the meaning of "extended description" is important semantic information that needs to be exposed.

DPub note: 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.

DPub note: 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.

DPub note: 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

Is reported to the accessibility APIs and the user agent as an extended description
The element can be hidden from the visible view, or exposed, depending on user agent or AT settings or functionality
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":

We must distinguish between "current AT and user agents implement the required functionality" and "the requirements needed in the specification."
We must distinguish between accessibility API and AT. For example, if a low-vision keyboard user needs access to expose the extended description, that is interaction with the UA, not with any AT.
All elements are technically "discoverable by AT"/"available on demand to AT users"/"skippable by AT", and all elements can technically be hidden from content view (e.g. via CSS). DPub's requirement is only met if that discovery/availability/skipability/hide-and-reveal functionality is meaningful. E.g., can a screen reader user identify that they are currently in an extended description, and if they skip to the end of it, that is what they are skipping? Can AT/UA respond to a request for "reveal extended descriptions" or "show me a list of extended descriptions"?

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:

Discoverable meaningfully by any current AT.
Skippable meaningfully by any current AT.
Hidden from the visual meaningfully by any current AT.
Able to be accessed without using a screen reader in any current UA.

DPub note: 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.

DPub note: It became clear throughout this conversation that the requirement "able to pass structured content to an additional specialized user agent" is vital for the publishing industry. However, it is needed in more contexts then simply extended descriptions, and is out of scope for this conversation.

According to specifications, as currently existing, with the caveats that some of these specifications are still in draft (eg. annotations).
	description links DPub note: 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 DPub note: 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 DPub note: Mark Hakkinen's investigating this
Not restricted to images DPub note: For clarity, we suggest rephrasing to "Works for non-image content"	yes	no	yes	yes	yes DPub note: Figure can be a wrapper around any flow content.	yes DPub note: Figure can be a wrapper around any flow content.	yes DPub note: Figure can be a wrapper around any flow content.	no	no	yes DPub note: Figure can be a wrapper around any flow content.	yes	no	yes	yes
Can hold rich content	yes	yes	no	yes	yes	yes	yes	to an extent	to an extent	yes	yes	?	yes	yes
Same technique for different objects	yes	no	yes	yes	yes DPub note: Figure can be a wrapper around any flow content.	yes DPub note: Figure can be a wrapper around any flow content.	yes DPub note: Figure can be a wrapper around any flow content.	no	no	yes DPub note: Figure can be a wrapper around any flow content.	yes	no	yes	yes
Reusable in multiple content DPub note: "contexts"?	yes	yes	no	yes	no	yes	yes	no	no	yes	yes	no	yes	yes Note from Mark Hakkinen: can be done either server-side or client-side
Description clearly associated with object	no	yes	yes	yes	yes	yes	yes	yes	yes	yes	no	yes?	yes	yes
Clear which associated object is the description	no	yes	yes	yes	no	no	yes	yes	yes	no	no	yes?	yes	yes Note from Mark Hakkinen: We may even leverage the new aria-roledescription to explicitly label the description type.
Not bloat primary content page	yes	yes	no	yes	no	yes	yes	no	no	yes	yes	no	yes	yes
Exposed meaningfully to the accessibility APIs and UA	no	yes	yes	yes	no	no	no	no	no	no	no	no	yes?	yes

For reference, to clarify the *current* state of the world, for current spec, and *some* current AT and UA.
	description links DPub note: 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
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 Note from Mark Hakkinen For the alternate content, it would only be displayed if requested, and thus skippable in that sense if display not. Depending upon the markup used in the actual implementation of the component
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

Extended Description Analysis

Technological Approaches

Use cases and technological approaches

Technological Approaches Implementation

Implementation Complexity

Implementation Approach

	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	?	?	?	?	?
web components	?	?	?	?	?

	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
web components	low (once Web component is built once)	high (but again only has to be done once)

	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?
web components	no	yes