This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
(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.
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.
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.
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.