media a11y telecon minutes

any errors are mine...Jim Allan

28 Apr 2010

See also: IRC log

    John_Foliot, Eric, Judy, +31.65.159.aaaa, Jim_Allan, Geoff_Freed,
Janina_Sajka, +61.2.801.2.aabb, +61.3.986.4.aacc, +61.2.801.2.aadd


    * Topics
         1. multitrack api
         2. media/text association
    * Summary of Action Items

<JF> shall we start?

<JF> anyone volunteer to scribe?

<scribe> scribe: allanj

jf: issues from JB, needs statement

<silvia> is there a phone number to call?

<JF> 1 617 761 6200 (USA)

jb: We need a requirements document for work in the media area.
... sees there are some requirements. are they vetted? are they
... concern about technical and accessibility representation. wants WAI to
have participation. requirements would help getting the right folks

jf: sylvia has done work for Mozilla, and put lots of information on the
... are we missing something? who else should we contact?



jb: impression from months back, was concerned about vetting and input, if
they have been addressed, I'm Ok

sylvia: documents posted have had lots of input.
... requirements captions, transcript, audio description


sylvia: basic requirements are not a problem. all agree. Issues are how to
realize the requirements in practice on the web.
... doesn't feel need for additional requirements. Please review, comment as
... standstill, at the moment is the technical implementation
... one issue is synchronization of multiple video types (multiple angles,

jb: 0there is a role for the requirements document., will review the pieces.
wonders why not a whole.

js: may need a resolution that are requirements are at URI.

<silvia> this is our media accessibility requirements document:

js: perhaps wiki page. that way we have a starting point, and the problems
we solved

jf: jb talked about other groups to review. do we have to chase after other
groups, or say here is the info - review at will.

jb: looks like lots of groups have been approached. would like to know who,
so I can use my contacts to forward the work of the group. need a single
requirements. will commit to review these documents.

jf: in minutes of this meeting are lots of URI. could combine all
requirements into one
... there are several technologies referencing similar things
... smile, etc. lots of overlap, hard to look 5 years in future.
... getting a sense of scale and timeline for a deliverable has not yet been
... /s/smile/smil

dick: have been pointing out challenges. getting responses of 'too far down
path a'
... long term vs short term. want to know constraints
... guidance on input needed,

sylvia: 'too far down the path'... only the implemented video element in
... that is fixed. trying to make that accessible (captions, audio
... smil is out of scope.
... still a need to develop a larger picture, need to solve the short term

jf: having a requirements document may help focus efforts.
... smil and daisy have legitimate concerns.
... video is being used now. how do we solve that problem.

js: daisy should be on call

kenny: yes daisy is here.

jb: requirements would be good

jf: would help set timelines also

?? if something violate a longterm need but meets a shortterm need, how do
we resolve.
multitrack api

dickbolterman: activation of embedded content tracks, this api meets this

resolution: the media sub team recommends the multitrack API at @@
media/text association

db: also related to item 3
... main concern - current vido and audo objects have multiple functions.
... content, selection, and time containers
... all are being integrated into one object
... tried to integrate SMIL processing model with 'switch'
... proble: introduction of time contaiiner. secheulde independent objects.
... we are not just choosing from among available tracks
... we are gathering different tracks from different places
... also links in captions
... pairing audio w/ video, should be same as pairing captions w/ video, or
audio description w/ video

jf: technology is browse window. they are reaching the point that they can't
do everything that a standalone player can
... do we focus on browsers as they are now, or what they can do in the

db: absolutely browser window. reasonable that captions can be place on,
above, below, etc the video. we are adopting old TV model. TV now is moving
away from old model
... extended functionality can work in the current object.

sylvia: disagree with this model. mentioned video with time containers. in
html5 video is only audio and video with one timeline. slideshows are a
different thing.
... source selection with only 1 time line.
... switch element is out of html5
... tracks for captions and audio descriptions are not independent time
... they are dependent on the one AV timeline. this is a big difference.
... need to solve accessibility first. other proposals are after this.

db: is one selection with one timeline can agree.
... if fetching a track comes in late then what happens.
... need to match time if things are coming from separate files.
... if you don't want this, then must define captions as embeded within
... could have many track, karoke, etc. they are real problems. and here

sylvia: map all timelines to the base video timeline. multiple files will
not break this simple algorithm
... soucing from different servers. if things don't arrive at the same time,
too bad. can't hold the video.

db: if you need the captions to get the information, then throwing them out
is not a good plan.

sylvia: video won't start until captions are there.

db: if you have small device with long video. need to support the simple
soulution first, but address the complex one in the future.

eric: media engine composed media files on demand.
... need to define specific rules about timing. all media must be there
before it starts.
... not sure how this is different from what we have now.

db: is inside the video element the proper place to do the time composition.

eric: must agree with sylvia. already have this situation. media file is
time container. and can reference external media

db: if you have embedding media, the rendering engine...

eric: not the case. the mdia samples may come from external file.
... there is one master timeline in the container. controled by the browser

db: hyperlinks in a text file, to link to other objects or navigate within a
media. so the subbordinate textfile is controlling the parent object

sylvia: it doesn't matter. just points to an offset in the video

db: if in same file and point 20 sec into the future......

sh: that is not how timetext works.

db: author has to know what video encoding is being use.

sh: whichever is playing controls the clock. can sample forward or backward

Discussion of intricacies of timedtext and smil timing model

sh: what does a hyperlink actually do in a caption file. none of it has been

jf: do we need to bring up hyperlinks in the requirements documents
... srt, dxfp, and styling of textfiles.
... accessibility, changing style is need.

<gfreed> just for the record, i think we do need to look at hyperlinking
when the time is appropriate.

jf: can't do this with srt. then do we look a timedtext or dxfp
... but browsers say it is too complex.

db: need to keep options limited.
... text association models have different semantics

?? correction, srt will use the browser default style sheet, modifiable by
the user.

jf: what about the author having some control?

eric: basic srt does not have this (styling by author)

jf: styling could allow placement of captions, above, below, bubbles, etc.

eric: need a solution to allow the author to style. otherwise, not going to
... problem with dxfp is how stylse is expressed.

sh: xsfo has css properties through xsl.

gf: one model about styling on captions is repurposing captions from other
... may have colors fonts, etc so they can transfer to the web.

sylvia: dxfp problems, no support for ruby and i18n.

sh: not ruby markup but can display ruby text.

jf: srt doesn't support ruby either

sylvia: srt is simplistic solution. determining the requirements on whatwg
... ... what format exists to support stylihg requirement. currently, none.

jf: yikes!
... requiring ruby is a good thing.

sylvia: ian is mashingup and format to meet requirements. need feedback and
... it will likely be the format speced

jf: this covers item 4 also
... time is ticking. htmwg is looking to solve or they will be closed.
... need to get a requirements document, need to focus on that, and try to
set timeline
... and get started on the work
... html5 video is already on the web.

jb: number if a11y issues. media is an important issue. TF chairs wre
working with html5 to move things along.
... coordination calls ongoing.
... this is a complicated area. discussion today reinforces the need for
... it comes up in every topic. reaching consensus on requirements is needed
... need one document
... htmlwg chairs understand that media needs to be done right, and will
take some time.

js: underscore doing it 'right', timeline must be realistic.

regular telecons. have scheduled 10.

scribe: post one set of requirements. set short term goals, then see where
we are
... need to get to a consensus

jf: need a single concensed requirements document. short term and long term.
will create soon.

<scribe> ACTION: jf to create requirements a11y media accessibility document
[recorded in]

<trackbot> Created ACTION-27 - Create requirements a11y media accessibility
document [on John Foliot - due 2010-05-05].

UNKNOWN_SPEAKER: will ahve conference call for next few weeks, then reassess
frequency of calls

rssagent, make minutes
Summary of Action Items
[NEW] ACTION: jf to create requirements a11y media accessibility document
[recorded in]

Received on Wednesday, 28 April 2010 23:37:49 UTC