12306 2011-03-15 13:37:35 +0000 "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." While everyone can probably agree that alternative content is a good idea when f 2012-11-15 17:18:09 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified Other other CLOSED WONTFIX http://www.whatwg.org/specs/web-apps/current-work/#the-canvas-element a11y, a11ytf, a11y_canvas P3 normal --- 1 contributor contributor annevk ayg bhawkeslewis eoconnor faulkner.steve hsivonen ian jackalmage james jfoliot laura.lee.carlson lwatson mike mjs public-html-a11y public-html-admin public-html-wg-issue-tracking schwer w3c zcorpan public-html-bugzilla oldest_to_newest 46717 0 contributor 2011-03-15 13:37:35 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html Section: http://www.whatwg.org/specs/web-apps/current-work/#the-canvas-element Comment: "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." While everyone can probably agree that alternative content is a good idea when feasible, when considering what people are using the canvas for, which seems to fit the examples provided in the first paragraph well, the wording "they must" doesn't make any sense to me. How on earth do you expect authors to provide alternative content for a game or a complex visualization? I suggest either softening the first sentence up or just whacking it entirely. Otherwise thanks for a nice and clear spec. :) Posted from: 77.243.62.134 User agent: Mozilla/5.0 (X11; U; Linux i686; da-DK; rv:1.9.2.15) Gecko/20110303 Ubuntu/10.10 (maverick) Firefox/3.6.15 48228 1 ian 2011-05-06 20:11:50 +0000 Anyone have an opinion on this that I should know about before I resolve the bug? :-) 48238 2 faulkner.steve 2011-05-06 20:31:08 +0000 (In reply to comment #1) > Anyone have an opinion on this that I should know about before I resolve the > bug? :-) yes, I request you do not change the spec wording at this time, if you have a change in mind, send a diff to public html for review. 48248 3 bhawkeslewis 2011-05-06 21:25:55 +0000 (In reply to comment #1) > Anyone have an opinion on this that I should know about before I resolve the > bug? :-) It is not obvious that games and complex visualizations cannot be made accessible using sub-DOM in combination with other techniques. See also: http://lists.w3.org/Archives/Public/public-html/2011Apr/0801.html 48364 4 jackalmage 2011-05-09 17:39:16 +0000 I think the note should be softened as well. While Benjamin's email points out many interesting methods that can be explored to expose some types of visualizations to certain kinds of non-visual users, they are still limited (most wouldn't apply to spiders) and most are both experimental and fairly complex, rendering them unsuitable for authors at this time. Even if we had the hardware APIs necessary to implement an audio-haptic mapping of my mandelbrot set generator (we don't), I wouldn't know how to use it properly. This is the sort of thing that still requires a ton of research and study, and likely will only be truly usable when it's driven by a sufficiently intelligent automatic system rather than implemented manually by authors. 48435 5 w3c 2011-05-10 15:17:22 +0000 Adding the a11yTF keyword. The bug triage sub-team thinks we should keep an eye on this bug, the current wording of the spec shouldn't be changed. 48574 6 schwer 2011-05-17 21:51:33 +0000 The right way to do this is to expand the Canvas 2D API spec. to handle clickable regions to support hit testing. I mentioned this on the public-html list. Essentially, we would define a closed path for the bounds of an object and associate it with an element in fallback content. It would require canvas implementations to manage the last drawn of an object to deal with overlapping regions. So you would define a path and then call something like: setClickableRegion(element); Then canvas would be able to process a ptInPath on the mouse, for clicks, onmouseover, and onblur and route the event to the element in fallback content that processes the keyboard events for the drawing object. The bounds of the object would supply the accessibility API mapping for the element. This also provides the author with ability to do canvas managed hit testing that is not limited to the shapes defined by image maps and in fact the ability to bind the the object to richer HTML objects in fallback content would make this even more powerful. 52333 7 mike 2011-08-04 05:00:25 +0000 mass-moved component to LC1 60798 8 ian 2011-12-02 17:52:16 +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: Rejected Change Description: no spec change Rationale: If I make this change it'll just get a revert request. I agree the change needs to be made, but I don't care enough to go through the motions here. If anyone wants to escalate this I'd be happy to work with you to provide a patch. 78360 9 lwatson 2012-11-15 17:18:09 +0000 Comment via Rich Schwerdtfeger: This text exists in the canvas element specification: "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."