Bug 8885 - Fallback mechanism for embedded content
Summary: Fallback mechanism for embedded content
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML Canvas 2D Context (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: dmacdona
QA Contact: HTML WG Bugzilla archive list
Keywords: a11y
Depends on: 8657
Blocks: 10709
  Show dependency treegraph
Reported: 2010-02-05 20:25 UTC by Ian 'Hixie' Hickson
Modified: 2013-01-16 14:23 UTC (History)
10 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Ian 'Hixie' Hickson 2010-02-05 20:25:44 UTC
(Split from bug 8644.)

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
Comment 1 Ian 'Hixie' Hickson 2010-02-14 10:38:59 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:

Status: Did Not Understand Request
Change Description: no spec change
Rationale: I don't understand. Could you elaborate?

The original bug was about this section:

I first presumed that the issue here was intended to apply to all the elements in that section: audio, canvas, embed, iframe, img, math, object, svg, and video.

I can't find anything in the spec that says "used when an external resource cannot be used", however, so I'm not sure what this is referring to. <object> and <img> seem to be the only elements that use a mechanism like this, so maybe this only applies to those? But the text refers to <video>, so maybe that's what it means?

The problem described ("For example...") is a valid problem, but it doesn't seem to highlight a problem with HTML, so much as a problem with an authoring practice of an inexperienced author. Things like transcripts should be available to all users all the time, not hidden as accessibility "fallback"s.

I'm at a loss as to what the problem is that is being described here. Any help would be greatly appreciated.
Comment 2 Michael Cooper 2010-08-31 14:06:02 UTC

The bug triage sub-team believes the HTML A11Y TF should take up this bug. Additional notes may follow in a separate comment.
Comment 3 Michael Cooper 2011-02-01 16:15:18 UTC
HTML A11Y TF Action 66 http://www.w3.org/WAI/PF/HTML/track/actions/66 and Action 90 http://www.w3.org/WAI/PF/HTML/track/actions/90 are meant to provide the information for this bug.
Comment 4 dmacdona 2012-12-20 16:08:51 UTC
I think the idea of fallbacks is good, the bug is asking for html5 to “describe a model for fallback content that allows a user to choose from any available fallback” 

So it appears they would like for there to be some way to choose from one of the fallbacks. I don’t think the bug is well articulated. I don’t know if it is something we want to prescribe ... and to my knowledge in the accessibility world there is not an emerging single best practice to point towards... WCAG does not require it. So I don’t think this bug needs to be pursued as it stands... perhaps in an html next, someone can create a fully baked recommendation extension that could be rolled in... but that would be a separate matter.
Comment 5 Michael Cooper 2013-01-16 14:23:26 UTC
HTML A11Y TF has decided it no longer needs to track this bug.