Minutes: Canvas Accessibility Sub Group Teleconference, 03 March 2014

Hello,

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

TEXT:

   [1]W3C

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

             Canvas Accessibility Sub-Group Teleconference

03 Mar 2014

   See also: [2]IRC log

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

Attendees

   Present
          Mark Sadecki, Rich Schwerdtfeger, Rik Cabanier, Jatiner
          Mann, Jay Munro, Janina Sajka

   Regrets
   Chair
          MarkS

   Scribe
          MarkS

Contents

     * [3]Topics
         1. [4]Walk through Hit Regions spec to discuss priority
            for implementation
         2. [5]Custom mouse cursors
         3. [6]fill rule
         4. [7]Possible Testing and/or Coordination meeting at
            HTML WG F2F
     * [8]Summary of Action Items
     __________________________________________________________

   <trackbot> Date: 03 March 2014

   <scribe> scribe: MarkS

Walk through Hit Regions spec to discuss priority for implementation

   [9]http://lists.w3.org/Archives/Public/public-canvas-api/2014Ja
   nMar/0159.html

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

   Do we plan on supporting nested regions with
   hierarchical/ancestor relationships in L1?

   RC: I had not implemented that yet. No parent ID
   ... this is about how multiple regions on the page behave.

   RS: Is this like a Z-order?

   RC: This is a parent ID. Inherit z-order and other
   ... This is a pseudo DOM
   ... the hierarchy is ignored in the fallback content, the
   relationship would be established using this parent ID
   ... where it bubbles, it follows the DOM order.

   RS: mouse event will bubble up the parent tree, like anything
   else in the DOM.
   ... with Hit Testing, it would be nice if you have a parent
   region and a child, you would think that the child would get
   first chance to record the hit, otherwise bubble up to the
   parent.

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

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

   <richardschwerdtfeger> A hit region A is an ancestor region of
   a hit region B if B has a parent and its parent is either A or
   another hit region for which A is an ancestor region.

   RS: lets say I had a container div in the fallback content, and
   then I had a B inside of it, I might have multiple children,
   each of those would have a hit region. The parent would contain
   all of those items. You would have to go through...

   RC: First you set up the bigger region, then the smaller one.

   RS: so its up to the author

   RC: the fallback nesting content does not need to match.
   ... subtract the children's pixels from the parent.

   RS: If its a list, the children have to be higher in the list
   than their parent in order to get a hit.

   RC: the algorithm takes care of that.
   ... is the parent ID necessary for L1

   RS: Do we have anything on here that says, when something is
   drawn it goes to the top of the region list?

   19 Clear regions that cover the pixels in region's set of
   pixels on this scratch bitmap.

   RC: I think this is for the AAPI to understand the relationship
   between regions.

   RS: You have a new hit region, bind it to the element. Your
   fallback content will have the structural hierarchy that will
   be used in the AAPI. Since the options are in the listbox,
   there is an implied relationship there.
   ... The roles are not enough for the AAPI.
   ... if you create a region that has a checkbox role, how do you
   specify its state?
   ... what happens with an accessibility checker. i can't walk
   the structure. its sitting inside a virtual dom in the canvas

   RC: it would expose the hit regions DOM

   RS: not sure why they are doing this.
   ... there are a number of issues with this that are
   problematic. You can't convey state with this.
   ... they are trying to restrict fallback content to only HTML
   controls.
   ... I wouldn't include any of this as it stands.
   ... the browser would have to create new api's to expose this
   dom

   RC: The WHAT WG spec has been updated to be less restrictive
   regarding elements that can be used for fallback content

   <cabanier> The arguments object's control member is not one of
   the following:

   <cabanier> null

   <cabanier> an a element that represents a hyperlink

   <cabanier> a button element

   <cabanier> an input element whose type attribute is in one of
   the Checkbox or Radio Button states

   <cabanier> an input element that is a button

   <cabanier> a select element with a multiple attribute or a
   display size greater than 1

   <cabanier> an option element that is in a list of options of a
   select element with a multiple attribute or a display size
   greater than 1

   <cabanier> a sorting interface th element

   <cabanier> an element that would not be interactive content
   except for having the tabindex attribute specified

   <cabanier> a non-interactive table, caption, thead, tbody,
   tfoot, tr, td, or th element

   RS: What if when your fallback content is a grid or a list box.
   all behavior is managed in a container in fallback. it will
   bubble up to the parent.
   ... why would it be limited to elements with tabindex

   <richardschwerdtfeger> <div role="listbox" tabindex="0"
   aria-activedescendant="id of child">

   RS: you will have a keyboard handler on that. focus will be
   fired on behalf of the child.
   ... that is why there should be no restrictions on what can be
   used for fallback content.

   RC: its to avoid authors putting in nonsense content in
   fallback

   JS: anyone can create nonsense.

   RS: Hopefully Ian will see this use case against any sort of
   restrictions.

   RC: this shouldn't affect hit testing.

   RS: We don't want to do parent ID, label or ARIA role for L1

Custom mouse cursors

   RS: where would you need a custom mouse cursor? Rich text
   editing? Hopefully people won't be doing that
   ... don't think its critical for L1
   ... would be nice, but low priority for L1

fill rule

   RC: this is needed. for different kinds of binding rules

   RS: OK
   ... we will have to convince everyone that deferred features
   can be implemented without breaking anything.
   ... we are going to implement these. If we need to add other
   features in, we have to do so without breaking any features
   that are already there.

   We will not be supporting unbacked region descriptions like
   label or ARIA roles for L1.

   We will be supporting removeHitRegion

   We will be supporting the MouseEvent interface

   RS: do you think Apple will be OK with this in WebKit

   RC: I think so

   JMann: are we doing hit testing?

   yes

   MS: hoping to get everything we've agreed on back into the ED
   of W3C Canvas 2D

   JMann: Do we add this stuff "at risk"

   RS: Its based on what Dominic says.

   JMann: OK, so well bring in hit regions and the at risk status
   will be based on Dominic's response.

Possible Testing and/or Coordination meeting at

   JMann: Would be great if we could get Dominic

   RC: I cannot go. There is an SVG F2F that same week in Germany.
   I will be there.

   JMann: in the very least, it would be a good opportunity to
   talk with Dominic

Summary of Action Items

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [11]scribe.perl version
    1.138 ([12]CVS log)
    $Date: 2014-03-04 14:40:44 $

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

Received on Tuesday, 4 March 2014 14:46:46 UTC