Minutes: Canvas Accessibility Sub Group Teleconference, 14 APR 2014

Hello,

The minutes for the Canvas Accessibility Sub Group Teleconference 14 APR 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/04/14-html-a11y-minutes.html

TEXT:

    [1]W3C

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

             Canvas Accessibility Sub-Group Teleconference

14 Apr 2014

   See also: [2]IRC log

      [2] http://www.w3.org/2014/04/14-html-a11y-irc

Attendees

   Present
          Mark Sadecki, PLH, Janina, Rik Cabanier, Jay Munro

   Regrets
          Rich Schwerdtfeger

   Chair
          Mark Sadecki

   Scribe
          Mark Sadecki

Contents

     * [3]Topics
         1. [4]Update from Mark
         2. [5]W3C/WHAT WG diff analysis (for cherry picking and
            bug filing)
         3. [6]Mouse event (re)targeting
     * [7]Summary of Action Items
     __________________________________________________________

   <trackbot> Date: 14 April 2014

Update from Mark

W3C/WHAT WG diff analysis (for cherry picking and bug filing)

   [8]http://lists.w3.org/Archives/Public/public-canvas-api/2014Ap
   rJun/att-0011/14-canvas_diff_analysis.html

      [8]
http://lists.w3.org/Archives/Public/public-canvas-api/2014AprJun/att-0011/14-canvas_diff_analysis.html

   Added method clearHitRegions()
   [9]http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/#
   dom-context-2d-clearhitregions

      [9]
http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/#dom-context-2d-clearhitregions

   RC: WHAT WG already said they will not be making the change
   from pixels to paths.
   ... WHAT WG has a process for using a scratch bitmap to manage
   regions. We are using paths for that
   ... clearRect has the same effect as clearHitRegions()

   <plh> "Clear regions that cover the pixels in pixels in the
   canvas element."

   JM: clearRect is still in ours as well

   MS: clearHitRegions is a more elegant way of clearing hit
   regions.

   PLH: comparing clearRect and clearHitRegions. Why the
   difference re garbage collection

   <plh> "Garbage-collect the regions of the canvas element."

   <plh>
   [10]http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/
   #dom-context-2d-clearhitregions

     [10]
http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/#dom-context-2d-clearhitregions

   <plh>
   [11]http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/
   #dom-context-2d-clearrect

     [11]
http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/#dom-context-2d-clearrect

   PLH: think we should take out the ref to garbage collection in
   clearHitREgions

   AGREED

   [12]http://www.whatwg.org/specs/web-apps/current-work/multipage
   /the-canvas-element.html#the-control-represented-by-a-region

     [12]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#the-control-represented-by-a-region

   RC: I don't think we need to add WHAT WG step 4 (control
   represented by a region). covered by our step 3.

   AGREED

   [13]http://www.whatwg.org/specs/web-apps/current-work/multipage
   /the-canvas-element.html#clear-regions-that-cover-the-pixels

     [13]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#clear-regions-that-cover-the-pixels

   RC: We have a list of paths, so we don't need such an algorithm

   AGREED

   [14]http://www.whatwg.org/specs/web-apps/current-work/multipage
   /the-canvas-element.html#dom-context-2d-addhitregion

     [14]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-addhitregion

   RC: we use paths, so this rule doesn't apply to our spec

   MS: Clipping regions

   RC: That must have been added in the last couple weeks
   ... it makes sense. Not sure how we would implement this.
   ... a hit region can be clipped
   ... i think we should add this to our spec but reword it so
   that it deals with path and not pixels
   ... "remove from specified path..."

   PLH: how will you clip pixels if you are working with path

   RC: Clipping area is already based on path
   ... test the hit region and all their clipping paths
   ... unless we change addHitRegion to combine the clipping
   region with the current path

   JM: the path resolves to pixels in our spec, so the wording can
   be similar
   ... just not refer to fillRule

   [15]http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/
   #the-region-for-a-pixel

     [15]
http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/#the-region-for-a-pixel

   <plh> to be added "Remove from specified pixels any pixels not
   contained within the clipping region."

   JM: I think path would work there.

   RC: I don't think this needs to change

   JM: should we remove the underscore

   RC: I actually think we should change this to path. Link it to
   path

Mouse event (re)targeting

   [16]http://www.whatwg.org/specs/web-apps/current-work/multipage
   /the-canvas-element.html#dom-mouseevent-region

     [16]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-mouseevent-region

   PLH: not sure if its easy to change the target of an event
   before its dispatched

   RC: This would be really tricky to implement
   ... in FF it would be a tremendous amount of work

   PLH: Why exactly would that be?

   RC: browsers default behavior, its done in C++
   ... have to teach source algorithms about canvas
   ... probably won't have an implementation in 6 months
   ... makes sense to do it this way, but it would take a while to
   get it implemented

   PLH: WHAT WG attempts to do this without modifying DOM event
   spec
   ... no magic here
   ... other way would be to dispatch event, then when you hit
   canvas, dispatch a new event.
   ... or, once you reach canvas, change the target. that is like
   magic, not specified anywhere

   JM: Jatinder said we would need to talk to ?? Jacob

   PLH: if we move the mouse over a region, which has a control,
   now I don't target that to canvas, it targets the control

   RC: it bubbles up until it gets captured
   ... as you are moving over it, the event target changes.
   ... event retargeting is not as simple as it seems
   ... previously we considered not sending it to fallback
   contact, just send it to canvas and let the developer manage
   ... that might still be forward compatible.

   PLH: i think we would have to add a method
   ... to help the developer

   RC: it would be the region ID
   ... would be filled in automatically

   JM: They would get the mouse event from canvas and if the ID
   matches a control, there is a region

   RC: Rich said he wanted to see mouse enter and leave

   PLH: what was wrong with not retargeting the event?

   RC: That would work for me

   PLH: i say we do it this way and get feedback from
   implementers. sounds like this would be easier and the burden
   on authors is not that much
   ... doesn't change the target during mouse move. that is a win
   for me
   ... do we want session id or control

   RC: I think just the ID is enough

   PLH: is there a case where dev would be interested in region ID
   and not the control

   JM: in L1, it sounds like that would work. In L2, that might
   now work

   PLH: might be worth it to add a note saying that we won't be
   adding support event re-routing
   ... just support for region id

Summary of Action Items

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [17]scribe.perl version
    1.138 ([18]CVS log)
    $Date: 2014-04-15 15:03:49 $

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

Received on Wednesday, 16 April 2014 20:21:48 UTC