13181 2011-07-07 22:43:22 +0000 Canvas does not allow mouse events to be directed to keyboard accessible objects in fallback content 2012-11-15 17:35:26 +0000 1 1 1 Unclassified HTML WG LC1 HTML Canvas 2D Context unspecified All All CLOSED NEEDSINFO canvas RFE a11y, a11ytf, a11y_canvas, NotInW3CSpecYet, TrackerIssue P1 enhancement --- 1 schwer ian eoconnor faulkner.steve ian laura.lee.carlson lwatson mike public-html-a11y public-html-admin public-html-wg-issue-tracking rubys public-html-bugzilla oldest_to_newest 50805 0 schwer 2011-07-07 22:43:22 +0000 This is an annoying problem with canvas. You have to have to apply keyboard and and mouse handlers on entirely different objects. The keyboard handler can be applied to a fallback content element that it belongs to, yet the pointing device handlers have to be applied to an entirely different element <canvas> for all the drawing objects in canvas. This could be addressed by creating defining drawing paths in canvas and binding them to canvas fallback content that they are associated with. The pointing device events could be dispatched to the fallback content element in response to a hit. If the drawing paths were assigned a z-order a simple pointInPath() call could be used to assess the hit. If no path is hit the event would pass down to the canvas element just as it does today. See the related bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13176 50981 1 ayg 2011-07-13 22:14:15 +0000 Didn't see this. Promoting to P1 for the same reason as bug 13176 comment 3. 52777 2 mike 2011-08-04 05:04:09 +0000 mass-move component to LC1 54668 3 ian 2011-08-11 04:57:19 +0000 Do you have a URL to a page showing this problem? 55007 4 rubys 2011-08-14 23:51:48 +0000 This bug was marked as P1 over 30 days ago, and still hasn't been RESOLVED. Editors: please RESOLVE it ASAP. NEEDSINFO and WONTFIX are valid resolutions for this part of the process. We simply want to get this bug to a state where we are prepared to accept change proposals should anybody be inclined to produce such. 57367 5 rubys 2011-09-26 20:34:42 +0000 We had an agreement for 1 month turn around for P1 bugs, and this is well past that point. As such, if anybody wishes to escalate this, they can do so at this time. 57373 6 schwer 2011-09-26 21:34:33 +0000 Ian, the only way to add a mouse handler in canvas is to bind it to the canvas element. However, keyboard events do go to the actual fallback content itself as representations of objects that are drawn on canvas. At this stage I can't: place three buttons in fallback content, and place them in the keyboard navigation order, and produce three corresponding drawing objects on canvas, and place a on click handler on the individual buttons in fallback content and receive the events when a click occurs on those buttons renderings on canvas directy. Rather I would have to place the onclick handler on the canvas element and perform the hit testing to dispatch the onclick to the fallback content elements. That is why the bug is filed. You don't have to write an example to prove it. Sam, if you feel it is necessary to escalate this please let me know. As far as I can tell this has not been closed or reopened. It is marked new. 57456 7 rubys 2011-09-27 23:42:30 +0000 (In reply to comment #6) > > Sam, if you feel it is necessary to escalate this please let me know. As far as > I can tell this has not been closed or reopened. It is marked new. If it is not a priority at this time, consider dropping the priority. If it is a priority, consider writing a Change Proposal. 57513 8 schwer 2011-09-29 15:35:55 +0000 Note: I spoke with David Bolter at Mozilla this week and he stated that they plan on implementing a solution for this by Q1 2012. That includes defect: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13176 57534 9 ian 2011-09-29 23:19:35 +0000 I'll speak with David about what he had in mind. 57552 10 faulkner.steve 2011-09-30 09:27:52 +0000 (In reply to comment #9) > I'll speak with David about what he had in mind. It would be best for all stakeholders if discussion occurs on a public mailing list not in secret 58072 11 rubys 2011-10-11 19:44:00 +0000 Reminder: a failure to escalate this bug by January 14th, 2012 will result in this bug no longer being treated as a last call comment: http://lists.w3.org/Archives/Public/public-html/2011Jun/0315.html 61357 12 ian 2011-12-09 23:24:58 +0000 BTW, it would be helpful if this wiki page (or another but with the same structure) could be filled in documenting precisely what it is that needs addressing here: http://wiki.whatwg.org/wiki/Canvas#Limitations_of_real-world_use_cases See also bug 13176. 62557 13 schwer 2012-01-11 17:56:56 +0000 Provide location information to assistive technology. 62624 14 schwer 2012-01-12 22:28:43 +0000 Issue Title: Provide canvas location and hit testing capability to fallback content Issue text: Provide a facility to assign location information for rendered child of fallback content and provide a way to do hit testing within the location of the rendered child such that pointer events may be dispatched to the rendered child. The dimensions defining the location may be provided to an assistive technology, such as a magnifier, to determine the objects location on the screen. Both bugs 13181 and 13176 must be associated with this issue. 62795 15 rubys 2012-01-16 23:13:49 +0000 https://www.w3.org/html/wg/tracker/issues/201 62830 16 rubys 2012-01-18 01:55:39 +0000 Changed status per: http://lists.w3.org/Archives/Public/public-html/2012Jan/0087.html 62968 17 schwer 2012-01-20 22:58:35 +0000 Additional information for the editor: http://wiki.whatwg.org/wiki/Canvas#Limitations_of_real-world_use_cases 64711 18 ian 2012-02-29 00:08:33 +0000 Reclosing since this is marked TrackerIssue, but note that I intend to address this very shortly in a pretty comprehensive manner. See http://wiki.whatwg.org/wiki/Canvas#Regions for details. 78363 19 lwatson 2012-11-15 17:35:26 +0000 Comment via Rich Schwerdtfeger: We have a hit testing proposal that includes paths that have been applied to canvas under the section Hit Regions. This allows an author to route mouse events to fallback content where the fallback element is bound to a closed path on canvas. Specifically, the addHitRegion has a control argument which refers to a fallback content element to which the events would be routed.