Minutes: Canvas Accessibility Sub Group Teleconference, 16 December 2013

Hello,

The minutes for the Canvas Accessibility Sub Group Teleconference 16 December 2013 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/2013/12/16-html-a11y-minutes.html

TEXT:

   [1]W3C

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

             HTML Accessibility Task Force Canvas Sub Group

16 Dec 2013

   See also: [2]IRC log

      [2] http://www.w3.org/2013/12/16-html-a11y-irc

Attendees

   Present
          Rich Schwerdtfeger, Mark Sadecki, Jay Munro, Rik
          Cabanier, Jatinder Mann

   Regrets
   Chair
          Rich S

   Scribe
          MarkS

Contents

     * [3]Topics
         1. [4]Should work on drawCustomFocusRing go to L2?
         2. [5]Walk through existing Canvas 2D Accessibility bugs
         3. [6]next meeting date
         4. [7]Should scrollPathIntoView refer to fallback
            elements rather than "notional children" having a
            defined location?
     * [8]Summary of Action Items
     __________________________________________________________

   <trackbot> Date: 16 December 2013

   <scribe> Meeting: HTML Accessibility Task Force Canvas Sub
   Group

   <scribe> scribe: MarkS

Should work on drawCustomFocusRing go to L2?

   Should work on drawCustomFocusRing go to L2?

   RS: We have Firefox and Microsoft and have had contact with
   Dominic from Chrome
   ... Paul Cotton left if up to the group to move customFocusRing
   to L2. Do we have consensus on this or do we need further
   discussion?

   RC: If everyone is Ok with moving it to L2, I think that is a
   good idea

   RS: We were almost there, but really need Media Queries/User
   Context to deal with the high contrast issue. So we should
   probably wait.

   JMann: If we feel like something later on will help us do that,
   then I think we should wait.

   RS: I'm fine either way

   JMann: lets start with systemFocusRing but still talk about
   customFocusRing when relevant.
   ... what about the CfC from the TF

   <JatinderMann> Mark those last comments came from me (JMann)

   RS: Paul Cotton left it up to this group in the last TF call.

Walk through existing Canvas 2D Accessibility bugs

   <richardschwerdtfeger>
   [9]https://www.w3.org/Bugs/Public/show_bug.cgi?id=23978

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

   <JatinderMann> All bugs are listed here:
   [10]http://lists.w3.org/Archives/Public/public-html-a11y/2013De
   c/0011.html

     [10] http://lists.w3.org/Archives/Public/public-html-a11y/2013Dec/0011.html

   RS: Informing the user shouldn't be optional
   ... this had to do with informing the user that the location
   has changed for the current focused element. This is for the
   Assistive Technology. This was phrased like this because some
   platforms might not have an accessibility infrastructure.

   JMann: If we say it is a requirement, and a platform doesn't
   support it, isn't that the same as supporting this feature.

   RS: Notifying would be an additional step. This piece would be
   optional.

   JMann: What they really wanted was a bounding box. Notifying
   the AT is a goal of the feature.

   RC: agreed

   JMann: I think it should be a requirement

   RS: I agree, do you want to take "optionally" out?

   JMann: Was Ian's concern that an accessibility feature must be
   enabled in order to fire that event?

   RS: I think it was more for older mobile phones who don't have
   an integrated AT, they could still draw the focus ring, but not
   inform the location
   ... in all the AAPI you have rectangle, X,Y Width and Height.
   You would expose that to the AAPI for the bounding box.

   JMann: my concern was that is said optional at all, it makes it
   seem like its not that important. However, I would think that
   this would be the actual feature.
   ... i think we should make it a requirement and clarify what
   the feature is for.
   ... a preamble that describes what this feature is meant to do.

   RS: so remove the word optionally, and add a note that explains
   the feature.

   JMunro: I'm looking at the spec and it doesn't say explicitly
   that its informing the AAPI. It could be a dialog box or
   anything. So to clarify its for AAPI would help.

   <richardschwerdtfeger> Note: This is intended to provide inform
   the user of the location of the element on canvas to support
   accessibility services. For user agents that are implemented on
   platforms that don't provide such services this feature cannot
   be implemented.

   <richardschwerdtfeger> This is intended to provide inform the
   user of the location of the element on canvas to support
   accessibility services.

   JMann: If a platform didn't have native accessibility support,
   it should be clear that it would be beneficial to at least draw
   the ring, even though you can't report the location.

   RS: who will make the edit?

   JMunro: I can make the edit if you provide the text.

   <richardschwerdtfeger>
   [11]https://www.w3.org/Bugs/Public/show_bug.cgi?id=23979

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

   RESOLUTION: 23978 closed

   <richardschwerdtfeger> The differences between
   drawSystemFocusRing and drawCustomFocusRing should be better
   highlighted in the specification:

   <richardschwerdtfeger> * Using drawCustomFocusRing means that
   the web app intention is to draw the focus itself, unless the
   user has requested a particular focus ring. Its purpose is to
   help the web app preserves the user setting

   <richardschwerdtfeger> * Using drawSystemFocusRing means that
   the web app wishes to delegate the drawing of focus ring to the
   user agent

   RS: PLH has presented recommended text

   JMann: I support this bug, it took me awhile to understand the
   difference between system and custom focus ring

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

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

   RS: If we move this to L2, we can pass on this one.

   JMann: would it help to add a note to describe what
   drawSystemFocusRing() does?

   <JatinderMann> If the given element is focused, draws a focus
   ring around the current default path or hte given path,
   following the platform conventions for focus rings.

   RS: there is no given path
   ... so we should make this clearer?

   JMann: Draw the focus ring around the current default path.
   should we put something in there so developers understand what
   the purpose of this function is

   RS: Do we want to change it to drawSystemFocus?

   JMann: when we say system, we really mean User Agent, right?

   RS: which is based on the Operating System

   JMann: In IE its a dotted line, in FF its a reddish-orangish
   line

   <richardschwerdtfeger> The purpose of this function is draw a
   focus ring in a way that conforms to the way a user agent draws
   focus.

   <richardschwerdtfeger> The purpose of this function is draw a
   focus ring in a way that conforms to the way a user agent draws
   focus and to inform assistive technologies of the location of
   the bounds of the focus as applied to an element.

   JMann: its useful to come up with some ideas right now, but we
   may want to continue to work on the exact wording.
   ... important that other implementers not on this call, or web
   developers, understand what this is for.
   ... confusion around what the system is (UA) and what this
   method does or is important for.

   <richardschwerdtfeger> The purpose of this function is draw a
   focus ring in a way that conforms to the way a user agent draws
   focus and to inform assistive technologies of the location of
   the bounds of the focus as applied to an element. User agents
   often implement focus drawing following system conventions.

   JMann: I wonder if its worth not saying "ring"
   ... canvas allows you to draw any path, so ring is confusing.

   RS: outline is OK with me

   JMann: not everyone does an outline, so maybe just focus path?

   JMunro: Path has another meaning

   <richardschwerdtfeger> The purpose of this function is draw a
   focus in a way that conforms to the way a user agent draws
   focus and to inform assistive technologies of the location of
   the bounds of the focus as applied to an element. User agents
   often implement focus drawing following system conventions.

   JMunro: I think we should talk about working and terminology
   more. Outline is a possibility, I'm thinking of focus.

   JMann: we can take the actual working and discuss it on the
   list

   MS: is the word "indicator" too vague

   JMann: no, thats actually what it is. that is interesting

   RC: would we have to change chrome and FF to match?

   JMann: is it prefixed?

   RC: no, its not prefixed, but its behind a flag

   JMann: this is just the note, nothing normative
   ... sounds like we are all in agreement that we can make it
   better and we should probably do that on list.

   <richardschwerdtfeger> The purpose of this function is draw a
   focus indicator in a way that conforms to the way a user agent
   draws focus and to inform assistive technologies of the
   location of the bounds of the focus as applied to an element.
   User agents often implement focus drawing following system
   conventions.

   JMann: you still want to say if the given element is focused.

   RS: Because we don't have any path capability right now, if its
   not focused, it doesn't draw the ring, but it does provide the
   location.
   ... Magnifiers want to allow users to zoom to a location on the
   canvas. If the element doesn't have focus, they still want to
   be able to drive the magnifier there.

   RC: that has nothing to do with Path API, its just how its
   currently designed.
   ... you don't inform the AAPI unless it has focus.

   RS: Dominic *does* inform that AAPI of the location's object,
   even though the spec doesn't say that. it is a way around hit
   testing.
   ... this wouldn't be necessary if we had hit testing.
   ... because fallback canvas aren't rendered to the glass, they
   don't have a location. One way to deal with this is to use dSFR
   method to draw the ring and indicate location. The same
   function could be used to indicate location, without drawing
   the focus ring if they are not in focus.

   JMann: so the AAPI won't know where the elements are until they
   are in focus.
   ... if I want to move the magnifier, I would move focus to...

   RS: HTML outside of canvas, the layout engine provides the
   location of each element to a corresponding accessible object.
   A magnifier or SR maintains a view of all the objects rendered
   on the screen can speak or zoom to all elements. A user can
   zoom to any element using that location info

   JMann: does it make sense to have a separate focus location
   mapping API

   RS: we actually had something like that, but Ian wanted to have
   one function to encourage people to write to the function.

   JMann: do we all agree that we should inform the aapi of
   location? if so, we should open a bug.

   <richardschwerdtfeger> ACTION: Rich Open bug against 2D Canvas
   for drawSystemFocusRing to inform assistive technologies of the
   location event when it does not have focus [recorded in
   [13]http://www.w3.org/2013/12/16-html-a11y-minutes.html#action0
   1]

   <trackbot> Created ACTION-224 - Open bug against 2d canvas for
   drawsystemfocusring to inform assistive technologies of the
   location event when it does not have focus [on Richard
   Schwerdtfeger - due 2013-12-23].

   JMann: so every time that method is called, I inform the AAPI
   of the location of all elements.
   ... Maybe just moving sCFR to L2 will make this work easier.

   <richardschwerdtfeger> RESOLUTION: Move drawCustomFocusRing to
   L2

   JMunro: its already in L2 now, so I will make changes to both
   were appropriate.

   <richardschwerdtfeger>
   [14]https://www.w3.org/Bugs/Public/show_bug.cgi?id=23979

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

   RS: should bug 23979 be moved to L2?

   JMann: we could open another bug regarding the note text.

   <richardschwerdtfeger> RESOLUTION: move defect 23979 to L2 in
   line with the resolution to move drawCustomFocusRing to L2

next meeting date

   Next meeting will be Monday Jan 6

Should scrollPathIntoView refer to fallback elements rather than
"notional children" having a defined location?

   <richardschwerdtfeger>
   [15]http://lists.w3.org/Archives/Public/public-canvas-api/2013O
   ctDec/0045.html

     [15] http://lists.w3.org/Archives/Public/public-canvas-api/2013OctDec/0045.html

   RS: I like the term descendent
   ... do you want to change both of those?

   JMunro: I would like to change to descendent, but the
   implementers should chime in.

   JMann: notional child doesn't mean anything to me

   RC: whatever language we use here needs to be copied to dCFR

   RS: need to create a defect/bug to do that.

   JMunro: I can do that.

   RS: we'll talk about the scrolling issue at our next meeting.

Summary of Action Items

   [NEW] ACTION: Rich Open bug against 2D Canvas for
   drawSystemFocusRing to inform assistive technologies of the
   location event when it does not have focus [recorded in
   [16]http://www.w3.org/2013/12/16-html-a11y-minutes.html#action0
   1]

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [17]scribe.perl version
    1.138 ([18]CVS log)
    $Date: 2013-12-17 00:13:37 $

     [17] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [18] http://dev.w3.org/cvsweb/2002/scribe/

Received on Tuesday, 17 December 2013 15:45:28 UTC