21:24:57 RRSAgent has joined #html-a11y
21:24:57 logging to http://www.w3.org/2011/04/27-html-a11y-irc
21:24:59 RRSAgent, make logs world
21:24:59 Zakim has joined #html-a11y
21:25:01 Zakim, this will be 2119
21:25:01 ok, trackbot; I see WAI_PFWG(A11Y)5:30PM scheduled to start in 5 minutes
21:25:02 Meeting: HTML Accessibility Task Force Teleconference
21:25:02 Date: 27 April 2011
21:25:29 :)
21:25:50 agenda+ Identify Scribe
21:25:51 agenda+ Next Steps on Multitrack
21:25:53 agenda+ Text Formats Change Proposal
21:25:54 agenda+ Actions Review http://www.w3.org/WAI/PF/HTML/track/actions/open
21:25:56 agenda+ Other Business?
21:25:57 agenda+ be done
21:26:08 rrsagent, make logs public
21:27:19 WAI_PFWG(A11Y)5:30PM has now started
21:27:26 +John_Foliot
21:27:31 janina has joined #html-a11y
21:28:39 +??P3
21:29:43 zakim, who's here?
21:29:43 On the phone I see John_Foliot, ??P3
21:29:44 On IRC I see janina, Zakim, RRSAgent, silvia, JF, MikeSmith, [tm], trackbot
21:29:54 zakim, item 1
21:29:54 I don't understand 'item 1', JF
21:29:54 zakim, ??P3 is Janina
21:29:55 +Janina; got it
21:30:16 zakim, take up topic 1
21:30:16 I don't understand 'take up topic 1', JF
21:30:25 zakim, agenda?
21:30:25 I see 6 items remaining on the agenda:
21:30:27 1. Identify Scribe [from JF]
21:30:29 2. Next Steps on Multitrack [from JF]
21:30:31 3. Text Formats Change Proposal [from JF]
21:30:32 4. Actions Review http://www.w3.org/WAI/PF/HTML/track/actions/open [from JF]
21:30:34 5. Other Business? [from JF]
21:30:34 6. be done [from JF]
21:30:42 zakim, next topic
21:30:42 I don't understand 'next topic', janina
21:30:47 zakim, take up agenda 1
21:30:47 agendum 1. "Identify Scribe" taken up [from JF]
21:30:54 scribe: JF
21:31:09 +silvia
21:31:15 Sean has joined #html-a11y
21:31:28 +mark
21:31:59 +Judy
21:32:57 mark has joined #html-a11y
21:33:12 frankolivier has joined #html-a11y
21:33:43 zakim, passcode
21:33:43 I don't understand 'passcode', Sean
21:33:47 +[Microsoft]
21:33:52 zakim, mute me
21:33:52 silvia should now be muted
21:34:02 Zakim, Microsoft is Frank
21:34:02 +Frank; got it
21:34:15 zakim, code?
21:34:15 the conference code is 2119 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), Sean
21:34:49 its telling me its not valid
21:35:01 + +54558aaaa
21:35:28 zakim, aaaa is Sean
21:35:28 +Sean; got it
21:35:31 zakim, +54558aaaa is Sean
21:35:31 sorry, Sean, I do not recognize a party named '+54558aaaa'
21:35:51 JS: thinks we should have a post-mortem on issue 152, what happened and where are we now?
21:36:16 +Eric_Carlson
21:36:18 JS: believe we are still on track...
21:36:27 zakim, unmute me
21:36:27 silvia should no longer be muted
21:36:56 SF: the chairs decided what we were trying to do was not possible based on WG rules
21:37:09 everyone else pulled back their change proposals
21:37:26 so that ian's work moved forward uncontested
21:37:34 and now we even have some of the bugs resolved
21:38:04 s/SF/SP/
21:38:05 JS: does anyone have anything to add to that?
21:38:18 JB: were we not at some point relying on ian's proposal?
21:39:06 JS: maybe that would be an introduction to where we are now?
21:39:53 EC: what happened was when we returned from F2F, ian had a CP. Based on email with many, he incorporated those changes into WHAT WG
21:40:12 based on feedback, he was updating running spec at WHAT WG, but not his original CP
21:40:23 thus his CP was out of date
21:40:58 so ian withdrew his CP, as did others, and so the WHAT WG text moved into the W3C spec, and John added the 5 bugs against the revised W3C spec text
21:41:16 JB: thanks for the overview - added clarrity
21:41:28 we need to be careful on watching where text is evolving
21:41:56 with a goal to avoid this confusion again
21:42:22 MW: was watching process, and wanted to be sure his concerns were included into one of the CP's
21:42:35 and what ended up was that was not what happened
21:42:52 conclusion - always have a valid Change proposal in hand
21:43:22 JB: this was unusual for w3C process
21:43:35 this was atypical
21:43:46 JS: many found this quite confusing
21:44:29 EC: to be fair, our problem was that we did not have a valid change proposal
21:45:05 JB: that may be part of the problem/issue, but that was not 100% clear - there was a missed understanding
21:45:20 the concensus process was lost
21:45:34 MW: the problem was there was no CP last Friday
21:45:57 SP: not unhappy with the process, we got what we needed, and the bugs are being pursued. In essence we got what we needed
21:46:36 EC: Agree with Silvia - in the end we resolved a contentious issue by amicable resolution
21:47:10 JS: generally good. So we now have those 5 bugs, some of which appear to be resolved. Do we expect this all to be resolved before LC?
21:47:28 http://www.w3.org/Bugs/Public/show_bug.cgi?id=12544
21:47:29 http://www.w3.org/Bugs/Public/show_bug.cgi?id=12545
21:47:31 http://www.w3.org/Bugs/Public/show_bug.cgi?id=12546
21:47:32 http://www.w3.org/Bugs/Public/show_bug.cgi?id=12547
21:47:34 http://www.w3.org/Bugs/Public/show_bug.cgi?id=12548
21:47:36 JB, can we get a status check
21:48:14 Bug 12544 - MEDIA CONTROLLER requires track kind for in-band tracks
21:48:24 SP: this has been applied
21:48:37 we now have a get @kind function in the spec
21:48:55 MW: there remains an outstanding question about what @kind values can be gotten back
21:49:28 how do we decide - not in concurrance with ian's perspective, woulod prefer that W3C define the list
21:49:38 should be independant of the container formats
21:49:50 so there should be a single place where these are define
21:50:07 JSD: the fact that they are marked resolved may not be sufficient for this group
21:50:14 s/JSD/JS
21:50:31 JS: what can be retrieved is more important than how for some
21:50:53 we should be looking to ensure that our concerns (user requirements) is fully met
21:51:33 EC: I sympathize with both perspectives. None of the existing container formats have support for most of these @kind values yet - they don't exist
21:51:47 q+
21:51:54 q?
21:51:55 defining them in W3C is an interesting thought exercise, but if they are never implemented it is simply a thought exercise
21:52:25 MW: is a chicken and eg problem - do we wait for all the media formats to define the same values with different meanings/names?
21:53:04 Seems a more productive way forward is to define a small number of values so that others can reference
21:53:14 +q
21:53:31 MW: if we put the stake in the ground, we show leadership
21:53:57 JS: sounds like there is more discussion on this issue
21:53:59 ack JF
21:54:14 ack s
21:54:21 SP: let's continuing discussing - this is something basically new
21:54:31 happy to continue the dialog
21:54:50 Bug 12545 - MEDIA CONTROLLER requires loop attribute for grouped multitrack
21:55:11 SP: both Philip and ian are asking for the use-case, and Eric and Silvia are attempting to explain
21:55:39 both ian and Philip believe there is another way forward, but silvia believes is a dangerous way forward
21:56:05 but is not a deal-breaker. would like things to be consistent, but not a do or die issue
21:56:24 Bug 12546 - MEDIA CONTROLLER requires autoplay attribute for grouped multitrack
21:56:35 SP: ian is also asking for a use-case
21:56:53 discussion is happening, but this is not quite clear yet
21:57:03 perhpas the first implementation will help resolve this as well
21:57:18 doesn't believe this is a blocker, nor a fundemental a11y issue
21:57:30 EC: disagree that it is not a a11y issue
21:58:00 we *do* need to discuss this more, but email discussion to date is that Eric was unclear on one aspect of the media controller API
21:58:24 believed that if 1 played, all played, so this might change things in the discussion
21:58:34 JB: also believes that this is important for a11y
21:59:02 SP: maybe we need to put the a11y keyword to this bugs
21:59:16 Bug 12547 - MEDIA CONTROLLER requires readyState for grouped multitrack
21:59:36 SP: is a disucssion tath Eric should summeraize
22:00:04 EC: if we don't have it then a script has no way of determining a ready state
22:00:30 eg; if you have a js controller that is attached after the group is created, then there is no way of knowing what the state is
22:00:52 JS: sounds like it needs additional work
22:01:11 Bug 12548 - MEDIA CONTROLLER requires onended event
22:01:23 SP: believe this has been added
22:01:37 JS: so our change for 12548 has been accepted?
22:02:24 JF: status still reads new
22:02:34 JS: we should verify
22:03:06 HTML5 spec has:
22:03:09 A http://dev.w3.org/html5/spec/video.html#mediacontroller has a most recently reported readiness state, which is a number from 0 to 4 derived from the numbers used for the http://dev.w3.org/html5/spec/video.html#media-element readyStateattribute, and a most recently reported playback state, which is either playing, waiting, or ended.
22:04:05 http://lists.w3.org/Archives/Public/public-html-a11y/2011Apr/0307.html
22:05:06 EEC: I think there may be an issue with the script thta pushes the SVN text from one location to the other
22:05:19 JS: considering the other 4, where do we start?
22:05:32 suspect mark would like to go back to the @kind discussion
22:05:44 http://dev.w3.org/html5/spec/video.html#dom-tracklist-getkind
22:05:47 EC: also have a proposal on how to handle that issue
22:06:20 EC: it is useful for us to come up with a list of the @kind values, but we need to go further and ensure that those @kinds are added to the container formats
22:06:36 silvia can do this for OGG, David Singer can likely do for MP4
22:06:42 this is likely the right way forward
22:06:50 MW: this would be great
22:07:04 if we write down a list then 3gpp and mpeg will reference that list as well
22:07:37 SP: Ogg already has a list
22:08:03 ian based upon what OGG already had defined, but understand that MPEG has some definitions from DSAH
22:08:18 s/DSAH/DASH
22:08:28 http://wiki.xiph.org/SkeletonHeaders#Role <- ogg's list
22:08:33 but 3gpp is waiting on W3C
22:08:45 SP: full list from OGG
22:09:03 but may not have everything that 3gpp are expecting
22:09:17 EC: seems that these groups are all waiting to hear what we propose
22:10:03 EC: we should add a section to the reference documents
22:10:11 MW: is this a normative document?
22:10:20 JB: not sure
22:10:40 seems this should be a normative reference from elsewhere, not internal to HTML5
22:10:59 JB: a PFWG might be the place to do this - would need a minor charter mod for that
22:11:17 SP: we should agree/assure that this can be modified in the future
22:11:20 +Q
22:11:26 since it is just a string
22:11:43 might see new values emerge over time
22:11:51 wouldn't want to see a fintie list
22:12:24 MW: for clarification - in external discussions 3gpp and MPEG DASH are not interested in defining these values
22:12:40 they are waiting for W3C to define the URN for the track kinds
22:13:00 just like has already been done for text @kinds - why is this any different?
22:13:24 SP: from OGG's container format, they are all the same
22:13:28 q?
22:13:44 EC: seems that having the definition in the HTML spec is a bit backwards - these are not specific to html
22:13:56 MW: not specific to media container formats as well
22:14:04 EC: my point exactly
22:14:26 SH: We can create a wiki like the microformats did
22:14:31 zakim, mute me
22:14:31 silvia should now be muted
22:14:55 JB: another approach would be to define a collection of these and post them at W3C.
22:15:01 q+
22:15:02 ack j
22:15:57 -Eric_Carlson
22:16:18 q+
22:16:24 +Eric_Carlson
22:16:26 ack s
22:16:29 SH: wanted to make the point that whether wikis are an issue or not, the chairs have already made the decision that the spec can reference wikis
22:16:45 so if it is a problem for our list, then it would be a problem for other lists as well
22:17:00 MW: this is not specific to html, even less for container formats
22:17:14 however anyone writing html will want to know what these values are
22:17:17 q?
22:17:21 ack m
22:17:21 so there is an html need to define this
22:17:55 EC: don't disagree that the spec needs to define the labels, but the list and definitions need to come from somewher else
22:18:22 JS: do we agree that a canonical list needs to be defined, and that W3c is the place that this should happen?
22:18:33 (appears there is no disagreement)
22:18:42 zakim, unmute me
22:18:42 silvia should no longer be muted
22:18:52 Is there also consensus that the html5 spec is not the right place for this document?
22:19:11 SP: not necessary a good approach
22:19:11 q?
22:19:18 this should be in one place
22:19:26 +q
22:19:45 SP: what html does is places a normative list in the spec
22:19:57 but other groups would need to replicate this list
22:20:10 but they shouldn't be restricted by an html list
22:20:23 q?
22:20:24 zakim, mute me
22:20:25 silvia should now be muted
22:20:28 ack j
22:20:49 judy has joined #html-a11y
22:20:54 q+
22:21:02 q?
22:21:13 ack j
22:21:16 q+
22:21:41 JF: disagrees with Silvia's proposal - should be in one location so that all ca nreferrence one document
22:21:53 JB: this might take too long for HTML5's timeline
22:22:03 q?
22:22:07 zakim, unmute me
22:22:07 silvia should no longer be muted
22:22:12 ack s
22:22:31 q+
22:22:41 q+
22:23:04 SP: doesn't fundmentally disagree with JF, but container formats may need more than HTML5 requires
22:23:58 JS:
22:23:59 zakim, mute me
22:23:59 silvia should now be muted
22:24:22 on the list of what a container can do, we can suggest that this list is a set of know values that container should support
22:24:30 but we should not lock it down
22:25:01 however if there are new requirments, there are W3c processes for adding to canonical requirements
22:25:47 q?
22:25:48 JS: comment 2 - why not let w3C figure out where and how to register these values. Our groups purpose could be to come up with an initial list, and not worry exactly where to house that list
22:25:51 ack j
22:25:53 ack m
22:26:05 MW: nobody is suggesting that container formats be constrained by this
22:26:27 MPEG has defined a flexible method for defining an URN for specific set of values
22:26:38 there appears to be a small set of use-case now
22:26:50 that could be used in multiple use-case
22:27:07 zakim, unmute me
22:27:07 silvia should no longer be muted
22:27:25