Canvas Accessibility Sub-Group Teleconference

<trackbot> Date: 03 March 2014

<scribe> scribe: MarkS

Walk through Hit Regions spec to discuss priority for implementation

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.

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