See also: IRC log
<trackbot> Meeting: HTML Accessibility Task Force Teleconference
<trackbot> Date: 05 December 2013
<scribe> scribe: MarkS
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.
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.
JS: A couple of bugs were filed based on our response to LC comments.
<paulc> All MSE LC bugs: 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: 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> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23663
<paulc> 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 http://www.w3.org/2013/12/05-html-a11y-minutes.html#action01]
<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].
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> http://www.w3.org/WAI/PF/HTML/track/actions/215
<plh> http://lists.w3.org/Archives/Public/public-html-a11y/2013Dec/0011.html
<plh> 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: 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> 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> 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 http://www.w3.org/2013/12/05-html-a11y-minutes.html#action03]
<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.