See also: IRC log
<trackbot> Date: 13 February 2014
<janina> Meeting: HTML-A11Y Task Force Teleconference
<scribe> scribe: MarkS
<chaals> MS: Chaals is slacking…
<chaals> … but we're getting on with it and will continue to update people.
MS: Chaals and I continue to work on items
<chaals> MS: We were waiting to hear back from Mozilla about trying out hit regions...
<chaals> … yesterday they said that they think this approach is actually looking good.
<chaals> … they have a prototype and expect to show that next week. They do not intend to drop drawFocusIfNeeded. That is good news all around...
<chaals> … Unsure about status of Chrome.
<chaals> JB: Good to hear. Understand that hit test depends on several things, including perhaps path which is not going to get into the current spec. Would implementation get this into level 1?
<chaals> MS: Think the spec will require work on hit regions and path, but don't think this is *months*.
<chaals> … sowe would have to go through some administrative hoops to get this into L1
<chaals> JB: With implementations, this is a pretty good reason to put it back in…
<chaals> MS: Asked them to summarise their position in public, haven't seen that yet.
JS: interested in finding out what the timeframe will be for Hit Regions
<janina> http://lists.w3.org/Archives/Public/public-html-a11y/2014Feb/0026.html
JS: SteveF has shared the list of
bugs that HTML WG had requested regarding ALT
work/changes
... we have been talking about syncing 5.1 and 5.0 specs
... Paul had some ideas on how to move forward process wise,
but he is not here.
-> http://www.w3.org/2014/02/12-a11y-bugs-minutes.html Minutes from Bug Triage
MS: Bringing one bug to the
canvas sub team
... Bringing one bug to the canvas sub team
... Reopened a bug against 5.1
<scribe> ...Closed two
-> https://www.w3.org/Bugs/Public/show_bug.cgi?id=13549 13549 4.10.18 associating form elements with forms that do not contain them can cause navigation problems for AT and keyboard users
CS: This could be addressed with a WCAG failure. but should also bring it against 5.1
JS: Feel like this should cause a
validation failure
... should be a 5.1 issue
CS: If there isn't a WCAG failure, there should be
DM: Please send a note to WCAG
-> https://www.w3.org/Bugs/Public/show_bug.cgi?id=12964 12964 <video>: Declarative linking of full-text transcripts to video and audio elements
JS: talked about this in Media
sub team. syncing functionality could be added if
programatically linked
... there is mainstream interest in this
... more than just a longdesc for video
... think we should defer this to 5.1
... cognitive accessibility could be improved with this
feature
AR: wondering how this is
different than closed captioning.
... don't want to see a situation where we duplicate a feature
that already exists.
JS: another use case is for people who want to read through the transcript.
DM: WCAG recommends authors put text transcripts on the page of the video.
-> http://tinyurl.com/p5qkc2z LC1 HTML spec Resolved NEEDSINFO, INVALID, WONTFIX
https://www.w3.org/Bugs/Public/show_bug.cgi?id=13273
Clarify text in media element user interface section
Agreement that this would be better as a MUST requirement.
OK with moving it to 5.1
We should test current support
DM: comes back to that old conversation about disabling javascript.
JS: potential for use case for
disabling js in order to get around inaccessible custom
controls.
... anyone interested in keeping this in 5.0?
CMN: I am in favor of that, but think we would have a hard time getting it into 5.0
DM: it is a failure in WCAG
CS: is there a failure technique for this?
DM: yes, if you can't reach everything with the keyboard
CMN: I think we should clarify that we are not moving this to 5.1 just because we couldn't get it into the 5.0 timeline. It's something we should have done in 5.0
https://www.w3.org/Bugs/Public/show_bug.cgi?id=13437
Editorial changes to The Video element (5 of 5)
CMN: the argument they use to reject this bug seems like nonsense to me.
CS: Seems like a non-issue to me
agreement from the group
CMN: If we want to keep this
requirement, then its not that difficult to explain how it
could be done. We would reopen this in 5.0.
... we would like to see implementers pick up the a11y features
and get it right. They could be put at risk if they don't
... I think we want this always available (not necessarily
visible)
... I suggest we open this and get it right. We want to make
sure the control is available, but not necessarily visible.
Right now its not clear that the UA is required to make it
available.
... reopen and discuss it quickly.
PLH: If you do that you should add more info.
CMN: reopen it, assign it to me and put in some clarifying info.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=13275
Display of media control UI when scripting is disabled
CMN: This looks the same as the previous bug. Mark it as a duplicate and state the intention is the same. would like to fix it in 5.1
https://www.w3.org/Bugs/Public/show_bug.cgi?id=13461
Commentary on Issue #30 (longdesc) from the Association of American Publishers
JB: progress was made on this in the TF. They are aware of that. Since we are nearly complete with our extension spec, we can thank them for offering comment, point to the longdesc extension, etc.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=13651
Missing alt should not be considered conforming in the presence of figcaptions over 50 words in length.
JB: will take time to write up
the research I did on this issue and determine a
threshold
... propose it stays assigned to mark and gets reopened in
5.1
JS: I think the pushback on this was around the specific number.
JB: right we need to justify the
threshold
... need examples to backup the threshold