W3C home > Mailing lists > Public > public-html-a11y@w3.org > August 2010

HTML-A11Y TF Media Group Minutes for 11 August

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>
Message-ID: <20100811235239.GD2122@sonata.rednote.net>
Minutes from today's Media teleconference is available in text below.
It's also available in HTML at:


                                                           - DRAFT -

                                                       HTML-A11Y telecon

11 Aug 2010

   See also: IRC log


          Janina, Sean, Plh, John_Foliot, Eric, Silvia, Kenny_Johar, Judy




     * 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

   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

   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

   <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

   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

   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

   [End of minutes]


Janina Sajka,	Phone:	+1.443.300.2200

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:42 UTC