Minutes: Canvas Accessibility Sub Group Teleconference, 10 March 2014

Hello,

The minutes for the Canvas Accessibility Sub Group Teleconference 10 March 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/03/10-html-a11y-minutes.html

TEXT:

   [1]W3C

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

             Canvas Accessibility Sub-Group Teleconference

10 Mar 2014

   See also: [2]IRC log

      [2] http://www.w3.org/2014/03/10-html-a11y-irc

Attendees

   Present
          MarkS, Rik Cabanier, Rich_Schwerdtfeger, jaymunro,
          Jatinder_Mann, Janina Sajka

   Regrets
   Chair
          MarkS

   Scribe
          MarkS

Contents

     * [3]Topics
         1. [4]Summary of Canvas discussion at A11y TF Meeting
         2. [5]Review proposed draft for Hit Regions L1
     * [6]Summary of Action Items
     __________________________________________________________

   <trackbot> Date: 10 March 2014

   <scribe> Meeting: Canvas Accessibility Sub-Group Teleconference

   <scribe> scribe: MarkS

   [7]http://lists.w3.org/Archives/Public/public-canvas-api/2014Ja
   nMar/att-0165/HitRegionsL1.html

      [7] http://lists.w3.org/Archives/Public/public-canvas-api/2014JanMar/att-0165/HitRegionsL1.html

Summary of Canvas discussion at A11y TF Meeting

   MS: Updated the TF with regards to our progress to date. Paul
   asked what the next steps forward would be. I clarified that we
   would be getting a limited version of Hit Regions back into the
   L1 spec and working it until we were satisfied. Then we would
   take it to the TF for approval and then on to the WG to approve
   and take Canvas back to LC. Paul seemed happy with that. I urge
   us to continue making progress. To me the importance of this
   work is for us to have something to take to future implementors
   like Chrome or WebKit so that they know what our priorities for
   Hit REgions are. While they can implement everything in the
   WHAT WG or L2 spec, for Level 1, this is what we consider
   necessity. I shared a version of the Hit Regions section last
   week that I think is a good starting point based on what we
   discussed previously. I would like to review that today so that
   Jay has something he can put back into L1. We can file bugs
   against it once its in there until we are satisfied.

Review proposed draft for Hit Regions L1

   [8]Proposed L1 Hit Regions Section (for today's review)

      [8] http://lists.w3.org/Archives/Public/public-canvas-api/2014JanMar/att-0165/HitRegionsL1.html

   [9]What is the L2 Hit REgions and what L1 is based on

      [9] http://lists.w3.org/Archives/Public/public-canvas-api/2014JanMar/att-0165/HitRegionsL2.html

   [10]A diff of these two documents.

     [10] http://lists.w3.org/Archives/Public/public-canvas-api/2014JanMar/att-0165/HitRegions.patch

   JM: Hit Region is a collection of coordinates? pixels?

   RS: I think its a collection of paths

   JM: Think we need to define what a hit region is.

   RC: I think its defined later down in the spec

   JM: Just wanted to be clear about what the hit region is
   describing. we talk about returning that under mouse events.

   JS: Perhaps we need a glossary

   JMann: we technically defined it, but its not clear what the
   purpose of a hit region is
   ... maybe we need to make a non-normative description of it

   JM: Its more clear now. I'll play around with it.
   ... perhpas make it more clear.

   RC: I think we should take out fillRule. its no where else in
   the W3C spec.

   RS: OK, lets take it out then.

   JMann: if we want to add it, all we need is test cases.
   everyone supports fillRule already. We can do this.
   ... does this improve the feature?

   RS: I don't know what we get from it.

   JMann: we get the non-zero binding rule. No one does even-add
   yet, but everyone does nonzero
   ... fillRUle, point in path, etc all support non-zero, but
   nobody supports even-odd yet. Doesn't feel unnatural that this
   defaults to non-zero either.
   ... I still think I'm OK cutting it.

   RS: why can the ID have an empty value

   MS: I think we have it in there to just handle the case

   JMann: what if you have two without ids, you just can't remove
   them?
   ... what if two regions reference the same control,

   RC: I think the second region overrides it.

   JMann: I think its oK to loosen the definition on this.

   RS: If the fallback element goes away, the hit region goes
   away.

   RC: I think its covered already

   JMann: it feels like the basic feature set.

   JM: Later it calls to addHitRegion, what happens if you call it
   again with the same ID, should that remove the hit region?

   RC: It means that you remove the hitRegion. The second one
   overrides the first one. it clears the old value first.
   ... Verifeid that if you remove the control from the canvas,
   you remove the region.

   RS: Anytime you remove an associated element, you would remove
   the region

   RC: its not true. You don't have to have a control. The region
   will not have a11y roles, but you will have events.
   ... when you hover over that region.
   ... that should all be in the spec, no need to change anything.

   <JatinderMann> 1.If ID is null, return nothing and abort these
   steps.

   The region identified by the ID ID in a bitmap bitmap is the
   value returned by the following algorithm (which can return a
   hit region or nothing):

   RS: Is this the region for where you get a hit?

   RC: this is just the region identified by an ID
   ... like a dictionary
   ... algorithm for differentiating regions in the region list

   RS: ok, so its an internal method

   JM: Do we want to say anything above the list of processing
   steps that explains the purpose of this

   JMann: I think this follows all the normal conventions from
   specifications
   ... don't want to diverge too much from what the WHAT WG spec
   has.

   RS: Is this close to what WHAT WG has?

   RC: except for the restrictions on what can be included as
   fallback content.

   RS: One of the things we should probably do is to file bugs on
   WHAT WG
   ... on things like that
   ... we want to keep things in sync. Think the editors should do
   that.
   ... I can write it but I think it would be better coming from
   the editors.

   RC: Any idea why clearRect() is mentioned in that note?

   RS: I think Hixie wanted that there. I'm not clear why

   RC: It seems odd to do that.

   RS: I think he was just trying to make it easier for developers

   RC: Clipping does not affect hit regions

   RS: Should we be clipping the hit regions, like we did for
   focus ring?

   MS: I think it automatically happens

   RC: It is strange that the clearREct thing is non-normative

   RS: How does adding a new region clear anything?

   MS: Yeah, I don't see that either.

   RS: Not sure we have all of the same definitions that they have
   in WHAT WG
   ... see clearRect

   <richardschwerdtfeger> Adding a new region and calling
   clearRect() are the two ways this clearing algorithm can be
   invoked. The hit region list itself is also reset when the
   rendering context is reset, e.g. when a
   CanvasRenderingContext2D object is bound to or unbound from a
   canvas, or when the dimensions of the bitmap are changed.

   <richardschwerdtfeger> A CanvasRenderingContext2D object has a
   scratch bitmap and can be bound to an output bitmap. These are
   initialized when the object is created, and can be subsequently
   adjusted when the rendering context is bound or unbound. In
   some cases, these bitmaps are the same underlying bitmap. In
   general, the scratch bitmap is what scripts interact with, and
   the output bitmap is what is being displayed. These bitmaps
   always have the same dimensions.

   RC: This is for canvas workers I think. I don't think anyone
   has implemented this.
   ... i don't think that applies to us

   JM: Instead of saying scratch bitmap it says canvas element in
   our nightly spec. We're not supporting workers yet

   RC: we should not refer to scratch bitmap. there are other
   proposals out there that people are liking better.

   RS: So what are we doing with clearRect?

   JM: Under clearREct in the nightly, it covers this. step 3. it
   will clear any regions encompassed in it

   RC: Maybe if you add a new hit region that encompasses the
   other hit regions.

   MS: I think we need to add text that clarifies that the new
   region has to totally encompass the hit region that would be
   cleared.

   RC: The last one you draw is the one that gets hit.
   ... how do you know if a path covers another path.
   ... it would be very hard to determine if one path totally
   encompasses another.

   RS: it happens automatically, but it doesn't do garbage
   cleanup.

   RC: problem comes when you add a new one over the old and then
   remove the new one, the old would still be there and it
   shouldn't
   ... i really don't think it *should* be removed. i think we
   should talk to Ian about this.
   ... it seems reasonable that an author would expect the
   previous region to still be there.

   RS: There is another mention of fillRule in step 3
   ... do we want to remove that

   RC: yes

   RS: Another mention of scratch bitmap.

   JM: Does it translate to the canvas element here as it did
   before?
   ... lets assume that change will be global

   MS: Jay, do you have enough here to get Hit Regions back into
   Level 1

   JM: I think with the notes here I can get that done.

Summary of Action Items

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [11]scribe.perl version
    1.138 ([12]CVS log)
    $Date: 2014-03-11 00:44:47 $

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

Received on Tuesday, 11 March 2014 00:47:03 UTC