- From: Janina Sajka <janina@rednote.net>
- Date: Wed, 11 Aug 2010 19:52:39 -0400
- To: HTML Accessibility Task Force <public-html-a11y@w3.org>
Minutes from today's Media teleconference is available in text below. It's also available in HTML at: http://www.w3.org/2010/08/11-html-a11y-minutes.html W3C - DRAFT - HTML-A11Y telecon 11 Aug 2010 See also: IRC log Attendees Present Janina, Sean, Plh, John_Foliot, Eric, Silvia, Kenny_Johar, Judy Regrets Chair John_Foliot Scribe janina Contents * Topics 1. Actions Review http://www.w3.org/WAI/PF/HTML/track/actions/open 2. moving our User Requirements to W3C Note status? 3. Technical Primitives Development 4. Candidate Solutions Gap Analysis: WebSRT; WMML, Etc. * Summary of Action Items __________________________________________________________________________________________________________________ <scribe> agenda: this action+ Activity Updates -- Proof of Concept; Content Contributions <JF> hello <scribe> scribe: janina Actions Review http://www.w3.org/WAI/PF/HTML/track/actions/open jf: primarily long range on Judy. moving our User Requirements to W3C Note status? jb: Is there value to moving toward note status for our User Requirements? plh: No? jf: is wiki sufficient? will it last? js: my concern as well. plh: gives more visibility, certainly. jf: something we can do, but no need to hurry on it. plh: yes ... Having as a note will not help within html wg, but if there's longer term value, than that's another reason. jf: Perhaps as a wrap up task? js: Agrees Technical Primitives Development jf: has anyone done any work on this? comments? <silvia> http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements sp: We need to work on it more, phps as we look at proposed formats. ... I believe our user reqs are the most useful js: Suggesting a view from engineering is helpful. Maybe it's the user list with comments on amount of work to implement, etc, jf: We need a gaps analysis -- the need to have ... I believe the engineers understand what we need on the easy stuff sp: Is it part of our user reqs that we need sign language implemented from multiple files? ... Not convinced that we need third party sign language ec: One problem with included track is mpeg4 can only contain one video ... also webm sh: there are formats on top of mp4 which do have multiple video, so not a structuring constraint, it's just mpeg didn't have our use cases ec: If you can find authoring software that will support that sh: Can do that ... In case of sl, I've done it with two videos, doesn't need to be actually frame sync'd; because the grammar is so different, the ordering can be looser ... approx is good js: value from user req of sl in second file is community isn't dependent on the original author--third party can provide sl jf: would i do css placement? for a pip type experience? ... phps a large view port for sl if i'm looking at my iPhone, vs on my plasma tv sh: if you just want signer with fixed mat, then fairly easy to transparent on top of primary; if moving mat, that's much harder ec: also not many formats preserve the alpha channel sh: a little hard to compose in real time kj: Want to provide ebook and daisy perspective -- this wg very important to these groups. ... recently had daisy mtg on these topics with thought of making suggestions here ... so daisy4 is using time text, ttml to sync video and captioning ... discussed that thtml+time; ... svg extracted from smil -- took what they needed into their own space jf: i think that's similar to websrt, taken what they needed from css and left the rest kj: benefits could support extended audio, because smil3 allows to build ... smil3 allows pause injection, so supports extended audio that way ... also escapability is important -- click a link in caption -- pauses primary asset while second asset is loaded. ... once it's closed, smil3 supports resume where paused ... don't believe smil can be adopted in its current form, but might it be possible to take what we need and leave the rest? plh: it's possible to profile smil 3 to our needs ... but what about a timing model -- there's none in html ... css, a primitve timing, phps ... microsoft did timing a long time ago, so is phps more ready for this ec: well put jf: so that's where we are in primitives <plh> s/css, a primitve timing, phps/they have primitive timing model in svg (smil animation) and css (css transition/animation), but nothing in their existing html implementation code, at least for firefox, opera, safari, and google/ ec: would do, but am overloaded right now <plh> s/did a timing a long time ago, so is phps more ready for this/did html+time a long time so they have the code already, so they're probably the most advanced here/ ec: i do think it well worth our time to prioritize ... we really need a prioritized list jf: it needs to be a group consensus <scribe> ACTION: john to create a prioritized list due 30 august [recorded in http://www.w3.org/2010/08/11-html-a11y-minutes.html#action01] <trackbot> Created ACTION-52 - Create a prioritized list due 30 august [on John Foliot - due 2010-08-18]. sp: suggest you do this in a table ... including what's already supported Candidate Solutions Gap Analysis: WebSRT; WMML, Etc. sp: suggest we can contribute feedback usefully to websrt, they're soliciting comments ... but it isn't just websrt, there's also a js api sp; and ml in the formats jf: has the framework changed significantly, since our stanford mtg? ... is track group now gone? ... what should we be aware of? sp: trying to understand whether our reqs are met by this spec ... trying to find out how involved this grp wants to be in tek spec and making sure our reqs are met jf: for myself, i'm less worried about the tek, but very concerned that we understand the user reqs js: ditto. not religous on tech selected, though prefer open tech. but care that we meet the identified user needs phl: silvia, will websrt fulfil our reqs? sp: haven't looked at it all -- that's why i want that table started -- so we can answer this question precisely ... believe it's satisfying time sync for text ... don't believe it's doing more than text ... i've made suggestions on the rest, and believe they would satisfy if accepted ec: agree phl: so websrt is a contender ... would time text fulfill? sh: yes. reason they're doing srt, is that people there don't like tt for various reasons i don't fully understand jf: believe the prejudice may be the aversion to xml ... namespaces sh: but websrt is using bits of xml, but would be hard to embed websrt into xml js: might make it hard for groups like daisy and idpf to adopt our technology kj: that's correct. for daisy we don't know how we would sync multiple audio/video without xml phl: phps allow users to choose? sh: but why does the track mechanism need to specify the lang? phl: we could specify a minimum lang support requirement? jf: so i can't support tif in all browsers -- so we need some reliable format specs sh: in a perfect world we'd have a video format as well ... jf: seems content formats will need to produce in at least two formats for the forseeable future ... do we do the same in time sync? may be a bad idea -- won't be done ... so we should specify at least one -- support this one -- feel free to support others sh: we've had that argument with every format that's been introduced, suspect this maynot happen jf: hope you're wrong! <grin> ... can we get to a recommendation on this? kj: what formats can do text, audio, and video sync for us? what are the candidates <JF> I agree with you silvia js: that's the key question kj: other than a subset of smil, i don't see an option jf: don't care myself if it's smil, if the brosers can come up with another way to do it kj: agree js: agree sp: ogg can do it, mpeg4, ... ec: i think a misunderstanding here ... believe kenny is suggesting an external controller sp: wasn't sure if external was a req ... with external, yes, we have some work to do ... and that's exactly where our reqs haven't been considered kj: yes, and in the container space. ... what director sync's it all phl: are we brining in additional reqs beyond a11y? if from epub? ... just want to be careful on that. sh: we do have structure reqs, that are very similar ... the ability to nav to different points in the timeline is an a11y req jf: and we get these reqs because people already have these behaviors and would expect them in html5 kj: if there are to be separate tracks, the sync question becomes critical ... it's not a daisy problem, because we've spec'd that ec: if the model is that the main resource provides the time line, and everything else is child behavior then there's no issue ... it's only when the additional files are out of sync that there's a problem. sh: doesn't quite work, because, eg., the description needs to be sync'd at a certain point -- this descript here at this video point, etc js: and may need to be active when the main resource is paused jf: appreciate that this is complex for tech, but believe it's a user 'must' ... from my perspective, it's easier to present the user reqs and request solutions ... we all agree the primary resource is the master time line; q is how to fire adaptive at particular points in that tl ec: without a prioritization of each of the user reqs, don't see we can call any req a 'must' jf: i think we have an informal understanding of what we need to achieve, at what priority -- well -- ... any solution we come forward with needs to see the rest getting accomplished kj: fundamental question that needs to be answered is do we want to delegate sync to a container, or manage it ourselves? phl: don't understand, how does that simplify or complicate kj: if you say it's all bundled, then it's all up to the author, and that's all there will be jf: that's a bad path ... put it all in the media container is not a good solution kj: so if we need to do it outside the container, then it becomes clear what we need to do going forward phl: but which tech? ... ogg and mpet have just one tl, can't do what we need kj: if the sl is burned in, then everything is simple ... but, i want to be clear that we're saying we want to be able to sync separate tracks with the primary jf: yes, third parties should be able to add js: like the disable dstudent services office at my U jf: the only wah for dss to add sl would be a separate sl video for the primary resource phl: not the only way jf: could take into ... so that's a video -- have video produced in U.S., but I need to create subtitles in Quebec, where it's a legal req ... and they'll produce multi language, that's also a legal req ... so how do we allow these to happen ... so my answer we can't push this on the container sp: we're discussing tech solutions, do we actually have a requirement on external? is it stated js: i thought i wrote it -- third party jf: we need to double check this kj: this single question has a huge bearing on our task jf: believe the larger answer is we don't want to hand this off to the container, we have to provide for it ... so we're at our mtg ending time ... good work getting done ... we need to get that table up, so we can start mapping to it -- it's my action -- and we'll go through a prioritization exercise ... i'll map to wcag ... and we should wbs it rrsagent make minutes rrsagent make minutes Summary of Action Items [NEW] ACTION: john to create a prioritized list due 30 august [recorded in http://www.w3.org/2010/08/11-html-a11y-minutes.html#action01] [End of minutes] __________________________________________________________________________________________________________________ -- Janina Sajka, Phone: +1.443.300.2200 sip:janina@asterisk.rednote.net Chair, Open Accessibility janina@a11y.org Linux Foundation http://a11y.org Chair, Protocols & Formats Web Accessibility Initiative http://www.w3.org/wai/pf World Wide Web Consortium (W3C)
Received on Wednesday, 11 August 2010 23:53:10 UTC