This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13181 - Canvas does not allow mouse events to be directed to keyboard accessible objects in fallback content
Summary: Canvas does not allow mouse events to be directed to keyboard accessible obje...
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML Canvas 2D Context (show other bugs)
Version: unspecified
Hardware: All All
: P1 enhancement
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
Whiteboard: canvas RFE
Keywords: a11y, a11ytf, a11y_canvas, NotInW3CSpecYet, TrackerIssue
Depends on:
Reported: 2011-07-07 22:43 UTC by Rich Schwerdtfeger
Modified: 2012-11-15 17:35 UTC (History)
10 users (show)

See Also:


Description Rich Schwerdtfeger 2011-07-07 22:43:22 UTC
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:
Comment 1 Aryeh Gregor 2011-07-13 22:14:15 UTC
Didn't see this.  Promoting to P1 for the same reason as bug 13176 comment 3.
Comment 2 Michael[tm] Smith 2011-08-04 05:04:09 UTC
mass-move component to LC1
Comment 3 Ian 'Hixie' Hickson 2011-08-11 04:57:19 UTC
Do you have a URL to a page showing this problem?
Comment 4 Sam Ruby 2011-08-14 23:51:48 UTC
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.
Comment 5 Sam Ruby 2011-09-26 20:34:42 UTC
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.
Comment 6 Rich Schwerdtfeger 2011-09-26 21:34:33 UTC
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.
Comment 7 Sam Ruby 2011-09-27 23:42:30 UTC
(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.
Comment 8 Rich Schwerdtfeger 2011-09-29 15:35:55 UTC
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:
Comment 9 Ian 'Hixie' Hickson 2011-09-29 23:19:35 UTC
I'll speak with David about what he had in mind.
Comment 10 steve faulkner 2011-09-30 09:27:52 UTC
(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
Comment 11 Sam Ruby 2011-10-11 19:44:00 UTC
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:
Comment 12 Ian 'Hixie' Hickson 2011-12-09 23:24:58 UTC
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:

See also bug 13176.
Comment 13 Rich Schwerdtfeger 2012-01-11 17:56:56 UTC
Provide location information to assistive technology.
Comment 14 Rich Schwerdtfeger 2012-01-12 22:28:43 UTC
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.
Comment 16 Sam Ruby 2012-01-18 01:55:39 UTC
Changed status per:
Comment 17 Rich Schwerdtfeger 2012-01-20 22:58:35 UTC
 Additional information for the editor:
Comment 18 Ian 'Hixie' Hickson 2012-02-29 00:08:33 UTC
Reclosing since this is marked TrackerIssue, but note that I intend to address
this very shortly in a pretty comprehensive manner. See for details.
Comment 19 LĂ©onie Watson 2012-11-15 17:35:26 UTC
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.