- From: John Foliot <jfoliot@stanford.edu>
- Date: Wed, 27 Apr 2011 16:20:17 -0700 (PDT)
- To: "'HTMLWG WG'" <public-html@w3.org>, <public-html-a11y@w3.org>
All, Please find the HTML version of today's Media sub-team teleconference at: http://www.w3.org/2011/04/27-html-a11y-minutes.html Or as plain text below: ***************** HTML Accessibility Task Force Teleconference 27 Apr 2011 See also: IRC log Attendees Present John_Foliot, Janina, silvia, mark, Judy, Frank, +54558aaaa, Sean, Eric_Carlson Regrets Chair SV_MEETING_CHAIR Scribe JF Contents Topics Identify Scribe Summary of Action Items <trackbot> Date: 27 April 2011 <silvia> :) Identify Scribe <scribe> scribe: JF <Sean> its telling me its not valid JS: thinks we should have a post-mortem on issue 152, what happened and where are we now? ... believe we are still on track... SP: the chairs decided what we were trying to do was not possible based on WG rules everyone else pulled back their change proposals so that ian's work moved forward uncontested and now we even have some of the bugs resolved JS: does anyone have anything to add to that? JB: were we not at some point relying on ian's proposal? JS: maybe that would be an introduction to where we are now? 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 based on feedback, he was updating running spec at WHAT WG, but not his original CP thus his CP was out of date 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 JB: thanks for the overview - added clarrity we need to be careful on watching where text is evolving with a goal to avoid this confusion again MW: was watching process, and wanted to be sure his concerns were included into one of the CP's and what ended up was that was not what happened conclusion - always have a valid Change proposal in hand JB: this was unusual for w3C process this was atypical JS: many found this quite confusing EC: to be fair, our problem was that we did not have a valid change proposal JB: that may be part of the problem/issue, but that was not 100% clear - there was a missed understanding the concensus process was lost MW: the problem was there was no CP last Friday SP: not unhappy with the process, we got what we needed, and the bugs are being pursued. In essence we got what we needed EC: Agree with Silvia - in the end we resolved a contentious issue by amicable resolution 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? http://www.w3.org/Bugs/Public/show_bug.cgi?id=12544 http://www.w3.org/Bugs/Public/show_bug.cgi?id=12545 http://www.w3.org/Bugs/Public/show_bug.cgi?id=12546 http://www.w3.org/Bugs/Public/show_bug.cgi?id=12547 http://www.w3.org/Bugs/Public/show_bug.cgi?id=12548 JB, can we get a status check Bug 12544 - MEDIA CONTROLLER requires track kind for in-band tracks SP: this has been applied we now have a get @kind function in the spec MW: there remains an outstanding question about what @kind values can be gotten back how do we decide - not in concurrance with ian's perspective, woulod prefer that W3C define the list should be independant of the container formats so there should be a single place where these are define JS: the fact that they are marked resolved may not be sufficient for this group ... what can be retrieved is more important than how for some we should be looking to ensure that our concerns (user requirements) is fully met 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 defining them in W3C is an interesting thought exercise, but if they are never implemented it is simply a thought exercise MW: is a chicken and eg problem - do we wait for all the media formats to define the same values with different meanings/names? Seems a more productive way forward is to define a small number of values so that others can reference +q MW: if we put the stake in the ground, we show leadership JS: sounds like there is more discussion on this issue SP: let's continuing discussing - this is something basically new happy to continue the dialog Bug 12545 - MEDIA CONTROLLER requires loop attribute for grouped multitrack SP: both Philip and ian are asking for the use-case, and Eric and Silvia are attempting to explain both ian and Philip believe there is another way forward, but silvia believes is a dangerous way forward but is not a deal-breaker. would like things to be consistent, but not a do or die issue Bug 12546 - MEDIA CONTROLLER requires autoplay attribute for grouped multitrack SP: ian is also asking for a use-case discussion is happening, but this is not quite clear yet perhpas the first implementation will help resolve this as well doesn't believe this is a blocker, nor a fundemental a11y issue EC: disagree that it is not a a11y issue 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 believed that if 1 played, all played, so this might change things in the discussion JB: also believes that this is important for a11y SP: maybe we need to put the a11y keyword to this bugs Bug 12547 - MEDIA CONTROLLER requires readyState for grouped multitrack SP: is a disucssion tath Eric should summeraize EC: if we don't have it then a script has no way of determining a ready state 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 JS: sounds like it needs additional work Bug 12548 - MEDIA CONTROLLER requires onended event SP: believe this has been added JS: so our change for 12548 has been accepted? JF: status still reads new JS: we should verify <silvia> HTML5 spec has: <silvia> 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. http://lists.w3.org/Archives/Public/public-html-a11y/2011Apr/0307.html EEC: I think there may be an issue with the script thta pushes the SVN text from one location to the other JS: considering the other 4, where do we start? suspect mark would like to go back to the @kind discussion <silvia> http://dev.w3.org/html5/spec/video.html#dom-tracklist-getkind EC: also have a proposal on how to handle that issue ... 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 silvia can do this for OGG, David Singer can likely do for MP4 this is likely the right way forward MW: this would be great if we write down a list then 3gpp and mpeg will reference that list as well SP: Ogg already has a list ian based upon what OGG already had defined, but understand that MPEG has some definitions from DASH <silvia> http://wiki.xiph.org/SkeletonHeaders#Role <- ogg's list but 3gpp is waiting on W3C SP: full list from OGG but may not have everything that 3gpp are expecting EC: seems that these groups are all waiting to hear what we propose ... we should add a section to the reference documents MW: is this a normative document? JB: not sure seems this should be a normative reference from elsewhere, not internal to HTML5 JB: a PFWG might be the place to do this - would need a minor charter mod for that SP: we should agree/assure that this can be modified in the future +Q since it is just a string might see new values emerge over time wouldn't want to see a fintie list MW: for clarification - in external discussions 3gpp and MPEG DASH are not interested in defining these values they are waiting for W3C to define the URN for the track kinds just like has already been done for text @kinds - why is this any different? SP: from OGG's container format, they are all the same EC: seems that having the definition in the HTML spec is a bit backwards - these are not specific to html MW: not specific to media container formats as well EC: my point exactly SH: We can create a wiki like the microformats did JB: another approach would be to define a collection of these and post them at W3C. 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 so if it is a problem for our list, then it would be a problem for other lists as well MW: this is not specific to html, even less for container formats however anyone writing html will want to know what these values are so there is an html need to define this EC: don't disagree that the spec needs to define the labels, but the list and definitions need to come from somewher else JS: do we agree that a canonical list needs to be defined, and that W3c is the place that this should happen? (appears there is no disagreement) Is there also consensus that the html5 spec is not the right place for this document? SP: not necessary a good approach this should be in one place +q SP: what html does is places a normative list in the spec but other groups would need to replicate this list but they shouldn't be restricted by an html list JF: disagrees with Silvia's proposal - should be in one location so that all ca nreferrence one document JB: this might take too long for HTML5's timeline SP: doesn't fundmentally disagree with JF, but container formats may need more than HTML5 requires JS: 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 but we should not lock it down however if there are new requirments, there are W3c processes for adding to canonical requirements 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 MW: nobody is suggesting that container formats be constrained by this MPEG has defined a flexible method for defining an URN for specific set of values there appears to be a small set of use-case now that could be used in multiple use-case JS: so, are we in agreement that a) W3C should define the canonical list, b) that W3C figure out where this would happen and live? <mark> http://www.w3.org/WAI/PF/HTML/wiki/Track_Kinds JB: how much of this specifically is related to a11y and not a larger container format issue? If it is primarily for a11y use then it may change the quesstion JS: there seems to be a fair bit of a11y and i18n issues EC: there *Is* a need for a list of a11y terms and it should be in a document that comes from thta group. but in HTML5 the labels can apply to those terms. in the container format, it is those terms that get mapped to the container formats so the canonical definition should be what a11y NEEDS JB: so this makes it appear that this is PF territory SP: looking at mark's list, there are 2 or 3 that would make sense to add supplementary, commentary, and clear audio SP; as eric suggests, we should focus on the a11y reqs here. David singer also had some suggestions MW: to add one to that list, there are situations where the only place to get captions is when they are burned into the video itself so it would be nice to be able to label the video with captions/subtitles there SP: would that actually be supplied as a seperate track in the resource, or is it simply a description of what is already burned into the video file is @kind then the correct way to define/describe this/ MW: what we have today is some instances with caption burned into the video JS: this is going to exist for smoe time due to legacy content MW: if we can extract that in any way, then we would extract the text and store it seperately or offer 2 versions of video, one with burned in, one without (Mark is this correct?) SP: agree, to offer this to the end user as an undefined alternative MW: there is a usecase for machine understandable extraction however for example, always show captions EC: agree 100% - the right thing is that to have an @kind that says there are captions if it is applied to an audio track, then it is an error, but if it is included then it is up to the user-agents to intelligently do something with this so a new label for 'captions' for burned in captions MW: there appears to already be some duplication from different groups. if everyone agrees we can narrow down to one term and common definitions SP: suggestion - make 2 tables: one like you have, and then a second that contains the ones we have agreed to MW: OK, agrees to that ... do we assume that the initial five values have agreement? JB: in the status section, in addition to reflecting what is in the page, might be useful to also show who is involved in the current discussion JS: 2 questions - we are looking here only at binary formats? is this correct? (yes) <mark> I added "This page is a work-in-progress and is being actively studied by the HTML a11y working group" we were trying to be very careful of terms - so it should be audio description, not video description SP: 'description' is in the spec. JS: there is some confusion, and in the user reqs we took pains to delineate the difference between binary descriptions and text descriptions as long as the taxonomy is clear and precise JF: is description for both audio and text be a problem? MW: we need to define needs and then word terms as I undertand in the spec, there is a list of names, but with no definition JS: we do need to do that, to define the terms. this is why we were very careful with the usage of names SP: it is the mime type that does the definition so the generic term of description makes more sense, as it is the @type that defines the type of @kind resource SJ: go around the table for the values to take consensus so on initial five: alternative, description, main, sign, translation - are there any concerns here? JF: are there any disagreements that those 5 values required for a11y JS: there was some discussion earlier about defining "main" versus "primary" JF: propose we continue on this discussion on the mailing list JS: do we want to continue with 2 calls a week? (we will remain with once-weekly calls) JS: are there any other hightlihgs on the reamins bugs that we should be discussin today? ... thanks for the good work - it appears we are actually in a good way despite last weeks confusion next call is next wednesday Summary of Action Items [End of minutes]
Received on Wednesday, 27 April 2011 23:20:50 UTC