Minutes: Canvas Accessibility Sub Group Teleconference, 17 March 2014

Hello,

The minutes for the Canvas Accessibility Sub Group Teleconference 17 March 2014 are available in HTML and plain text below.  Supporting information for this Sub Group can be found on the wiki: http://www.w3.org/WAI/PF/HTML/wiki/Canvas

HTML: http://www.w3.org/2014/03/17-html-a11y-minutes.html

TEXT:

   [1]W3C

      [1] http://www.w3.org/

             Canvas Accessibility Sub-Group Teleconference

17 Mar 2014

   See also: [2]IRC log

      [2] http://www.w3.org/2014/03/17-html-a11y-irc

Attendees

   Present
          MarkS, Rik Cabanier, Rich Schwerdtfeger, jay munro

   Regrets
   Chair
          MarkS

   Scribe
          MarkS

Contents

     * [3]Topics
         1. [4]hit regions as Paths vs Pixels (Rik's email)
         2. [5]How events are handled. (Rik's email)
     * [6]Summary of Action Items
     __________________________________________________________

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

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

      [7] 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:
   [8]http://www.whatwg.org/specs/web-apps/current-work/multipage/
   the-canvas-element.html#canvas-mouseevent-rerouting-steps

      [8] 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

Summary of Action Items

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [9]scribe.perl version
    1.138 ([10]CVS log)
    $Date: 2014-03-17 22:53:21 $

      [9] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [10] http://dev.w3.org/cvsweb/2002/scribe/

Received on Tuesday, 18 March 2014 10:59:38 UTC