See also: IRC log
<trackbot> Date: 17 October 2013
<scribe> Meeting: HTML-A11Y Task Force Teleconference
<scribe> scribe: MarkS
KZ: Hello everyone, I am the newest member of WAI and I will be the new web accessibility engineer located in Beihang. I have a long history of working in the field of accessibility, most recently at IBM developing accessibility solutions for IBM customers.
CN: CfC passes in the TF. HTML WG will most likely wait for PF to approve the new work statement and consensus procedures
<chaals> discussion / development of responses to LC comments
CN: ready to propose a set of resolutions to the comments received during the LC comment period
...we have a survey that we will put as a formal call for consensus that will run through the next week.
...most comments are editorial in nature.
...in response to James Craig, there is a new 'should' requirement. It is possible that this will require an additional LC period. If so, it would add 3 weeks to the longdesc timeline.
...please review the comments, look carefully at the proposed changes to the spec in addition to the responses.
https://www.w3.org/2002/09/wbs/44061/ProposedLongdescCommentResponses/
MS: it is now open through next friday
PC: is this CfC subject to the old TF rules or the new TF rules (7 days, spanning a meeting)
CN: this satisfies the old
requirements (and the new)
... we have accepted as a group, a set of 20 tests, with
results for many of those. We are still looking for results on
AAPIs
MS: David and I will finish testing and record results by end of day tomorrow
CN: These tests should now be entered into the HTML testing framework.
JS: In last week kris mentioned that it shouldn't be too difficult to get our tests into the HTML test suite.
MS: I can work with the HTML testing TF to get those tests in there.
<chaals> chaals' github account (the test results are in longdesc-tests)
LW: can I shadow you during that process?
DM: me too
MS: yes I can
<chaals> ACTION: marks to coordinate putting the tests into the HTML harness [recorded in http://www.w3.org/2013/10/17-html-a11y-minutes.html#action01]
<trackbot> Created ACTION-208 - Coordinate putting the tests into the html harness [on Mark Sadecki - due 2013-10-24].
CN: We have been asked to review MSE for accessibility support. Are there any particular comments, results.
AR: I sat down last night to look at MSE. Was concerned with text track, syncing of video, etc. I did not see any major concerns.
CN: The key thing to be sure of is that synchronized tracks don't get lost or out of sync when you move through the media timeline. Should we ask the group to clarify that question?
...would help to ask them explicitly
AR: I think there is value in having them state that explicitly.
<paulc_> paulc
JS: It was not clear during my review with Mark that the requirement the TF has for keeping two video tracks synchronized was met (sign language video) We should ask that question as well
PC: why are these questions not pertinent to the HTML5 spec?
AR: I think it should be addressed in HTML5 as well, but this spec addresses certain technical requirements that are important to this functionality.
CN: the kind of change we want is to be explicit that accessibility/parallel tracks to be synchronized when you move/jump around the timeline.
<chaals> ACTION: chaals to request that the MSE spec be explicit that parallel tracks (e.g. for accessibility) need to be re-synched when jumping around a streamed resource [recorded in http://www.w3.org/2013/10/17-html-a11y-minutes.html#action02]
<trackbot> Created ACTION-209 - Request that the mse spec be explicit that parallel tracks (e.g. for accessibility) need to be re-synched when jumping around a streamed resource [on Charles McCathie Nevile - due 2013-10-24].
<chaals> action-209 due today
<trackbot> Set action-209 Request that the mse spec be explicit that parallel tracks (e.g. for accessibility) need to be re-synched when jumping around a streamed resource due date to 2013-10-17.
PC: maybe its 2.4.5 Changes to selected/enabled track state
...deals with synchronization.
<paulc_> 2.4.5 Changes to selected/enabled track state
<paulc_> http://www.w3.org/TR/media-source/#active-source-buffer-changes
a11ytf keyword, marked as resolved and either won’t fix, needs info, or later: http://is.gd/VkTxop
https://www.w3.org/Bugs/Public/show_bug.cgi?id=10905
CN: I think command is being dropped from HTML5 and that is how accesskey worked
...lets leave it as resolve later. I will take a look at it
JS: I think command is something we should take up in 5.1
https://www.w3.org/Bugs/Public/show_bug.cgi?id=10782
problems with button example for accesskey
CN: I will need to look carefully at this one (in the spec) before I can comment
...suggest to leave it for now and assign me an action item
https://www.w3.org/Bugs/Public/show_bug.cgi?id=10888
Access Command Requirements for HTML5
CN: Will leave this one until we're happy with how it all pans out
...this is master bug
https://www.w3.org/Bugs/Public/show_bug.cgi?id=10994
accessKeyLabel can expose new information about the user and possibly also other origins
CN: also not clear if accesskey label is a good solution. I would like to open this bug
...because the problem exists.
...suggest we reopen this bug and re-examine it.
CN: will have to re-target it since it is currently targeted at LC1
JS: seems like we should target all of these accesskey related bugs to HTML5.1
PC: are you actually talking about taking this bug, opening a new one with a new target (5.1) and pointing back to this one?
CN: No, I propose we re-open this bug and change the component to a future product.
PC: we don't change components because we lose the history
...you should open a new bug and link it back to this one.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=13451
Don't disallow image map on object
CN: don't think there is a specific impact here, and there is almost no browser implmentation. Not sure what to do with this one.
JS: I'm not clear what the tie-in is
<chaals> [I propose that we leave this as resolved and pick some other battles]
<chaals> RESOLUTION: close bug 13451
<cyns> I have a bit of new business to add to the end
<scribe> done
https://www.w3.org/Bugs/Public/show_bug.cgi?id=10252
HTML5 hard-binds "Action" to accesskey key-press
JS: Same solution as before?
[agreement]
<cyns> I'd like to put canvas accessibility and staging across 5.0, 5.1 and beyond on the agenda for next week. Have some IE folks interested in attending to disucss
JS: it is possible that accesskey gets superseded by landmarks
<chaals> [I am not happy to drop this bug yet]
https://www.w3.org/Bugs/Public/show_bug.cgi?id=11140
Subject: Physical Keys and Gestures for "accesskey" attribute The use of ASCII/Unicode code points for key binding has numerous well-known drawbacks. There are vital physical keyboard keys with no Unicode representation. Even for the main alphabet keys sp
<cyns> on cavas, wondering who besides Rich needs to be there?
JS: propose the same solution as other accesskey bugs
[agreement]
<janina> Cyns, don't understand 'cavas'
<chaals> [you mean leave them as is, or give up on them? (I am not happy taht we give up on them)]
https://www.w3.org/Bugs/Public/show_bug.cgi?id=13511
document parsing should discuss setting up accessibility APIs
<janina> Charles, treat as with other AccessKey related -- move to html.next
<chaals> [OK]
CS: since the spec we need to reference is not ready yet, we should create a new bug in 5.1 and link to this one
<janina> Yes, Can do
<scribe> ACTION: Cyns to create new bug HTML5.1 and link to original 13511 [recorded in http://www.w3.org/2013/10/17-html-a11y-minutes.html#action03]
<trackbot> Created ACTION-210 - Create new bug html5.1 and link to original 13511 [on Cynthia Shelly - due 2013-10-24].
CS: can we put canvas on the agenda for two weeks from today?
<paulc_> Ted from Apple?
JS: I think we should start the canvas sub team up again. Steve, Rich, Mark Pritchard, Frank Olivier was active in that, and a few others.
PC: was hober involved?
CS: I know Rich was really driving it.
JS: agree to put this on the schedule in two weeks.
<janina> call 2265