This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 8644 - Fallback mechanism for embedded content
Summary: Fallback mechanism for embedded content
Status: VERIFIED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML Canvas 2D Context (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.w3.org/TR/html5/text-level...
Whiteboard:
Keywords: a11y, a11ytf, a11y_text-alt
Depends on:
Blocks:
 
Reported: 2010-01-05 10:42 UTC by Gez Lemon
Modified: 2010-10-05 12:58 UTC (History)
6 users (show)

See Also:


Attachments

Description Gez Lemon 2010-01-05 10:42:05 UTC
1.  This section includes a number of mechanisms for embedding content, but the <img> and <area> elements are the only elements that include a specific mechanism for providing a short text alternatives (@alt). The need for a mechanism to include a short text alternative (label) for the embedded content is no different for elements such as embed, video, audio, canvas, MathML and SVG. Since the ability for the embedded content to provide a text alternative directly will vary across formats, content types and authoring practices, HTML5 should include support for the alt attribute or a similar mechanism (ex. aria-labelledby) for each of these elements and the conformance requirements regarding its presence should be consistent for each element.

2. From an accessibility perspective, HTML5 should describe a model for fallback content that allows the user to choose from any available fallbacks. The problem with specifying that fallback content should only be "used when an external resource cannot be used", is that it puts users in the position of having to guess about the accessibility of the content on different sites and to reconfigure their browser to find out if they guessed correctly. For example, an author on one site might embed captioned video that requires a plugin in order to be rendered with no fallback while an author on a second site uses the same plugin to include a video, omits captions, but provides fallback content that includes a text transcript of the video. The problem is that a deaf user who has the required plugin installed will get the captions on the first site, but will likely miss that there's no fallback on the second site entirely. Similarly, if the same user does not have the required plugin (or has turned it off so that they could access fallback content on another site), they end up getting nothing on site 1 and the fallback content on site 2.
Comment 1 Ian 'Hixie' Hickson 2010-02-05 20:25:56 UTC
Split part 2 into bug 8885.
Comment 2 Michael Cooper 2010-02-11 17:18:09 UTC
The HTML Accessibility Task Force intends to track these issues, per the proposal at http://lists.w3.org/Archives/Public/public-html-a11y/2010Jan/0245.html.
Comment 3 Ian 'Hixie' Hickson 2010-02-23 06:00:52 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: alt="" isn't about providing a short text alternative, it's about providing an alternative. It just so happens that a limitation of <img>, <area>, and <input> forces the alternatives for those particular elements to only be text, with no markup. However, that's a bug, not a feature.
Comment 4 Michael Cooper 2010-08-31 16:55:22 UTC
Bug triage sub-team accepts wontfix status of this bug. The core issue is represented by Bug 8885, and we will work on providing the needed information there.