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:


Note You need to log in before you can comment on or make changes to this bug.
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: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13176
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: http://lists.w3.org/Archives/Public/public-html/2012Jan/0087.html
Comment 17 Rich Schwerdtfeger 2012-01-20 22:58:35 UTC
 Additional information for the editor: http://wiki.whatwg.org/wiki/Canvas#Limitations_of_real-world_use_cases
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
http://wiki.whatwg.org/wiki/Canvas#Regions 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.