Canvas Accessibility Sub-Group Teleconference

<trackbot> Date: 06 January 2014

<scribe> Meeting: Canvas Accessibility Sub-Group

<scribe> scribe: Mark Sadecki

<scribe> scribeNick: MarkS

http://www.w3.org/WAI/PF/HTML/wiki/Canvas#Next_Agenda

scrollPathIntoView()

[discussion on scrollPathIntoView() and why location information of fallback content needs to be updated]

RS: we need to add text that makes it clear that scrolling the page (and moving the position of canvas objects in the browser window) should result in location information updates to fallback elements as well.

JMunro: We should probably add that under point #3 Scroll rendered fallback element into view with the align to top flag set.

RC: Sounds like advice. Do we need to put it here?

RS: Should probably go in an implementation guide for Canvas

RC: I don't think we need to specify that the position of the elements gets changed if the page scrolls.
... If the canvas document is offscreen and an element gets focused, it should tell the browser to move the canvas into the viewport

RS: just need to put something into the method for scrollPathIntoView()
... and this was moved to L2

RC: Should we leave it undefined for now?
... if you are tabbing to an element that is offscreen, you want to scroll the page to move it into the viewport

RS: Where should that go?

RC: It should be text that is similar to scrollPathIntoView
... it should be one of the steps for drawing the focus ring

JMunro: I'm wondering if sending location updates to the a11y layer is really needed because its connected to the fallback content which is connected to the element drawn on the screen.
... do we need a note that says to move the location too

RS: If you tab to something which is a fallback content, what would happen?

JMunro: I think the browser would move focus to that element, and draw the focus ring.

RS: When you first tab, will you have a location?

RC: the position is always known.
... when you call drawFocusRing, you set the location

RS: before that is called, we don't have location information.

RC: that is true
... but they have to call drawFocusRing, even when it does not receive focus (its just checking)
... I don't think we need to define this behavior

JMunro: I thought location information for all elements was only returned on dCFR
... dSFR returns VOID
... so element.focus doesn't trigger this, they have to call drawFocusRing

RC: correct.
... author needs to call drawFocusRing which checks all the canvas elements to see if it has focus. if it does, it draws a ring, regardless it will update the location info for all elements in canvas

http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/#dom-context-2d-scrollpathintoview

RC: We need additional text under scrollPathIntoView() "if the elements region is not on the screen, then scroll the region into view"

JMunro: RE: where to put these things. Do we want to put these notes at the bottom of both methods (dCFR and dSFR)

RC: It should be after step 1 of each method

RS: This is something they would have to change in Chrome...

RC: yes
... should talk to Dominic

JMunro: I can put some draft text into there that clarifies that if focus is moved to an element on the canvas and the canvas is not in the viewport, the page should scroll so that the canvas is in the viewport.

RS: I just pinged dominic and he said no problem.

RC: after step 3, when the elements are attached to the region. that is where it should go

Review action items taken up at last meeting

JMunro: 23978 is mostly taken care of. I see your reply now and will finish it up.
... wanted to suggest that as we make changes, can we say something like "change [original content] to [new content]"

RS: absolutely

JMunro: we can make changes to L2

http://www.w3.org/WAI/PF/HTML/track/actions/224

RS: That is all taken care of. There may not be a bug, but the work is being done

MS: I can take a closer look to confirm.

Continue Bug Walkthrough (starting with 23980)

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23980

RC: we agreed last call that dSFR is OK dCFR needs work, but we can do that for L2

JMunro: Let's make a note on the bug.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23982

Focus Ring out of canvas

RC: I think that was a question from Apple. Wanted to know what should happen
... what happens when you try to scroll to it.

RS: the location would change, but the visual rendering of the ring would be clipped
... do we need a note to clarify that?

RC: lets say the path is underneath the canvas element, would you scroll past that, or to the bottom or not at all?
... clip it if its partially visible, but what if it is not visible (beyond the canvas borders)
... wouldn't you just say abort

RS: give it a location, but don't draw anything.

RC: what happens if you tab to the fallback content for an element that is rendered beyond the borders of the canvas?

RS: don't scroll at all.
... it has to be visible on the canvas

RC: so that should be made clear. if the element is beyond the borders of the canvas, do not scroll it into view

Estimate how long it will take to address rest of the bugs

These are the remaining bugs

23984 Is it possible to implement drawCustomFocusRing?

23985 drawCustomFocusRing and color scheme

23986 Current default path

23987 Empty path and drawSystemFocusRing

[group agrees that 2-3 weeks tops to go through rest of bugs]

Confirm next meeting