See also: IRC log
<trackbot> Date: 27 February 2014
<MarkS> scribe: MarkS
CM: chaals and mark are working on exit criteria, will be sharing with the group for consensus soon.
<chaals> MS: PaulC you asked for a timing update…
<chaals> PC: Yes, especially wrt the face to face meeting.
<chaals> … trying to figure our load on Director's calls
<chaals> MS: Might take 2-3 weeks to get WG stuff tied up (most particularly getting Exit Criteria approved).
<chaals> … so best case we do it before f2f. Or we could let if go after f2f.
CMN: we will keep Paul informed to avoid any timeline conflicts
<chaals> scribe: chaals
MS: Had a meeting on Monday. Discussed possible timelines, options.
… agreement that we should get the accessibility problem done before publishing level 1, so should get Hit regions done.
… 2 possible ways. One is to bring back what we minimally need for an accessible canvas, other is to bring back all of hitregions, put things at risk and see how much we get done.
… Group is starting to consider bringing all of hit regions as the better approach.
…Mozilla has now landed basic hitregions that inform accessibility API - which is exactly what we wanted.
… Others have asked for hit testing, which would also benefit accessibility.
RS: Think patched firefox nightly has hit testing working.
JMann: Seems we were trying to get input from google/mozilla on what we should do here.
… Good news, Ric implemented it in firefox - great effort. Bad news is that there is a lot of feedback from google that needs to be addressed. E.g. hitregions doesn't do hit testing.
… We want to implement the full feature not just a slice.
… When we asked Domenic for a timeline he said months not weeks, and it isn't clear if this is minimal or full implementation.
… So, what is the cost of doing it testing - can it be done in L1, without path?
<MarkS> scribe: MarkS
PC: I attended monday's meeting.
There was talk of bringing all of Hit Regions back in and
marking it at risk.
... I suggested the group try to find out what implementers are
implementing.
<janina> +1 to PC
PC: reports confirm that we need to be patient and figure out what needs to be put back in to L1
RS: I believe Mozilla has hit
testing in their Nightly
... we do need to resolve what we need in the spec
CN: I agree with Paul, we need to decide what goes back into the spec. Sounds like progress is being made. Hopefully we'll have a resolution soon.
JMann: I think its important to get Google on board and figure out what they want to ship
<chaals> scribe: chaals
MS: Based on Google's email I heard something different. They aren't that concerned by the spec. Domenic seemed to suggest a couple of weeks' work, but that they have other higher priorities.
… sounded like they would implement everything.
<MarkS> scribe: MarkS
<scribe> scribe: MarkS
RS: there was discussion about where these conversations take place. Right now, of critical importance is what elements can be used as fallback content
CM: Our task is to work on HTML stuff in the W3C. It sounds like there is work to do, some hurdles, but the group is making progress, and don't have a particular issue they need the full TF to help resolve at this stage.
JMann: Is dominic referring to
everything in the spec? i worry if they want to do all of it.
sounds like feature creep. especially regarding the path
object.
... i think if we put everything in, we will run into timing
issues.
JB: Be great to get this back on a good course.
JS: I think all of us want to do it all. We have to worry about publishing a spec. The specificity we need from Dominic is what order we would like these done in.
CM: HTML WG is meeting at eBay in San Jose April 8-9. Need to register if you want to attend
<chaals> face to face meeting wiki page
PC: The wiki page is very
extensive. A lot of agenda ideas there. We should consider
using this F2F to work through Canvas.
... all the TF work is up for discussion at the F2F
... Please feel free to edit the wiki page for the F2F
<paulc> See https://www.w3.org/wiki/HTML/wg/2014-04-Agenda#Potential_Topics for draft agenda topics
http://lists.w3.org/Archives/Public/public-html-a11y/2014Feb/0064.html
-> http://lists.w3.org/Archives/Public/public-html-a11y/2014Feb/0064.html Interest in attending F2F
LW: made very good progress over
the past few weeks.
... there are a lot of media related bugs. be great if the
media sub team could get back in action
... Mark sent around an email
<chaals> scribe: chaals
MS: Paul we've been closing bugs. Some are not CR-critical but would like to consider in 5.1
… Previously you mentioned closing old bugs and opening new ones for 5.1 as there was an issue of bringing all the history.
… we have been finding the history to often be relevant, so we wonder if you are OK with reassigning bugs to 5.1 component.
<scribe> scribe: Marks
<scribe> scribe: chaals
PC: You are asking to reopen these bugs that were on an old component?
MS/LW: Yes
<MarkS> PC: If you reopen it from an old component, how do you bring it to the attention of the editors.
PC: So how would it get drawn to attention of 5.1 editors? You propose to change the component, right?
LW: Yep.
PC: How many bugs?
MS: Maybe a dozen.
PC: I'm flexible. Please do this very transparently if it is what you are doing. Give people an opportunity to see what you are doing. Don't just quietly change the component - nobody will notice
<MarkS> PC: Suggest its done transparently, so that everyone knows what is going on. Changing the component is not very obvious.
LW: Will it be enough to include a comment in the bug e.g. "mass-moved to…"
PC: I don't think this is the same as Mike's example
PLH: Don't think we want the HTML 51 editors to work on those bugs yet.
… would be good to clarify to them what we expect them to do.
LW: Responsibility is clearly on the TF to provide rationale for changing the status…
PLH: OK. So until we have that info don't reopen the bugs.
PC: Agree.
… I presumed you had the rationale before you were doing that. I suggest working on them in the TF first.
…at that time changing the coponent makes sense
<MarkS> scribe: MarkS
CN: Does that cause trouble for
the Bug Triage team? Should they be moved to the a11y
component?
... component is better than a keyword
PC: I'm not convinced that moving bugs through components is what we want.
CN: We're saying these are not in HTML5 anymore, they are not ready for HTML5.1 so lets move them to a11y component until the TF is in agreement what they want to do with the bug.
CS: What about putting them in 5.1 and assigning them to a member of the TF
CM: Is this something that the bug triage could take directly to editors of html?
LW: yes
<chaals> ACTION: Leonie to figure out how to sort out this process [recorded in http://www.w3.org/2014/02/27-html-a11y-minutes.html#action01]
PC: there is a component HTML
a11y TF.
... last time we talked about this, we said we wouldn't use
it.
CM: This is the use case we intended it to be used for.
-> https://www.w3.org/Bugs/Public/show_bug.cgi?id=13434 Bug 13434 - Media element section does not state that tracks are to be synchronized with video
<chaals> scribe: chaals
MS: We thought this is editorial...
DM: Is there any way of misinterpreting this?
MS: That was our concern
JS: There is a use case for non-sychronisation, e.g. when yu are speed-reading a transcript.
DM: Do we want to require it to be synched?
LW: A transcript would be the non-time-dependent component.
<paulc> To LW: See http://tinyurl.com/jvo4sq8 which indicates there are 4 bugs in the HTML A11Y TF component. I expected it to be empty.
JS: We had a proposal for synchronized timescript. Didn't get consensus
LW: Isn't that captions?
CS: There was a discussion 2-3 years ago about using track for transcripts, but was knocked back 2-3 years ago.
LW: Question from Bug triage is whether the bug is an editorial change request
JS: I think it is implicit that there is a use case for synchronization, but does requiring that break the other use case of just reading the track?
DM: Is there a mechanism to grab it?
JS: It is a user agent question - and I think part of what Apple wanted to achieve. THey thought it was a mainstream requirement for that use case.
… e.g. enable highlighting the link to it
DM: If you have no timing there isn't captioning.
<MarkS> scribe: MarkS
CM: UA guidelines state that you
should be able to get at that text, not HTML's job to do
that.
... I'm not convinced we have an issue to resolve here.
<janina> +1 to cn
-> https://www.w3.org/Bugs/Public/show_bug.cgi?id=13435 Bug 13435 - Editorial changes to The Video element (3 of 5)
<chaals> ACTION: LW to raise bug 13434 to the TF by email [recorded in http://www.w3.org/2014/02/27-html-a11y-minutes.html#action02]
<trackbot> Created ACTION-233 - Raise bug 13434 to the tf by email [on Léonie Watson - due 2014-03-06].
<chaals> scribe: chaals
MS: If you pause on an unrendered frame, the caption rendered should be that which covers the frame rendered (last available frame).
… editor thinks it is already required, we didn't think so. Do we want to open the bug on 5.1 or accept it as done and close it?
CMN: If there is a proposal to clarify in the text it would make sense to propose, but otherwise we are just asking the HTML editorial group to change their collective mind.
MS: There is a proposal in the bug
<MarkS> scribe: MarkS
<chaals> ACTION: LW to raise bug 13435 to TF in email [recorded in http://www.w3.org/2014/02/27-html-a11y-minutes.html#action03]
<trackbot> Created ACTION-234 - Raise bug 13435 to tf in email [on Léonie Watson - due 2014-03-06].
<chaals> scribe: Marks
CS: ARIA WG has been discussing
how to make it easier to handle API mappings.
... In ARIA we decided to do a core document, then to do
technology specific ones for HTML and SVG
... for HTML seems to be the same one for HTML API map
doc
... for SVG, Rick was going to be the editor for that. makes
sense for these to be owned by the group responsible for the
technology
... wondering how HTML feels about this
... and we need an editor
JB: I'm interested in why the
original work stalled. Concerned about potential scope
reduction. The work is important. Have you considered adding
other editors and keeping the same scope?
... before this goes to the WG, I think we need more discussion
on this in the TF. I am concerned about scope reduction.
CS: this was proposed by Rich. I
can have them speak more to it.
... all the same mappings would be there. instead of separate
document
PC: Just wanted to remind Janina that PF would discuss this and report back. Seems like Cynthia is taking this to TF to bring to WG. Can cynthia write this up and share it with the TF for review for next week.
JS: Might be too early to discuss
this. Michael has asked we wait until after 1.0 is out. There
are a few more details we need to iron out first.
... the write-up should get consensus in PF and in WAI CG
before we bring this through the TF and the WG.
CS: I was using this as an opportunity to get some feedback for the write-up.
<David_> take it up next week?
CS: I want to talk about those next steps and recruit staff.
<chaals> [adjourned]
<chaals> [DOM report will be on next week's agenda, and I hope Janina will provide an email today of what she wanted to say]