- From: Mark Sadecki <mark@w3.org>
- Date: Tue, 07 Jan 2014 16:10:34 -0500
- To: HTML A11Y TF Public <public-html-a11y@w3.org>, public-canvas-api@w3.org
Hello,
The minutes for the Canvas Accessibility Sub Group Teleconference 6 January 2014 are available in HTML and plain text below.  Supporting information for this Sub Group can be found on the wiki: http://www.w3.org/WAI/PF/HTML/wiki/Canvas
HTML: http://www.w3.org/2014/01/06-html-a11y-minutes.html
TEXT:
      [1]W3C
      [1] http://www.w3.org/
                    Canvas Accessibility Sub-Group Teleconference
06 Jan 2014
   See also: [2]IRC log
      [2] http://www.w3.org/2014/01/06-html-a11y-irc
Attendees
   Present
          Mark Sadecki, Rich Schwerdtfeger, Jay Munro, Rik
          Cabanier
   Regrets
          Jatinder Mann
   Chair
          Mark Sadecki
   Scribe
          Mark Sadecki
Contents
     * [3]Topics
         1. [4]scrollPathIntoView()
         2. [5]Review action items taken up at last meeting
         3. [6]Continue Bug Walkthrough (starting with 23980)
         4. [7]Estimate how long it will take to address rest of
            the bugs
         5. [8]Confirm next meeting
     * [9]Summary of Action Items
     __________________________________________________________
   <trackbot> Date: 06 January 2014
   <scribe> Meeting: Canvas Accessibility Sub-Group
   <scribe> scribe: Mark Sadecki
   <scribe> scribeNick: MarkS
   [10]http://www.w3.org/WAI/PF/HTML/wiki/Canvas#Next_Agenda
     [10] 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
   [11]http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/
   #dom-context-2d-scrollpathintoview
     [11] 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
   [12]http://www.w3.org/WAI/PF/HTML/track/actions/224
     [12] 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)
   [13]https://www.w3.org/Bugs/Public/show_bug.cgi?id=23980
     [13] 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.
   [14]https://www.w3.org/Bugs/Public/show_bug.cgi?id=23982
     [14] 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
   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
Summary of Action Items
   [End of minutes]
     __________________________________________________________
    Minutes formatted by David Booth's [15]scribe.perl version
    1.138 ([16]CVS log)
    $Date: 2014-01-07 21:01:16 $
     [15] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [16] http://dev.w3.org/cvsweb/2002/scribe/
Received on Tuesday, 7 January 2014 21:10:34 UTC