W3C home > Mailing lists > Public > public-html-a11y@w3.org > January 2014

Minutes: Canvas Accessibility Sub Group Teleconference, 13 January 2014

From: Mark Sadecki <mark@w3.org>
Date: Tue, 14 Jan 2014 10:30:07 -0500
Message-ID: <52D557FF.1010304@w3.org>
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 13 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/13-html-a11y-minutes.html

TEXT:

    [1]W3C

      [1] http://www.w3.org/

             Canvas Accessibility Sub-Group Teleconference

13 Jan 2014

   See also: [2]IRC log

      [2] http://www.w3.org/2014/01/13-html-a11y-irc

Attendees

   Present
          Rich Schwerdtfeger, Mark Sadecki, Jatinder, Rik
          Cabanier, Philippe, Paul Cotton

   Regrets
   Chair
          Mark Sadecki

   Scribe
          Mark Sadecki

Contents

     * [3]Topics
         1. [4]Review Action items taken up at last meeting
         2. [5]Revisit Bug 23980 RE: Naming of focusRing methods
            http://j.mp/L3I6tf
         3. [6]Continue Bug Walkthrough (next up: 23984-23987)
         4. [7]Publication path/timeline for Canvas (from PaulC)
            http://j.mp/KfCUkH
         5. [8]Next Meeting
     * [9]Summary of Action Items
     __________________________________________________________

   <trackbot> Date: 13 January 2014

   <scribe> scribe: MarkS

   [10]http://www.w3.org/WAI/PF/HTML/wiki/Summary_of_focusRing_met
   hod_naming#Summary

     [10] http://www.w3.org/WAI/PF/HTML/wiki/Summary_of_focusRing_method_naming#Summary

Review Action items taken up at last meeting

   MS: I will follow up with Jay Munro regarding the two action
   items on him for last week.

Revisit Bug 23980 RE: Naming of focusRing methods
[11]http://j.mp/L3I6tf

     [11] http://j.mp/L3I6tf

   ->
   [12]http://www.w3.org/WAI/PF/HTML/wiki/Summary_of_focusRing_met
   hod_naming#Summary Summary

     [12] http://www.w3.org/WAI/PF/HTML/wiki/Summary_of_focusRing_method_naming#Summary

   MS: drawFocusIfNeeded seems to be a favorite at this point.

   JMann: I am OK with that

   RS: : I am OK with that

   JMann: drawFocusIfNeeded seems to solve all the issues I
   originally raised.
   ... talked about splitting the methods?

   RS: Ian originally wanted to have both together to make it
   easier on developers. I still think that is a good idea.

   RC: If we change the name and clarify purpose in spec, there
   should be no reason to split them up

   JMann: seems like if you are using the 2D context, this is the
   way to do it. Spoke with Graphic designers that understand this
   concept

   RESOLUTION: to change drawSystemFocusRing to drawFocusIfNeeded

Continue Bug Walkthrough (next up: 23984-23987)

   <plh>
   [13]https://www.w3.org/Bugs/Public/buglist.cgi?bug_status=NEW&b
   ug_status=ASSIGNED&bug_status=REOPENED&component=CR%20HTML%20Ca
   nvas%202D%20Context&list_id=30985&order=Importance&product=HTML
   %20WG&query_format=advanced

     [13] https://www.w3.org/Bugs/Public/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=CR%20HTML%20Canvas%202D%20Context&list_id=30985&order=Importance&product=HTML%20WG&query_format=advanced

   -> [14]https://www.w3.org/Bugs/Public/show_bug.cgi?id=23984
   23984 Is it possible to implement drawCustomFocusRing? (JM.
   Moved to Level 2)

     [14] https://www.w3.org/Bugs/Public/show_bug.cgi?id=23984

   -> [15]https://www.w3.org/Bugs/Public/show_bug.cgi?id=23985
   23985 drawCustomFocusRing and color scheme (JM. Moved to Level
   2)

     [15] https://www.w3.org/Bugs/Public/show_bug.cgi?id=23985

   -> [16]https://www.w3.org/Bugs/Public/show_bug.cgi?id=23986
   23986 Current default path

     [16] https://www.w3.org/Bugs/Public/show_bug.cgi?id=23986

   -> [17]https://www.w3.org/Bugs/Public/show_bug.cgi?id=23987
   23987 Empty path and drawSystemFocusRing

     [17] https://www.w3.org/Bugs/Public/show_bug.cgi?id=23987

   PLH: some of these are still assigned to CR component

   RS: 23984 should not be in the list because it is being moved
   to L2
   ... 23985 same thing

   JMann: 23986, which path actually gets drawn?

   PLH: I think you are talking about 23987

   JMann: if you call it immediately, what happens?

   RC: depends on what you have done previously

   PLH: Assuming you have not done anything

   RC: whatever path is in the canvas at that point, will be the
   focus area

   PLH: The spec states that there is always a current default
   path, what is it?

   <richardschwerdtfeger>
   [18]http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/
   #current-default-path

     [18] http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/#current-default-path

   JMann: scenario 1, just created canvas, call drawFocusIfNeeded,
   what happens, and just drew a path and called drawFocusIfNeeded
   what happens

   PLH: I will amend the bug

   JMann: what do we think should happen?

   PLH: I don't think anything should happen, there is no default
   path when the canvas element has been created

   JMann: if you call drawFocusIfNeeded before than you have a
   region associated with that path

   RS: can always have the path be outside the canvas area,
   nothing gets drawn
   ... it should have a default path of some sort

   RC: by default a fallback element has not region associated
   with it.

   JMann: I think it should get the bounds of the entire canvas
   element

   RS: Makes sense

   RC: that is not in the spec right now right?

   RS: no, should be

   RC: should that be in the HTML spec? That is where we talk
   about fallback content

   RS: What does context.fill do ?

   nothing

   RC: if you bring focus to fallback content, but the associated
   path has not even been drawn, nothing should happen

   JMann: agree
   ... so if I do the beginPath forces UA to cache the last path
   always.

   <richardschwerdtfeger> For CanvasRenderingContext2D objects,
   the points and lines added to current default path by these
   methods must be transformed according to the current
   transformation matrix before they are added to the path.

   RS: 0,0 is path, doesn't go anywhere?

   JMann: i think we should just change algorithm to abort

   RC: you need to update the region

   RS: If you are adding to the path, then yes

   RC: updated a11y api with the bounding box of the element

   RS: we could put a note that says to make sure that you have
   created a path

   RC: there is always a path

   <JatinderMann> The beginPath() method must empty the list of
   subpaths in the context's current path so that the it once
   again has zero subpaths.

   JMann: the moment you call beginPath, you have no path until
   you build on that path . it's empty
   ... so we draw the bounding of the canvas, or draw the last
   path, or we draw 0,0 or we ??

   RC: If the current default path is empty, then don't draw
   anything but set the accessible region back to the original
   value

   JMann: do we all agree that it is an error case?

   RC: I think it something an author might do
   ... a way to remove the association with the fallback content

   JMann: ah to reset a11y dom
   ... that is a use case
   ... means we shouldn't do nothing
   ... so 0,0 or the entire canvas. I like entire canvas, which is
   still true, but it may not be a real reset.

   RC: can we say initial value?

   RS: if its the entire canvas the magnifier focuses on entire
   canvas

   JMann: is there a default location?

   RS: not that I am aware of

   RC: can you make it invisible?

   RS: yes

   JMann: If we can tie it to the initial value (invisible) then
   that should cover the use case.

   JMann: does this feel buggy or will developers get this concept
   ... this should also resolve 23987

   <richardschwerdtfeger>
   [19]https://developer.mozilla.org/en-US/docs/Web/Accessibility/
   AT-APIs/MSAA/States

     [19] https://developer.mozilla.org/en-US/docs/Web/Accessibility/AT-APIs/MSAA/States

   RS: states are different on each platform. MSAA has the concept
   of unavailable

   <JatinderMann> STATE_SYSTEM_INVISIBLE

   RS: offscreen means not visible, but not necessarily gone.
   ... that means disabled, so that wouldn't work
   ... if the author really wants to remove it from the AT they
   should just remove it from the AAPI

   JMann: are we expected developers to delete the element and add
   it back later on?
   ... the recommend approach for removing your controls would be
   to change the ARIA state or delete the node. Maybe we should
   just a no op if the path is empty

   RS: so do nothing?

   yes

   JMann: should be as easy as updating the processing model

   RESOLUTION: Update the process to include "if there are zero
   sub paths in the current path, abort these steps"

   RS: we can close 23986 and 23987 when this is done.

   <plh> [20]https://www.w3.org/Bugs/Public/show_bug.cgi?id=23982

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

   PLH: 23982 focus ring out of canvas is that one closed?

   JMann: I don't think the bug reflects that, but we need to get
   the spec updated and then update the bug

   <richardschwerdtfeger> It was agreed that the focus ring would
   be clipped to the bounds of the canvas area but that the
   location of the corresponding fallback element would not be
   clipped and would match the current default path passed.

Publication path/timeline for Canvas (from PaulC)
[21]http://j.mp/KfCUkH

     [21] http://j.mp/KfCUkH

   <plh> [22]https://www.w3.org/Bugs/Public/show_bug.cgi?id=23981

     [22] https://www.w3.org/Bugs/Public/show_bug.cgi?id=23981

   <paulc> Canvas CR bugs: [23]http://tinyurl.com/kxmqysj

     [23] http://tinyurl.com/kxmqysj

   JMann: I'll have Jay close the bugs as soon as the spec is
   updated

   <richardschwerdtfeger> "Informs the user of the canvas location
   for the fallback element, based on the current path. If the
   given element has focus, draws a focus ring around the current
   path following the platform or user agent conventions for focus
   rings as defined by the user agent."

   PC: When will all the changes to the spec be made, and when
   will the bugs will be closed.
   ... next week we should have an agenda item to confirm these
   bugs are closed

   RS: I can confirm that 23978 has been completed

   JMann: scrollPathIntoView has been moved to L2 because it
   requires Path

   <plh3> " the bounding box of the area to which the user agent
   is scrolling as the bounding box of the current selection."

   <JatinderMann>
   [24]https://www.w3.org/Bugs/Public/show_bug.cgi?id=23983

     [24] https://www.w3.org/Bugs/Public/show_bug.cgi?id=23983

   <Zakim> plh, you wanted to ask about a potential new issue

   <plh3>
   [25]http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/
   #dom-context-2d-drawsystemfocusring

     [25] http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/#dom-context-2d-drawsystemfocusring

   <richardschwerdtfeger>
   [26]http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/
   #dom-context-2d-drawsystemfocusring

     [26] http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/#dom-context-2d-drawsystemfocusring

   PLH: If i have two checkbox in my canvas and two canvas
   elements to match, and I call drawFocusIfNeeded. Now, I move
   focus to the second element, second checkbox and I all
   drawFocusIfNeeded. I am assuming it does not remove the focus
   once focus is removed it is up to the author to remove the
   focus ring

   yes

   RS: also when author calls .focus

   JMann: is dominic in agreement with all of our changes?

   RS: I think we should send him an updated draft

   JMann: I will follow up with Jay to get all changes implemented
   so we have a new draft.

   PC: I talked to W3C Team and as long as we are removing
   material to canvas and not adding substantive new material, we
   can waive the disclosure period, so that is no longer a factor.

   PLH: we have two problems. We have added some text to this
   spec. Also, with changing the name of the method...

   PC: PLH can you add this to the discussion with Ian Jacobs?

   PLH: OK

   PC: doesn't look like we will have much of a delay going into
   LC. If we go back into CR what the min time will be. If another
   disclosure is required, the min length would match the 6 week
   period anyway, so we should be OK.
   ... main thing is that we need to get this into LC ASAP

   RS: when we get this draft, there is an apple guy that needs to
   look at it as well.

   RC: I think we have addressed his concerns as well. He may need
   to be convinced.

   JMann: will be worth it to share our changes and reasoning with
   him.

   RC: I'll email him.

   JMann: how long to get changes in?

   RC: Should be a small patch, the AAPI stuff might take a few
   weeks.

   PLH: Need dominic to update implementation in Blink

   JMann: we also need test suites as well

   PLH: I have some tests, but nothing that looks at the AAPI

   <plh3> [27]https://github.com/w3c/web-platform-tests/pull/457

     [27] https://github.com/w3c/web-platform-tests/pull/457

   PC: During this week, if the canvas editors are closing out
   bugs, they should be prepping LC document as well

   <plh3> ACTION: plh to update his tests in
   [28]https://github.com/w3c/web-platform-tests/pull/457
   [recorded in
   [29]http://www.w3.org/2014/01/13-html-a11y-minutes.html#action0
   1]

     [28] https://github.com/w3c/web-platform-tests/pull/457

   <trackbot> Created ACTION-225 - Update his tests in
   [30]https://github.com/w3c/web-platform-tests/pull/457 [on
   Philippe Le Hégaret - due 2014-01-21].

     [30] https://github.com/w3c/web-platform-tests/pull/457

   PC: we have to do a CfC, earlier the better
   ... probably what we would do is have a heartbeat for L2 as
   well
   ... we will be doing heartbeats in early Feb

Next Meeting

   MS: same time, same place next week

Summary of Action Items

   [NEW] ACTION: plh to update his tests in
   https://github.com/w3c/web-platform-tests/pull/457 [recorded in
   [31]http://www.w3.org/2014/01/13-html-a11y-minutes.html#action0
   1]

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [32]scribe.perl version
    1.138 ([33]CVS log)
    $Date: 2014-01-14 15:28:46 $

     [32] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [33] http://dev.w3.org/cvsweb/2002/scribe/
Received on Tuesday, 14 January 2014 15:30:07 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:37 UTC