Fallbacks for embedded content

This is an attempt to analyze how fallback mechanisms are applied to various types of embedded content in HTML. The analysis is an important step towards determining where the support provided by the HTML specification needs to be extended or modified to ensure all accessibility use cases are covered. The analysis is prepared primarily by Michael Cooper, with input from members of the Bug Triage sub-team of the HTML Accessibility Task Force.

This is a draft analyis put forth for discussion and should not be viewed as complete, final, or constituting a proposal in itself.

Sections of this document:

• HTML 4
• HTML 5
• General issues with fallback mechanisms
• Use cases

HTML 4

The table below shows known fallback mechanisms for embedded content elements in HTML 4. Only elements defined in HTML 4 are listed, plus the <embed> element which is a "de facto" HTML 4 element. The fallback mechanisms and issues are as generally used in the wild, not as defined by the specification. This is in order to identify the real support baseline upon which we are building.

HTML 5

The table below shows fallback mechanisms documented in the HTML 5 specification for the embedded content types supported by the specification. By contrast with the HTML 4 table, this HTML 5 table lists what the specification supports, not what is generally used in the wild. This is because the purpose of this exercise is to review the specification, not current usage. Note that the set of available fallback mechanisms (shown as column headers) is different from the set used in HTML 4.

General issues with fallback mechanisms

Some of the fallback mechanisms identified above have issues in theory or practice that were generic to several embedded content elements and / or were too long to include in the table. These issues are shown here.

@alt

• simple and long history
• not internationalized and doesn't support phrase markup
• lack of feature to specify "decorative" images have led to various heuristic uses of this attribute, but not complete universality in these

@title

• variously proposed / used as a replacement and / or supplement to @alt, but wildly inconsistent from an accessibility perspective
• primacy between @alt and @title unspecified: does @title come first, last, or cover @alt? Or should be ignored from an accessibility perspective?

@longdesc

• provides explicit long descriptions, contrasted with "d-link" approaches that don't semantically tie description to image
• description referenced by a URI, but user agent behaviour not specified (e.g., fetch and present? give user a link? etc.)
• many argue that a URI consisting only of a fragment on the same page should be valid, but unclear that implementations support this use case well, and expected UA behaviour not specified

embedded content

• mixture of fallbacks and param elements
• unclear whether fallback intended for non-support of element, non-support of the referenced content language (fallback only visible if the technology not supported), or accessibility (fallback displayed at user request)
• in practice, accessible fallbacks not available if browser supports the technology, which is largely the case today

Use cases

This is an attempt to propose use cases for fallbacks, as a step towards understanding what use cases remain to be met. The focus is on accessibility use cases. Use cases for non-support of the embedded content element and non-support of the referenced content technology are also important, and should not be confounded with accessibility use cases. It may be necessary to expand on this in the future in order to cleanly separate them.

The following list describes the use cases identified, and the table shows which embedded content types may have the corresponding use case. Beware of token overload; the terms are used here as defined below, and should not be interpreted to have any other meanings inherited from other contexts. Cells have an x where the use case is believed to apply to the embedded content type, otherwise they are blank.

Short text alternative

Can substitute for the object, sometimes on its own and sometimes complemented by an additional long text alternative. Normally, short text alternatives aren't provided if direct accessibility is possible, but it may still be used if direct accessibility for whatever reason isn't enabled (e.g., canvas makes a simple image and there is no need to enable full shadow DOM support).

Long text alternative

Can substitute for the object, fairly completely. Normally it complements a short text alternative but may stand on its own, e.g., in the case of transcripts.

Label

Identifies the object and tells the user if they want to go into it more. This has both non-accessibility and accessibility use cases. Frequently confounded with short text alternatives, it's a distinct use case and optimally should have a different implementation. Generally, if a label is provided, a short text alternative would be redundant and is not separately required.

Caption

This is a visible label, such as appears below an image in many publications. This is not primarily an accessibility use case, but is confounded in a few ways: 1) implementation of the caption is often (incorrectly, in my opinion) taken from the implementation of short text alternatives; 2) captions and short text alternatives are often both provided where their content is identical and redundant; 3) when a caption is provided, it should also generally be sufficient to meet the short text alternative use case (but not vice versa).

Summary

Is more than a short text alternative, but not the complete replacement that a long text alternative should be. Like a label, it may help a user decide whether to explore more, or may be a sufficient overview of the object in many cases.

Idiosyncratic direct accessibility

The object content itself provides ways to make it accessible, e.g., caption formats in video, features of SVG, the shadow DOM of canvas, etc. Generally, if a format supports direct accessibility it may still benefit from a label, but should not require a short or long text alternative. However, some objects may not enable the direct accessibility and still require external text alternatives, such as a short text alternative for a simple image implemented with canvas, or a transcript (i.e., long text alternative) for an audio. Note that for <embed> and <object>, this depends on features of the loaded content language, so these elements may or may not require separate fallbacks within the HTML.

Advisory / tooltip

A kind of text label that is usually displayed as a tooltip. Although frequently taken from short text alternatives or captions, this is not an accessibility use case. It is in the table to show that it is a distinct use case and should not be confounded with other accessibility fallbacks.

Specify none needed

For formats that need to be able to indicate that they are "presentational" and no accessibility fallback is needed.