See also: IRC log
<trackbot> Date: 31 October 2013
<trackbot> Meeting: HTML Accessibility Task Force Teleconference
<scribe> scribe: MarkS
<paulc> Deadline is Nov 14.
<paulc> First day of F2F in Shenzhen.
<JF> +1 (JF could be)
<paulc> Paul is not available. Already in China.
regrets for next week from MarkS
CN: plan is that there will be a
meeting, I will chair
... the weekend of TPAC there will not be a meeting
... there will be a meeting the week of 11/21 there will be a
meeting and Janina will chair
... 11/28 there will not be a meeting
... There will be a meeting the first week of Dec.
<chaals> ACTION: chaals to post meeting dates for next month... [recorded in http://www.w3.org/2013/10/31-html-a11y-minutes.html#action01]
<trackbot> Created ACTION-212 - Post meeting dates for next month... [on Charles McCathie Nevile - due 2013-11-07].
<paulc> The WG will not be meeting the two weeks after TPAC ie Nov 21 and Nov 28 there will NOT be meetings.
CS: continue discussion RE canvas in 5.0 vs 5.1 and to introduce Jatinder
JM: I have been on IE team for
many years. Helped implement canvas in IE9 and am an editor of
the canvas spec
... wanted to talk about at risk items in canvas. Hit regions
and focus rings. IE11 does not support these features and we
will not until a future version.
... our proposal RE: hit regions is to move them out to the 5.1
spec
RS: we actually have implementations for Chrome on Mac and Win and in Firefox. They do not use Path objects
JM: would be interested in seeing examples of those. Interested in how that is going to work without Path objects.
RS: Shape object seems to be the new approach. Can get location information of object on the screen.
JM: If I can't describe a region on the canvas to focus on, how is that accomplished.
RS: you have a current path. assigning that path to the object. in chrome, you draw your objects, have a path. no focus, does not render. allows magnifier to zoom in on those objects. agree we need a path, but not necessarily a path object.
JM: without specific path object,
its the current path.
... very much interested in pursuing a feature here. have had 3
versions of IE that support the drawing features of canvas. i
wonder if its worth moving the at risk stuff to the 5.1 spec.
not stop implementations, but the goal to 5.1
RS: i understood that these would
be a 5.1 feature. However, we need ability to drive
magnification today
... could be a couple years out before we see a solid plan for
this.
<paulc> What does Rich means " it was agreed upon"?
PC: when you said it was agreed upon, what were you referring to?
RS: it was agreed that we were going to push the path object on to 5.1.
PC: who? the TF, the WG?
RS: PLH and Rik Cabinier at F2F.
Cant' get it done for 5.0, push it to 5.1
... we have discussed this on previous calls.
PC: I would like to encourage the
TF to decide how they would like to proceed with the current
at-risk features.
... we have to go back to Last Call. I would prefer that if we
are going to take things out, we take them out before we go
back to LC
RS: we discussed this on previous
calls that path is coming out. that can come out for LC
... working to get two implementations of drawCustomFocusRing
and drawSystemFocusRing without the Path object.
ST: at Pearson, eduPub, everyone is moving away from Flash and Flex and moving towards canvas, so focus rings for driving magnification is very important to us in the ePub industry
PC: Would like the TF to reach consensus on what they want pushed to 5.1
RS: does anyone object that anything related to path get pushed to 5.1?
CN: we have to have a formal call
for consensus.
... so you would like to get consensus that focus ring items
will remain in the spec, but anything related to path be taken
out of this LC
<Suzanne_T> ST: It's also necessary to have a focus ring that matches the browser's ring for visual design
<JatinderMann> http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/
<paulc> Revised Editor's draft: http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/
PC: longer list of at risk items
in the current editors draft
... path objects and all their methods. hit regions, all
attributes of text metrics except width.
RS: when did focus rings get added to this list?
PC: there was a lot of discussion
on the editors list. Chairs encouraged editors to come up with
list of items with solid support
... to be finalized when Rich gets back from vacation.
... need to know which of these items the TF wants to remain at
risk and what should move to Level2
... sounds like anything related to path objects get moved to
Level2. focus rings stuff will remain at risk because you
believe they will be implemented.
RS: as far as hit regions go, you
need a path for that, so move to Level2
... ellipse would have to go to level 2
... same for text metrics
... so its just focus rings that don't require path objects
CN: so you want the a11y TF to
say that focus rings should stay in the spec as at risk because
we think it will be implemented.
... for the other things, if these other items are important to
a11y, we will suggest they move to level2
... the question is, are we happy to bump any of this to
Level2
PC: yes, indicate moved to
Level2, no position or remain at risk
... as soon as possible
<chaals> ACTION: chaals to frame the questions as outlined by Paul for a TF CfC [recorded in http://www.w3.org/2013/10/31-html-a11y-minutes.html#action02]
<trackbot> Created ACTION-213 - Frame the questions as outlined by paul for a tf cfc [on Charles McCathie Nevile - due 2013-11-07].
JM: I'd love to see a test page
to see focus ring without path object.
... to see if its useful on its own
http://www.w3.org/2013/09/accessible_canvas_clock.html
RS: I think it would be nice to
have a path object, but I see no one willing to implement it
and we cannot wait for it since a hook for mag users is
critical for a11y of canvas
... there is not consensus in the browser community RE Path VS
Shape
CN: my inclination is to test the
consensus of the TF over the next week.
... are the draw focus rings methods without path valuable
enough to implement
CS: rich can you describe how this currently works?
RS: when you do drawing in canvas
you have a current path. these functions, draw
systemFocusRings, passes an object passes it to element, uses
the system color/style to draw a focus ring. location info
gives the bounding location info in the AAPI. when you use
keyboard, you can focus on object and draw ring around
it.
... custom focus ring is similar, if system has high contrast
focus ring, otherwise it passes it off to author to draw the
focus ring
JM: the main thing I wanted to understand was what happens when canvas has multiple elements.
RS: this element is in fallback
content.
... which is mapped to AAPI
... when those items in fallback content can receive focus, i
can give it a location.
JS: I think we identified which features we are comfortable pushing to Level2. want the timeline for this to be sufficient that we can get these at risk items implemented.
PC: the current charter says that
canvas is to come out of CR in this quarter.
... this decision is up to the working group. I understand the
sentiment. chairs have been working hard to figure this
out.
... plan is to take it back to LC, minimal LC, if there are
features still at risk, come back to CR, WG to determine how
long that would last.
<Suzanne_T> http://wps.pearsoned.com/wps/media/objects/13909/14243253/Patterns_System_Focus_ring.htm
-> http://www.w3.org/2013/09/accessible_canvas_clock.html Accessible Clock Demo that demos focus rings
CN: suzanne says system focus
rings are critical, jatinder says it may not be worth it
without path
... ask that the canvas timeline be long enough to make
implementations possible.
CN: we have finished our Last
Call, we received 3 negative comments on the proposed
resolutions. Others are supported. Will deal with negative
responses.
... there are factual errors in the arguments presented.
... should come to resolution soon.
... next steps:
... my proposal is to drive the spec to a standalone
recommendation (or as far as it can get with
dependencies).
... we can mark this as done.
... ask HTML WG to make the decision regarding folding it in or
not.
... what is the actual process for an extension spec? do we
pass it back to the HTMLWG are we responsible for walking
through the process, etc?
<paulc> "plan 2014" explains the answer to Charles question
PC: Plan 2014 says that if you
want to fold back in, you need to get to CR and plan to exit CR
before ??? the TF would then indicate that they wanted it back
into HTML5
... your proposal to take to spec to rec and then roll it back
in was never the intention.
JB: the question is even if we
want to reintegrate it.
... process is already well spelled out.
JB: question RE wanting to integrate it or not get more complicated as we get to later versions of the spec when use cases are still not properly understood.
JS: i do want to underscore what Judy says. I have a strong concern of controlling when a longdesc attribute is obsoleted. There may be in time when we will be happy to see this happy, but controlling the timing on that is important
JS: I would like to see it go to recommendation. Propose to maintain it separately for that reason
CN: the process of what spec is
definitive is what the most recent one is. And we have the
ability to rescind
... do we want to, as a TF, make a stand alone spec. we appear
to be well ahead of HTML at this point.
<JF> bye all
<chaals> [My final comment (for the record): I am not too troubled by the risk of the HTML WG at some future point doing something bad to longdesc - the TF will continue to exist, and if it happens we will just have to go through the same process as we have of taking up the issue again and dealing with it...]
<Judy> [Judy's comment after Charles exited call -- this seems like just the beginning of the discussion. Will need more.]
<chaals> [FWIW I agree with Judy on that - what we got sofar is just a (potentially not even representative) sample of views]