Canvas Accessibility Sub-Group Teleconference

hit regions as Paths vs Pixels (Rik's email)

http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/#hit-regions

MS: What does WHAT WG say?

RC: It says pixels too
... it doesn't really matter, but when you start doing calculations, it will be much harder to do those on pixels rather than paths.
... like determining if there are any pixels on the canvas (if not, triggers clearing of the region list)

MS: Will that cause any issues since Path is not in spec?

RC: no, because we already have the current default path.

JM: Will it affect how it gets implemented once Path gets developed

RC: no
... it will be change the spec a bit. clear region that covers the pixels.

MS: removeHitRegion refers to pixels too

RC: and the garbage collection algorithm
... step 11

JM: so remove that completely?

RC: yes, I think so
... clear regions that cover the pixels
... region for a pixel should stay
... as it is, you have to transcribe the canvas to a bit map and analyze every pixel. expensive operation.

MS: would have to change addHitRegion step 7 which refers to pixels as well

RS: Nobody wants to start checking pixels

RC: reword to "Hit Region's path"

MS: Step 11 in addHitRegion

RC: that one goes away. That is the problem step.

How events are handled. (Rik's email)

RC: set an email to WHAT WG and Ian made a bunch of changes to how events are handled. Not quite sure he answered my question.

RS: the event just goes to the object that's registered
... oh, so there is no handler? It will bubble anyway

RC: the event target is the canvas, not the fallback element.

RS: it should

RC: the spec doesn't say that

RS: We need to work on the spec to make it say that then

RC: It currently says, "change the target"

RS: Redirect? Dispatch the target?

RC: that doesn't change the target attribute on the event.
... if you don't change the handler, you can end up sending the event to the fallback when you want to send it to canvas

RS: we need to specify that it bubbles up until an element is ready to handle the event.

RC: Robert Ocallahan had question about default action.
... would be difficult to implement

RS: you would have to write a handler.
... the user could always create the handler
... nothing in the spec says we have to have a default action
... cynthia shelley wanted to have something like that, but we couldn't et enough implementations for aria 1
... i think this is a reasonable expectation for now.

MS: any future compatibility issues if we introduce this in L2

RS: yeah, maybe. we would have to figure out where it goes.
... you would have to have a handler on it to activate it.

RC: if you click on upper corner of the region...

RS: no fallback elements, canvas is one single object
... should be relative to the canvas
... set the location, and have the offset for x,y be within the canvas element.

RC: the spec doesn't say recalculate where you click.

RS: if you have a div in html, the x,y position is relative to that div. shouldn't it be the same?

RC: if you want that, it needs to be in the spec

JM: if someone can sketch it out, I can write it.

RS: in my mind, the x, y position would be relative to the bounding rectangle for that button.
... if nothing hit the region the location would be based on it relative to the bounding box of the canvas.

RC: Ian made a bunch of changes that we might want to pull in as well.
... he also refers to other parts of the HTML spec as well. touch events... he changed how click handlers work.
... do you want to have mouse in and out events too?

RS: well, we know when the mouse is over the region.

RC: i can see you wanting that, but it would be a lot of work to add on on mouse in and out

RS: I think the author would want that... but I can see how it would be additional work.

RC: we could inform the author

RS: We could have the keyboard handler and the mouse handler in the same place
... so the layout engine knows where these things are?

RC: not really

RS: oh...

RC: it would get really complex
... i have been doing some experiments. on the canvas element itself, I can add a handler that tests if the mouse is over a hit region.

RS: To get this done, for canvas 1 we would handle clicks, and general mouse events, (move) save mouse in and out for canvas l2.

RC: seems like Ian's changes would make it much more difficult to implement.

RS: if the user moves the mouse over the canvas, accessible object from point will not work.

RC: i think it will. that is how the a11y tools do it.

<cabanier_> link to updated event handling: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#canvas-mouseevent-rerouting-steps

JM: would the author be responsible for recording the location of the region so that he can perform calculations for determining mouse in and mouse out?

RC: yeah

JM: OK, so when he calls addHitRegion