Canvas Accessibility Sub-Group Teleconference

<trackbot> Date: 10 March 2014

<scribe> Meeting: Canvas Accessibility Sub-Group Teleconference

<scribe> scribe: MarkS

http://lists.w3.org/Archives/Public/public-canvas-api/2014JanMar/att-0165/HitRegionsL1.html

Summary of Canvas discussion at A11y TF Meeting

MS: Updated the TF with regards to our progress to date. Paul asked what the next steps forward would be. I clarified that we would be getting a limited version of Hit Regions back into the L1 spec and working it until we were satisfied. Then we would take it to the TF for approval and then on to the WG to approve and take Canvas back to LC. Paul seemed happy with that. I urge us to continue making progress. To me the importance of this work is for us to have something to take to future implementors like Chrome or WebKit so that they know what our priorities for Hit REgions are. While they can implement everything in the WHAT WG or L2 spec, for Level 1, this is what we consider necessity. I shared a version of the Hit Regions section last week that I think is a good starting point based on what we discussed previously. I would like to review that today so that Jay has something he can put back into L1. We can file bugs against it once its in there until we are satisfied.

Review proposed draft for Hit Regions L1

Proposed L1 Hit Regions Section (for today's review)

What is the L2 Hit REgions and what L1 is based on

A diff of these two documents.

JM: Hit Region is a collection of coordinates? pixels?

RS: I think its a collection of paths

JM: Think we need to define what a hit region is.

RC: I think its defined later down in the spec

JM: Just wanted to be clear about what the hit region is describing. we talk about returning that under mouse events.

JS: Perhaps we need a glossary

JMann: we technically defined it, but its not clear what the purpose of a hit region is
... maybe we need to make a non-normative description of it

JM: Its more clear now. I'll play around with it.
... perhpas make it more clear.

RC: I think we should take out fillRule. its no where else in the W3C spec.

RS: OK, lets take it out then.

JMann: if we want to add it, all we need is test cases. everyone supports fillRule already. We can do this.
... does this improve the feature?

RS: I don't know what we get from it.

JMann: we get the non-zero binding rule. No one does even-add yet, but everyone does nonzero
... fillRUle, point in path, etc all support non-zero, but nobody supports even-odd yet. Doesn't feel unnatural that this defaults to non-zero either.
... I still think I'm OK cutting it.

RS: why can the ID have an empty value

MS: I think we have it in there to just handle the case

JMann: what if you have two without ids, you just can't remove them?
... what if two regions reference the same control,

RC: I think the second region overrides it.

JMann: I think its oK to loosen the definition on this.

RS: If the fallback element goes away, the hit region goes away.

RC: I think its covered already

JMann: it feels like the basic feature set.

JM: Later it calls to addHitRegion, what happens if you call it again with the same ID, should that remove the hit region?

RC: It means that you remove the hitRegion. The second one overrides the first one. it clears the old value first.
... Verifeid that if you remove the control from the canvas, you remove the region.

RS: Anytime you remove an associated element, you would remove the region

RC: its not true. You don't have to have a control. The region will not have a11y roles, but you will have events.
... when you hover over that region.
... that should all be in the spec, no need to change anything.

<JatinderMann> 1.If ID is null, return nothing and abort these steps.

The region identified by the ID ID in a bitmap bitmap is the value returned by the following algorithm (which can return a hit region or nothing):

RS: Is this the region for where you get a hit?

RC: this is just the region identified by an ID
... like a dictionary
... algorithm for differentiating regions in the region list

RS: ok, so its an internal method

JM: Do we want to say anything above the list of processing steps that explains the purpose of this

JMann: I think this follows all the normal conventions from specifications
... don't want to diverge too much from what the WHAT WG spec has.

RS: Is this close to what WHAT WG has?

RC: except for the restrictions on what can be included as fallback content.

RS: One of the things we should probably do is to file bugs on WHAT WG
... on things like that
... we want to keep things in sync. Think the editors should do that.
... I can write it but I think it would be better coming from the editors.

RC: Any idea why clearRect() is mentioned in that note?

RS: I think Hixie wanted that there. I'm not clear why

RC: It seems odd to do that.

RS: I think he was just trying to make it easier for developers

RC: Clipping does not affect hit regions

RS: Should we be clipping the hit regions, like we did for focus ring?

MS: I think it automatically happens

RC: It is strange that the clearREct thing is non-normative

RS: How does adding a new region clear anything?

MS: Yeah, I don't see that either.

RS: Not sure we have all of the same definitions that they have in WHAT WG
... see clearRect

<richardschwerdtfeger> Adding a new region and calling clearRect() are the two ways this clearing algorithm can be invoked. The hit region list itself is also reset when the rendering context is reset, e.g. when a CanvasRenderingContext2D object is bound to or unbound from a canvas, or when the dimensions of the bitmap are changed.

<richardschwerdtfeger> A CanvasRenderingContext2D object has a scratch bitmap and can be bound to an output bitmap. These are initialized when the object is created, and can be subsequently adjusted when the rendering context is bound or unbound. In some cases, these bitmaps are the same underlying bitmap. In general, the scratch bitmap is what scripts interact with, and the output bitmap is what is being displayed. These bitmaps always have the same dimensions.

RC: This is for canvas workers I think. I don't think anyone has implemented this.
... i don't think that applies to us

JM: Instead of saying scratch bitmap it says canvas element in our nightly spec. We're not supporting workers yet

RC: we should not refer to scratch bitmap. there are other proposals out there that people are liking better.

RS: So what are we doing with clearRect?

JM: Under clearREct in the nightly, it covers this. step 3. it will clear any regions encompassed in it

RC: Maybe if you add a new hit region that encompasses the other hit regions.

MS: I think we need to add text that clarifies that the new region has to totally encompass the hit region that would be cleared.

RC: The last one you draw is the one that gets hit.
... how do you know if a path covers another path.
... it would be very hard to determine if one path totally encompasses another.

RS: it happens automatically, but it doesn't do garbage cleanup.

RC: problem comes when you add a new one over the old and then remove the new one, the old would still be there and it shouldn't
... i really don't think it *should* be removed. i think we should talk to Ian about this.
... it seems reasonable that an author would expect the previous region to still be there.

RS: There is another mention of fillRule in step 3
... do we want to remove that

RC: yes

RS: Another mention of scratch bitmap.

JM: Does it translate to the canvas element here as it did before?
... lets assume that change will be global

MS: Jay, do you have enough here to get Hit Regions back into Level 1

JM: I think with the notes here I can get that done.