This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Currently the HTML 5 spec advises authors that it OK to place fallback content in the canvas element: When authors use the canvas element, they must also provide content that, when presented to the user, conveys essentially the same function or purpose as the bitmap canvas. This content may be placed as content of the canvas element. The contents of the canvas element, if any, are the element's fallback content. http://dev.w3.org/html5/spec/the-canvas-element.html#the-canvas-element advsing authors to put fallback inside the canvas element is demonstrably bad for users of canvas supporting browsers who cannot access the rendered content of the canvas bitmap. example:http://www.whatwg.org/issues/data.html?period=1 contains a canvas based graph that has its fallback content (a html data table) inside the canvas element. No firefox/opera/safari/chrome users can access it unless they view source. The fallback content is not even displayed to IE users. As the canvas element is widely supported and being used, the advice in the spec should reflect the reality of todays browser implementations.
I'm not disputing the current state of affairs, and the prospective advice in the spec doesn't work yet. However: A while ago, adding more API surface to <canvas> was suggested as a solution to the current accessibility defects of <canvas>. Such new API surface wouldn't be supported in browsers that have already been shipped. Why is the solution put forward in the spec being held to a different standard? If <canvas> is inaccessible in shipped browsers, surely you are overconstraining the problem if you require solutions to work in shipped browser releases if there is no such solution. Or are you just asking for a special note that this particular paragraph in the spec is prospective at this time as opposed to being retrospective like some other paragraphs of the spec? In general, the authoring advice in the spec is written for the time when browsers implement the HTML5 spec.
hi henri, I am not holding anything to a different standard,I am saying following this authoring advice causes problems, this should be noted in the spec, so authors don't who follow the advice think they are providing an accessible fallback or the spec should be changed to better reflect how browsers support fallback. I would hope that anywhere in the html5 spec where authoring advice results in a demonstrably worse user experience be considered a bug. (In reply to comment #1) > I'm not disputing the current state of affairs, and the prospective advice in > the spec doesn't work yet. However: > A while ago, adding more API surface to <canvas> was suggested as a solution to > the current accessibility defects of <canvas>. Such new API surface wouldn't be > supported in browsers that have already been shipped. Why is the solution put > forward in the spec being held to a different standard? > If <canvas> is inaccessible in shipped browsers, surely you are > overconstraining the problem if you require solutions to work in shipped > browser releases if there is no such solution. > Or are you just asking for a special note that this particular paragraph in the > spec is prospective at this time as opposed to being retrospective like some > other paragraphs of the spec? In general, the authoring advice in the spec is > written for the time when browsers implement the HTML5 spec.
This was escalated to ISSUE-74 as described in bug 7011. *** This bug has been marked as a duplicate of bug 7011 ***
Per the proposal at http://lists.w3.org/Archives/Public/public-html-a11y/2010Jan/0245.html, the HTML A11Y TF does not plan to formally work on this issue at this time. This does not mean the TF has no interest in it, but does not have immediate plans to work on it. The TF may review the issue in the future.
This bug predates the HTML Working Group Decision Policy. If you are satisfied with the resolution of this bug, 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 This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.