Bugzilla – Bug 8885
Fallback mechanism for embedded content
Last modified: 2013-01-16 14:23:26 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
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.
The bug triage sub-team believes the HTML A11Y TF should take up this bug. Additional notes may follow in a separate comment.
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.
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.
HTML A11Y TF has decided it no longer needs to track this bug.