8885 2010-02-05 20:25:44 +0000 Fallback mechanism for embedded content 2013-01-16 14:23:26 +0000 1 1 1 Unclassified HTML WG pre-LC1 HTML Canvas 2D Context (editor: Ian Hickson) unspecified PC All RESOLVED NEEDSINFO a11y P2 normal --- 8657 10709 1 ian david100 cooper gez.lemon hans.hillen ian mike public-html-a11y public-html-admin public-html-wg-issue-tracking silviapfeiffer1 w3c public-html-bugzilla oldest_to_newest 31500 0 ian 2010-02-05 20:25:44 +0000 (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 2. 32049 1 ian 2010-02-14 10:38:59 +0000 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: Did Not Understand Request Change Description: no spec change Rationale: I don't understand. Could you elaborate? The original bug was about this section: http://www.w3.org/TR/html5/text-level-semantics.html#embedded-content-1 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. 38324 2 cooper 2010-08-31 14:06:02 +0000 http://lists.w3.org/Archives/Public/public-html-a11y/2010Aug/0124.html The bug triage sub-team believes the HTML A11Y TF should take up this bug. Additional notes may follow in a separate comment. 44964 3 cooper 2011-02-01 16:15:18 +0000 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. 80442 4 david100 2012-12-20 16:08:51 +0000 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. 81480 5 cooper 2013-01-16 14:23:26 +0000 HTML A11Y TF has decided it no longer needs to track this bug.