Canvas Accessibility Sub-Group Teleconference

<trackbot> Date: 03 February 2014

<scribe> Meeting: Canvas Accessibility Sub-Group Teleconference

<scribe> scribe: MarkS

Concerns raised by Mozilla

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

When Canvas can go back to LC

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.

Next Meeting

See you all next week.

<jaymunro> thanks mark