- From: Mark Sadecki <mark@w3.org>
- Date: Thu, 05 Dec 2013 13:49:52 -0500
- To: HTML A11Y TF Public <public-html-a11y@w3.org>
Hello,
The minutes for the HTML Accessibility Task Force Teleconference 05 December 2013 are available in HTML and plain text below:
HTML:
http://www.w3.org/2013/12/05-html-a11y-minutes.html
TEXT:
[1]W3C
[1] http://www.w3.org/
HTML Accessibility Task Force Teleconference
05 Dec 2013
See also: [2]IRC log
[2] http://www.w3.org/2013/12/05-html-a11y-irc
Attendees
Present
PaulC, MarkS, PLH, Judy, RichS, Wuwei, Janina, Aardrian,
Jatinder, Rik_Cabanier, JohnF, Cynthia, Chaals, SamR
Regrets
Leonie
Chair
Chaals
Scribe
MarkS
Contents
* [3]Topics
1. [4]Mutation events and their replacements
2. [5]Resolution of longdesc LC comments, next steps
3. [6]Resolution of MSE comments
4. [7]Canvas 2D context. Next steps…
* [8]Summary of Action Items
__________________________________________________________
<trackbot> Meeting: HTML Accessibility Task Force
Teleconference
<trackbot> Date: 05 December 2013
<scribe> scribe: MarkS
Mutation events and their replacements
CN: because HTML WG is now publishing DOM4, DOM falls into the
work of the a11y TF.
... the TF cares about the replacement of mutation events, so
we will be following this
RS: I'm working on SVG2 spec, and we just moved from
referencing DOM2 to DOM3. Wondering what version we should be
aiming for?
CN: I would recommend DOM4. It's not finished, but previous
ones are soon to be considered "legacy" documents, but you
should definitely check.
RS: they want to go to LC by the end of the year, would we have
a hard time doing this if we start referencing DOM4?
CN: I would check with Alex and Robin, the editors of the DOM4
spec for expected timeline.
RS: we would like to reference DOM4 for SVG to better bring it
inline with HTML
... there is a UI Events spec. Doesn't look like browsers have
implemented new keyboard interface that is in this spec. Is it
going to be different in DOM4?
PLH: DOM4 does not define UI Events
RS: In UI Events, they introduce an extension to the DOM3
keyboard interface. Trying to figure out where we go with that,
keyboard is important for a11y. I will bring it up today in our
call.
Resolution of longdesc LC comments, next steps
CN: Chairs believe there is consensus on proposed responses.
Will be sending those out soon. Then we will implement
editorial changes next, then we will be ready to either request
publication as a standalone spec or folded back into HTML
... since this will presumably happen well before HTML5 is
published, both options are viable. Makes sense to publish on
its own and let HTML decide if they would like to include it.
Resolution of MSE comments
JS: A couple of bugs were filed based on our response to LC
comments.
<paulc> All MSE LC bugs: [9]http://tinyurl.com/lowrcmq
[9] http://tinyurl.com/lowrcmq
CN: does this need to be handled this week?
JS: no, I think we are interested in clarifying the reason for
a specific issue.
<paulc> A11Y bugs:
[10]https://www.w3.org/Bugs/Public/show_bug.cgi?id=23661
[10] https://www.w3.org/Bugs/Public/show_bug.cgi?id=23661
CN: to clarify, this has to do with multiple video streams for
sign-language captioning
<paulc>
[11]https://www.w3.org/Bugs/Public/show_bug.cgi?id=23663
[11] https://www.w3.org/Bugs/Public/show_bug.cgi?id=23663
<paulc>
[12]https://www.w3.org/Bugs/Public/show_bug.cgi?id=23661#c2
[12] https://www.w3.org/Bugs/Public/show_bug.cgi?id=23661#c2
JS: we would want the acknowledgment that this is required for
accessibility. That the spec is sufficient to support a11y at
that level. We originally made this intention clear back in
2010.
CN: says the MSE spec is following the HTML spec. We want an
acknowledgement of the use case in both specs, nothing
normative.
... suggest Janina should clarify what we are looking for, use
cases, non-normative, or normative text, and come back to us
with a proposal on this for next week.
<chaals> ACTION: Janina to bring back a proposal for how the TF
should deal with HTML bug 23661 (normative change, informative
editorial change, …) [recorded in
[13]http://www.w3.org/2013/12/05-html-a11y-minutes.html#action0
1]
<trackbot> Created ACTION-219 - Bring back a proposal for how
the tf should deal with html bug 23661 (normative change,
informative editorial change, …) [on Janina Sajka - due
2013-12-12].
Canvas 2D context. Next steps...
CN: asked if we wanted to move at risk items to L2. a11y TF
wanted to proceed with focus ring items at risk. There was a
questions RE: even if it is implemented, does it solve the
problem.
<plh> action-215?
<trackbot> action-215 -- Philippe Le Hégaret to Work with
jatinder to open issues on canvas api -- due 2013-11-28 --
PENDINGREVIEW
<trackbot> [14]http://www.w3.org/WAI/PF/HTML/track/actions/215
[14] http://www.w3.org/WAI/PF/HTML/track/actions/215
<plh>
[15]http://lists.w3.org/Archives/Public/public-html-a11y/2013De
c/0011.html
[15] http://lists.w3.org/Archives/Public/public-html-a11y/2013Dec/0011.html
<plh>
[16]http://w3c-test.org/web-platform-tests/submissions/457/2dco
ntext/drawing-paths-to-the-canvas/
[16] http://w3c-test.org/web-platform-tests/submissions/457/2dcontext/drawing-paths-to-the-canvas/
PLH: I had an action item to work with Jatinder and file bugs
based on system and custom focus rings
... i also wrote some tests.
CN: result of tests?
<plh>
[17]http://w3c-test.org/web-platform-tests/submissions/457/2dco
ntext/drawing-paths-to-the-canvas/drawSystemFocusRing_005.html
[17] http://w3c-test.org/web-platform-tests/submissions/457/2dcontext/drawing-paths-to-the-canvas/drawSystemFocusRing_005.html
PLH: with proper flags set in Chrome Canary and FF Nightly,
they mostly worked
... Big question, do you draw a focus ring whenever the focus
event is called, even if the element is not in focus?
RS: It has to be focused in order for it to draw the ring
PLH: but what about a paragraph, .
... is the spec clear enough or not? the spec actually doesn't
make it clear that this is a bug.
<plh> " or if the element would have a focus ring drawn around
it,"
PC: decision by the TF on the CfC in the TF suggested that both
system and custom focus rings should maintain at risk status.
Rich is suggesting that customFocusRing should move to L2,
which is not inline with results of TF CfC
<rubys> +1
<rubys> +1 to paul's statement
<richardschwerdtfeger> +1
PC: what happens if one or more of these bugs causes a
substantial change, requiring this spec to go back into LC 2
more times. Should try to flatten as many of these bugs as
possible before we go back into LC for the first time
<Zakim> chaals, you wanted to say I am happy to call a new CfC,
given there is evidence the consensus has changed at least on
drawCustomFocusRing
RS: we can work on getting them closed before we go back.
CN: given that the consensus has changed, I will happily call a
new CfC to see if we want to move drawCustomFocusRing to L2.
<richardschwerdtfeger> hi
CN: for drawSystemFocusRing it seems the best approach is try
to squash bugs.
JS: we discussed this in PF and I think we are close to having
something we all agree on. Part of the reason why there has
been a change in drawCustomFocusRing is that the approach
relies on media query functionality that is not available yet.
... we didn't think it would take more than 60-90 days to close
existing bugs.
RS: I've been talking with Rik on wording to address these bugs
already.
CS: Rich, have you brought back the sub-team?
RS: haven't done so, but if you think that would help
CS: please include Jatinder
PC: Normally what we would do is defer to the editors of the
spec. Already good comments on bugs, there are conversations
happening already. Should make sure the canvas editors are
aware they are empowered to close/work on these bugs where
possible.
RC: we already tried to go through CR six months ago. We were
told focus rings were almost ready. We ran into these issues. 4
months later, more issues. Worried that 6 months from now we
will find even more.
... i would like to move forward sooner. leave them at risk,
which they may fail to survive. work on them in L2
JB: I think we are making progress here. There have been a lot
of conversations happening. We have some implementations, those
are being reviewed and tested. We have more specifics now than
we had previously, which indicates improvement.
... lets follow through with identifying issues, addressing
them and testing them.
PC: if those problems are not reflected in existing CR bugs,
then the right way to have a dialog and get consensus is to
file bugs and start working on them. Having the bugs causes the
dialogs to happen.
... its very possible that a CfC to go back to LC will fail if
we don't close some of these bugs.
... i would like to take a couple weeks to see where we stand
on the bugs.
... and document any additional bugs.
<plh> [18]https://www.w3.org/Bugs/Public/show_bug.cgi?id=23980
[18] https://www.w3.org/Bugs/Public/show_bug.cgi?id=23980
PLH: if there are bugs missing from my list, please file them.
There is one bug addressing the naming issue. I encourage
people to comment if they have a position on any of these.
JM: RE: Bug on name. There was a historical reason. Would help
if that history was clarified in the bug comments.
<Zakim> chaals, you wanted to ask Rich to ensure that we keep
the TF and WG informed about where we are at.
JM: would love to see notes justifying the method naming
CN: I agree, file the bugs, discuss the bugs, keep TF and WG
informed on your progress.
PLH: I don't have access to the history of the naming issue.
Rich has started to include some information.
RS: Perhaps just getting rid of the word "ring" from the method
names would work.
JB: lets track it with normal group process
RS: thanks to PLH for filing the bugs.
PLH: would love to have someone look at and approve the tests.
<plh>
[19]http://w3c-test.org/web-platform-tests/submissions/457/2dco
ntext/drawing-paths-to-the-canvas/
[19] http://w3c-test.org/web-platform-tests/submissions/457/2dcontext/drawing-paths-to-the-canvas/
RC: most important thing about focus ring is that the method
updates the AAPI. I don't know how we can test that.
... under the hood it tells the OS where the focused region is
JB: WAI is currently trying to document how to test a11y
related issues.
CS: they are OS APIS so there are ways to automate this type of
testing.
CN: longdesc has requirements to test AAPIs. We looked at AAPIs
directly/manually.
... sounds like we agree to what needs to be done.
PC: I heard a suggestion from CS that a group of people get
together to work on this. Can we get Rich and Rik to coordinate
a meeting to make progress with all the players?
JS: canvas sub-team?
<chaals> ACTION: MarkS to follow up on getting the canvas
sub-team working [recorded in
[20]http://www.w3.org/2013/12/05-html-a11y-minutes.html#action0
3]
<trackbot> Created ACTION-220 - Follow up on getting the canvas
sub-team working [on Mark Sadecki - due 2013-12-12].
JS: there were some questions regarding history of naming
methods, etc. There was a separate list for canvas discussions
that could be referenced. Might be good to go back to that.
CS: please include me as well
CN: The more we get documented, the better off we are later on,
but getting the work done is high priority.
<chaals> [adjourned]
<paulc> Thanks.
Summary of Action Items
[NEW] ACTION: Janina to bring back a proposal for how the TF
should deal with HTML bug 23661 (normative change, informative
editorial change, …) [recorded in
[21]http://www.w3.org/2013/12/05-html-a11y-minutes.html#action0
1]
[NEW] ACTION: MarkS to follow up on getting the canvas sub-team
working [recorded in
[22]http://www.w3.org/2013/12/05-html-a11y-minutes.html#action0
3]
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [23]scribe.perl version
1.138 ([24]CVS log)
$Date: 2013-12-05 18:46:49 $
[23] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[24] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 5 December 2013 18:49:54 UTC