See also: IRC log
<trackbot> Date: 03 February 2014
<scribe> Meeting: Canvas Accessibility Sub-Group Teleconference
<scribe> scribe: MarkS
DB: It appears as though there
was a reaction to the discussion at Mozilla. I was surprised
that Dominic withdrew his support.
... need to ask him. Want to give Alex and Rik some space to
explore hit regions
https://bugzilla.mozilla.org/show_bug.cgi?id=958241
DB: worried that the AAPI doesn't have enough info about siblings and children, etc.
RS: I understand that info gets
stored in the layout engine, and in the AAPI. If you do average
scrolling, the info get updated. The issue we had was if the
viewport needed to be scrolled into view, which we handled in
our spec changes
... When the discussion was happening, Zynga was not pleased
with hit testing approach. They wanted something
"fuzzier"
... they wanted to modify the actually hit or trigger
area
... when hit testing was put into the spec, Microsoft didn't
have a chance to review it. It was later taken out. So we
focused on the drawSystemFocusRing, now drawFocusIfNeeded
approach to handle a11y.
... in order for hit regions to work, we have to work on Path
as well. Most of this is Canvas L2 stuff.
DB: Who is responsible for storing the current path
?
RS: its the object, the canvas
object.
... I think the drawFocusIfNeeded and Hit Regions need to
coexist
DB: It could cause a problem, I don't know.
RS: If we do implement hit regions, we could say that it overrides any drawFocusIfNeeded processing.
DB: right one would need
priority
... we wanted to explore hit testing. if it doesn't work out,
we wanted to consider focus outline as a backup
... if hit testing goes really well, we're not sure what we
would do with focus outline approach
JMann: So hit testing might solve the problem we solve with drawFocus?
RS: It would solve the location info, but not the outline drawing
JMann: so we have two potential solutions, but would only need to support one?
RS: IF we had two, could one affect the setting of the other?
DB: I'm looking out for the cognitive load on the developer
JMann: If we support drawFocus, and then hit testing comes around, how does that affect the developer
RS: Hit testing was always in the plan. The question is how long people will have to wait.
JMann: imagine we support drawFocus, hit testing in L2 will have to play nicely with drawFocus
RS: I don't think it would be a problem. We'd be applying hit regions in a similar manner to how its done in the OS. The thing is, if we add hit testing, if someone supplies a hit region, it takes precedence over any other location information
JMann: whatever we build in L2, it has to play well with L1. I just worry about compatibility. Espeicially if our only motivation is to get something out the door.
RS: We will still need to handle drawing the focus, including high contrast.
DB: as far as I'm concerned,
neither option is off the table. Trevor didn't accept the
patch, but that is not final. We would like to take a week on
this to do some exploration.
... I have reached out to Dominic. Don't want to bother him too
much.
RS: Better if it came from Moz.
MS: encourage Moz to post to public-canvas-api
JMunro: looking at hit regions, just wanted to say Path is critical to that. If we are thinking about going down that road, there is a lot of work to do on both
JMann: happy with drawFocus in L1 and hit regions in L2 as long as there is no backwards compatibility issues.
RS: I don't think they are going to draw the actual focus in hit regions
MS: I will update Paul this week in the TF call. Mozilla would like at least one week to explore the Hit Testing solution. They do not formally oppose drawFocusIfNeeded at this point. David Bolter will reach out to Dominic to make sure that is clear.
See you all next week.
<jaymunro> thanks mark