A mechanism for alternate content within HTML documents
Contents
Problem statement / use cases
- authors sometimes need to explicitly markup relations between embedded non-text media and related document fragments that describe or reference the document fragment
- authors need an element whose default CSS display is none but which can serve as container for a document fragment text alternative to non-text media
- authors need an HTML-only way (independent of HTTP) to provide alternate content within the same document (such as alternate language content, alternate media content, alternate content type content and so on)
- authors needs feedback from UAs upon authoring alternative content within a document
- users need mechanisms to access alternate content and to tailor the content to their own user and environmental needs
- implementations need clear interoperable guidance on how alternate content should be rendered and processed for users
Gaps
- This write-up does not yet deal with whether/how to handle situations where rendering multiple equivalents simultaneously would be preferable.
Whether the <alt> element's for attribute may point to any element, or only to a predefined list of elements (such as <img>, <object>, <embed>, <audio>, <video>, <canvas>, <table>) needs to be discussed.
- Whether authors should be able to explicitly indicate a preferred equivalents cascade needs to be discussed. (Explicitness would potentially introduce an opportunity for authoring errors. Besides, the author can indicate this implicitly through the order of provided equivalents.)
- Should UAs interpret order of equivalents as indicative of anything at all? (Can author be trusted/should author be burdened?)
Terminology
- "author-preferred equivalent" refers to the content for which one or more quivalents are available [Needs a better term. Perhaps "premier equivalent"?]
consult: Glossary of Terms for the HTML WG
consult: WAI Glossary (Note: the WAI Glossary addresses both WAI definitions of terms and concepts, but also W3C-wide definitions of terms and concepts)
Unifying the mechanisms to provide universality and accessibility – aka "A better alt"
Description of Accessibility, Internationalization and Universality Problems with ALT
Currently, different elements require different authoring techniques to provide equivalents. For example, <object>> takes its contents as the fallback mechanism, whereas <img> takes two different dedicated attributes, @alt and @longdec. Such inconsistency makes things more difficult for authors.
- @alt limits the equivalent to plain text – mark-up is not allowed, which makes it an even bigger challenge for authors to provide a good equivalent
Authors could use <object> instead of <img> to be able to provide rich/marked-up equivalents, but due to the lack of interoperability of <object> this is highly unattractive to authors. Also, it appears unlikely that <object> will become interoperable.
marked-up textual equivalents can satisfy the universality requirement, but ignore specific accessibility cases where other types of equivalents would be more ideal (a captioned version of a movie provides a deaf user with a more rich equivalent than a transcript does; an audio version of a movie, for example, provides a blind user with a more rich equivalent than a transcript does)
- Equivalents are treated as fallback by UAs. As a result, equivalents are "invisible metadata", and thus more difficult to author (authors don't 'see' the need; if they do, they don't easily see the result; "invisible metadata" is easily forgotten when the rest of the content is updated (especially with dedicated @longdesc documents))
- Equivalents are treated as "fallback" by UAs. As a result
authors can provide only a single equivalent in the case of <img>
authors are forced to decide on the 'right' fallback cascade in the case of <object>, <embed>, <audio>, <video>, <canvas>, <table>, etc. which they cannot possibly do 'right' because they cannot know which equivalent will be ideal to a given user in a given situation
- authors need to be able to provide multiple equivalents side by side (for instance, to allow the user to read a transcript while listening to the audio equivalent).
How would one indicate to end-users, a natural language switch as part of a title or alt? Perhaps an attribute @titlelang end @altlang (like @hreflang) that will take language code and punctuation separations. (Note: language code and punctuation have to be separated by white space (source: Olivier Gendrin, post to public-html 28 August 2007)
- Examples of Internationalization problems:
<!-- USING CURRENT MARKUP --> <span lang="fr">Lorem ipsum <abbr title="National Aeronautics and Space Administration (Administration nationale de l'aéronautique et de l'espace)">NASA</abbr> sit dolor amet</span>.
<!-- USING OG's PROPOSED MARKUP --> <abbr title="National Aeronautics and Space Administration (Administration nationale de l'aéronautique et de l'espace)" titlelang="en ( fr )">NASA</abbr> <acronym title="Working Group - groupe de travail" titlelang="en - fr">WG</acronym>
Implementation Problems
- @alt as "Tooltip" makes access to @alt text problematic, because tooltips tend to disappear within a few seconds. Thus longer @alt text is difficult to consume, yet the spec doesn't inform authors what amount of text they can count on being 'too much'
@alt is not implemented interoperably. See test-case.
@longdesc is implemented in only one GUI browser (iCab), which contributes to general unawareness amongst authors. (Even that one implementation isn't ideal: the resource pointed to by @longdesc is always loaded in a new window, even when @longdesc points to an anchor within the current document.)
- @longdesc doesn't describe how users who follow its URL must be able to find their way back
- Instances of @longdesc pointing to an external resource, thus requiring an extra http request, might fail (network problems; resource not found; no network connection available; etc.)
- For instances of @longdesc pointing to an external resource, it is unclear how that resource should look: should it include the web site navigation toolbars (increasing the time to reach the content for the user), or shouldn't it (risking confusing the user due to different 'looks' and missing site navigation bar)
- For instances of @longdesc pointing to an external resource, search engines need to make an extra request (which might fail) to get information about the image.
- It is not defined that UAs must make it easy for the user to return to where they came from after having followed an @longdesc URL. (iCab's implementation demonstrates how that can be a problem)
Proposed solutions
A new <alt> element with a required @for=idref attribute and optional (but strongly encouraged) type=MIMEtype and @title attributes. (If multilingual equivalents are within the scope of HTML5, @lang should be also be an optional attribute.)
The content of the <alt> element is an equivalent for the "author-preferred equivalent" that the @for attribute points to. The type attribute's value provides the UA with advisory information concerning the file format of the <alt> element's content. The title attribute provides the user advisory information about the sort of content.
When an <alt> element directly follows an <img> element and does not contain an @for attribute, the UA must assume an implied @for attribute referring to that preceding <img> element.
When an <alt> element is the content of an <object>, <embed>, <audio>, <video> or <canvas> element and does not contain an @for attribute, the UA must assume an implied @for referring to that parent <object>, <embed>, <audio>, <video> or <canvas> element.
Otherwise, an <alt> element may occur anywhere within <body> provided it contains a valid @for-idref
UAs must clearly indicate occurences of <alt> elements, what they are an equivalent for, as well as the <alt> element's @title's advisory information.
UAs must provide easy access to the contents of <alt> elements.
UAs may use the @type attribute's value as the basis to by default hide <alt> elements of which the user has indicated that he does not wish them to be presented, or which the UA cannot present.
UAs should indicate the file format of <alt> elements, preferably by transliterating the MIME type to a human-readable form (applicatind/pdf == "PDF").
UAs must not hide <alt> elements by default
UAs may allow users to hide <alt> elements by default
Authors may set <alt> elements to display:none for any media, but UAs must allow users to override that both by default and on a per case basis. (Note that authors are not required to set display:none. For instance because certain equivalents may be useful side by side. Example: a transcript of an audio equivalent; a prose equivalent of tabular data; a slide show equivalent of prose; etc.)
When only one <alt> element is provided for an author-preferred equivalent, and that "author-preferred equivalent" can for whatever reason not be displayed, the UA must fallback to that equivalent.
When the author-preferred equivalent and one or more equivalents are avaiable, or when the author-preferred equivalent cannot be displayed and two or more equivalents are avalaible, the UA may fallback to an equivalent, based on pre-configured user defined settings, but must allow the user to easily override and choose another quivalent.
When the user selects a listed equivalent, the UA must load it. Either by replacing the author-preferred equivalent, or next to it, or in a separate browser window (or whatever is the equivalent in the browsing environment). Either way, the UA must provide the user with easy means to return to the previous view.
Compatibility with pre-HTML5 UAs
The contents of <alt> will be rendered by pre-HTML5 UAs. The contents of @alt and @longdesc would thus be repeating the contents of the <alt> element. This would hinder adoptance of <alt>. Therefore HTML5 deprecates @alt and @longdesc.
Example mark-up
The current wiki appears to choke on an example of the markup described above. An example of Sander's proposal, using markup, is archived in the HTML WG's list archives.
Example implementation
For an object for which there are one or more equivalents for the user to choose from, the UA could indicate this by somehow hiliting the object (in a way that is only used to indicate the availablity of equivalents). To allow the user to choose from the available equivalents, the UA could provide their @title values and the (preferably transliterated) @type value through a contextual menu. The menu could for instance contain an "equivalents" entry, with those @title and @type values listed as submenus.
Pre-Existing Alternatives to ALT
Popular UAs already provide users with mechanisms to easily detect and alternate between equivalents:
Consider how <link> elements pointing to atom/RSS feeds are clearly indicated and made accessible in the chrome by Firefox, Opera, Safari and iCab (and IE7?).
- Consider how UAs allow users to switch the current document's view by selecting an alternate Style Sheet.
A Possible Variant
A new alt list; an <alt> element which must contain only <li> elements, each containing an equivalent, rerenced to by the author-preferred equivalent through @longdesc.
Evaluation
Pros:
- no need for authors to ensure each equivalent points to the correct author-preferred equivalent
- equivalents pointing to one author-preferred equivalent are grouped, which might be easier for UAs.
Cons:
- forces authors to group equivalents.
A modular solution
Alternate attributes
Some possible attributes for NMTokens and booleans to indicate whether content is displayed based on a users environment and an authors intentions:
- alt-langs (a space separated list of language codes indicating the display of content for any of the listed languages)
- alt-types (a space separated list of a MIME types indicating the display of content when the user’s defaults indicate preference for the included type)
- alt-media (a CSS media query indicating the display of content for when the environment meets or spoofs the media query)
- alt-declare (bool; to indicate an element should not be displayed immediately)
Other attributes:
- altfor(ALTLIST; a space-separated list NMTokens, each an alternate list, where only the first document fragment in each ALSTLIST that meets all necessary criteria is displayed at a time — with a mechanism for users to select from a list of other alternates meeting the criteria by the document fragment’s title)
- All elements sharing the same altfor attribute value are all part of the same alternate list
- Only one document fragment from the same alternate set should normally be displayed at one time (though UAs may provide mechanisms to display alternates side-by-side or in other ways their users might call for)
- Initial selection of the preferred alt from the alternate list is determined by the matching of alternate attributes to the user’s environment and secondarily by document order.
- authors use the title element to further differentiate alternate list members
- UAs should provide a mechanism for users to select from among other qualifying alternate list members by the alternate document fragments title attribute value
- UAs may allow users to spoof different environments to shape the alternates presented from the alternate list
- aris-describedby(IDREF)
- illustratedby (URI to associated a textual document fragment with a non-text media that is either referencing an embedded element with an IDREF hash or a full URI pointing to a non-text media resource)
An ALT element
An ALT element whose default CSS stylesheet display property is set to none
XForms Switch/Case
Use of XForms or an HTML5 native SWITCH and CASE elements for controlling alternative display
UA Norms
Recommend interactive visual UAs provide in-place swapping of alternates based on changes to a users environment or via direct user request through a contextual menu, for example. Consider the following sample code:
<img longdesc='#sandcastle' src='sandcastle' role='photograph' > <alt id='sandcastle' type='text/html' >The <em>whole</em> family created the biggest sand castle on the beach: big enough to move in.</alt>
In this case a UA might display the image according to the CSS styling of the document. However, if a user accessed the contextual menu for the IMG element’s frame, the UA should provide an alternates submenu with a "Long description (HTML)" item for the user to select. When selecting the item, the image is swapped out and in its place the UA renders the document fragment referenced by the long description (that document fragment is not displayed in the normal flow of the document because it is contained in an ALT element).
Discussion and evaluation
WG members should post feedback and other discussion to the WG’s list serve (the URI for the links below provides date information). Search on this email subject.
Thread: Marking up links to alternative versions of content
Thread: Marking up alternative versions of content
Thread: LONGDESC: some current problems and a proposed solution added to the wiki
Thread: Multilanguage title/alt