Minutes: Canvas Accessibility Sub Group Teleconference, 31 March 2014

Hello,

The minutes for the Canvas Accessibility Sub Group Teleconference 31 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

*NOTE:*  The URL for the minutes deviates from the standard pattern due to an
earlier meeting that took place in the same channel.  The standard pattern will
resume at the next meeting.

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

TEXT:

   [1]W3C

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

             Canvas Accessibility Sub-Group Teleconference

31 Mar 2014

   See also: [2]IRC Log

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

Attendees

   Present
          Rich_Schwerdtfeger, Mark_Sadecki, Rik Cabanier, Janina
          Sajka, Jay Munro, Jatinder Mann

   Regrets

   Chair
          MarkS

   Scribe
          MarkS

Contents

     * [3]Topics
         1. [4]Review progress from previous week
         2. [5]control Required or not via Jatinder
         3. [6]Exposing the hit region list
         4. [7]PointerEvents and event handling
     * [8]Summary of Action Items
     __________________________________________________________

   trackbot, start meeting

   <trackbot> Date: 31 March 2014

   <scribe> Meeting: Canvas Accessibility Sub-Group Teleconference

   <scribe> Scribe: MarkS

Review progress from previous week

   JM: Pixels to Path work is complete.
   ... I took out ID but based on discussion, I put that back in
   as required.
   ... I need feedback on the interface for accessing hit regions
   and hit regions list

   ->
   [9]http://lists.w3.org/Archives/Public/public-canvas-api/2014Ja
   nMar/0191.html hit region list interface

      [9] http://lists.w3.org/Archives/Public/public-canvas-api/2014JanMar/0191.html

   JM: on hitRegionList, to access items, we don't currently know
   what the index will be. I added HitREgionOptions to accomplish
   that, but I'm not sure if that is going to work for
   implementers
   ... looking for feedback on that approach

   RC: I'm not sure that we need this.

   JMann: you can keep your own list in JS

   JM: I put ID back in, I had taken it out, but I referenced
   Level 2 and saw that it was referenced in the WebIDL. I added
   it back but took out required

control Required or not via Jatinder

   JMann: should we require ID or not? Last call, we said we
   shouldn't, waiting to hear from Rik on that.
   ... you can always use the ID of the control

   RC: What if there is no control, like if you are drawing a
   dialog on top of an existing button.

   JMann: so do we want to support the unbacked regions?

   RC: one or the other, or both

   JMann: so for Level 1, we won't support unbacked region but
   because we want to be forward compatible, we ...

   RC: how will we remove an item, since that requires an ID

   JMann: for Level 1, control is required.
   ... for Level 2, control will be optional

   RC: it sounds like you won't be able to change that for Level 2

   JMann: to be forward compatible with Level 2, we need to make
   control optional.
   ... which is how the spec has it.

   RC: but they cannot both be absent

   JM: correct, I suggested that in my email
   ... I will add that to the spec then to clarify

   JS: Should look for precedent on how that should be written.
   One of them will be required,

   JM: do we want to say the reverse is true? if there is no ID,
   you must have a control? I'll research that.

   JS: we should at least have the concepts out, can perfect it
   later

   JMann: to remove a hit region, ID is required.

   RC: removing a control will also do that.

   JM: in the WebIDL it says "remove hit regions(ID)" probably
   need to make that match
   ... and if we want to remove it, you need to specify an ID

   JMann: Level 2 removeHitRegion take an ID. so it will match the
   spec text

   RC: it will be a regression issue

   <JatinderMann>
   [10]http://www.w3.org/html/wg/drafts/2dcontext/master/#hit-regi
   ons

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

   <JatinderMann>
   [11]http://drafts.htmlwg.org/2dcontext/master/#2dcontext

     [11] http://drafts.htmlwg.org/2dcontext/master/#2dcontext

   JM: is that the nightly? I'm not seeing that. The WebIDL and
   the spec text both say they take multiple options

   <JatinderMann> void removeHitRegion(DOMString id);

   <jaymunro>
   [12]http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas/

     [12] http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas/

   RC: we need to delete that branch or ask someone to turn it
   off. we want to make sure L1 and L2 match

   JM: I'll see who I have to contact to fix that

Exposing the hit region list

   ->
   [13]http://lists.w3.org/Archives/Public/public-canvas-api/2014J
   anMar/0191.html exposing hit region list

     [13] http://lists.w3.org/Archives/Public/public-canvas-api/2014JanMar/0191.html

   MS: currently is no way to reference an item in the list if we
   don't know if it has an ID or a control

   JM: if hitRegionList returned hitREgionOptions with the right
   one...
   ... we're only working with ID and control in L1
   ... what will we be using it for

   RC: i think for now, we should leave it up to the author

   JM: to track the list himself

   RC: is someone strongly in favor of having a list?

   JMann: This was raised by Jacob. You're right, the author can
   keep their own list.
   ... Jacob was concerned about being able to update existing
   items I think.
   ... we could have a getRegions that returns a list, or an
   attribute on which the list existed, but that could be overkill
   ... the downside is that if I'm not keeping track, and I add a
   bunch of regions, it could get difficult to manage.
   ... do we think its common to remove hit regions? like a use
   case in a game?

   RS: yeah, sure. You might also be resizing something?
   ... I've seen canvas be used for flowcharts. dropping objects,
   resizing objects, etc. I can see someone doing that.
   ... would the author be more likely to reference them by
   control or ID

   JMann: we give you the current path and the ID. can't change
   fill rule, can't change path,e tc. I wonder if this becomes
   more important in the L2 spec.
   ... currently, I can just remove and add a new one. you can
   remove by ID, or remove the control itself.
   ... then create a new one
   ... you can walk through the DOM and remove the controls to
   accomplish this.

   RS: we talked about this in ARIA RE: Webcomponents. I would
   limit the number of ways you can reference things, at least for
   L1

   JMann: Jacob raised this from an API design POV. IS there an
   advantage to exposing the list to developers. Probably not
   beyond the developer who can maintain his own list, or walk the
   DOM
   ... It may not be worth the additional complexity

   JM: You were talking earlier about changing the hit region.
   wouldn't that just happen if you make a new path and assign the
   control to the new path. wouldn't that replace the old one?

   RC: the other one would draw on top.

   JM: If you create a new path, then call addHitRegion with an ID
   that was previously used, shouldn't it just replace the old
   one?
   ... If you don't redraw the canvas, the old path will still be
   there? ok.

PointerEvents and event handling

   JMann: talking to Jacob on this one. Wherever we say mouse
   event, we should say pointer event.

   RS: are new pointer events implemented in all the browsers?

   JMann: I know Chrome and IE or Apple and IE. not sure

   RS: did we agree what events we wanted to support? focus? blur?
   ... mousein etc
   ... did we want to pass the pointer position through to the
   fallback element or the hit region.

   JMann: looking t what we have now.

   RC: it currently doesn't say which are supported
   ... it doesn't say anything about that
   ... it inherits behavior from HTML

   RS: does the canvas element handle all of this? do we need all
   the mouse events?

   JM: looking at WHAT WG spec, their pointer events look more
   like our Level 2. more specific pointer event support.

   RC: yes, they have made a lot of changes there. It seems
   unclear what it is doing. Seems like they are adding support
   for WebApps or something
   ... waht should happen when you click on a hyperlink (fallback
   content) for instance
   ... we could send the events to the canvas element, which would
   still be forwards compatible.

   RS: do you have to do all the hit testing yourself?

   RC: no, but the author would write the code to handle certain
   mouse events or pass it through to the fallback
   ... just standard event handling.
   ... with the ID of the hit region
   ... this is the ID of the hit region.

   RS: would need to reference the control by ID too

   JM: seems like having a standard interface to do this (ref by
   ID) is ideal. Argument for making ID required.

   RS: the only thing that worries me about ID, in ARIA we talked
   about using query-selectors to reference stuff in shadow dom
   ... worry about limiting this to just ID

   RC: if we say an ID is not required, you just wouldn't get the
   event handling, still get accessibility

   RS: I think it would be better to just focus on the hit testing
   behavior rather than how to reference elements in case we want
   to change that in the future

   RC: seems like a big change

   RS: I think managing the list of hit regions, with everything
   in 2.0 might be better to just focus on the dispatching.

   RC: that is the hardest part

   RS: isn't there a javascript dispatch event that you can use to
   retarget it?

   RC: harder from the UA perspective. easy from JS. lots of
   special case handling

   JMann: I wanted to hear from implementers about whether or not
   this would be a difficult approach, bad for performance, etc.

   RC: It seems like its easy until you have to do event
   retargeting.
   ... may be an issue when things scale to hundreds of hit
   regions.
   ... if the browser doesn't manage it, the author does.

   JMann: so today, a listener on the fallback will not get the
   event.

   RS: the authors need to supply an ID if they want to control
   that.
   ... I would use the same ID i used in the fallback content to
   make it easier.

   JMann: seems like we should add that ability.

   MS: how about if we specify that if you specify the control's
   ID but not the hit regions' ID, the hit regions automatically
   gets the same ID as the fallback element?

   RS: not a bad idea

   RESOLUTION: canvas element will handle event handling from the
   hit testing, and will not handle dispatching the event.

   RS: what about remove a node? in terms of hit region
   management.

   JM: if you set the control('s ID) and that was duplicated in
   the ID of the hit regions. Why would you need both?

   RS: wouldn't if you could guarantee they were the same

   JMann: why not just require the controls's ID
   ... right now they have to control the mapping

   RS: any compatibility issues when we go to L2
   ... may also have to reference things by selectors.
   ... i think webcomponents will affect this.

   RC: should we wait until this is ready?

   RS: imagine a web component in the fallback content of
   canvas...

   JM: so hit region interfaces are being left out for now and we
   are not specifying whether ID or control are required or not
   until we work through this issue.

   JS: we are going to get pressure from HTML WG on extra time for
   this

   RS: I think we are making great progress and are almost done
   here.

   RC: may be we should add an API to clear all hit regions.
   ... add clearRect() back in
   ... its still in the WHAT WG spec

   RS: lets add clearRect() back in. can do a clearRect() on the
   entire canvas to remove all the hit regions.

   JM: its still in L2 that way

   RC: its a little funky

   RS: what about clearHitRegions()

   RC: I like that

   JM: OK, so we are going to add clearHitRegions, not clearRect
   and change mouse to pointer events

   RC: I don't think we should do pointer event change just yet.

   RS: we need to talk to other browsers to see if they are
   supporting pointer events yet.

   JM: ID and control are still up in the air.

   RS: I think we should leave it up to the author to manage ID's
   etc.

Summary of Action Items

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [14]scribe.perl version
    1.137 ([15]CVS log)
    $Date: 2014-04-01 22:09:04 $

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

Received on Tuesday, 1 April 2014 22:13:45 UTC