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

Minutes from the Media Sub Wg telecon on July 14 2010 at 2200 UTC.

From: Kenny Johar <kennyjohar@gmail.com>
Date: Thu, 15 Jul 2010 10:50:04 +1000
Message-ID: <A0D2E22446934ED58FCB50FD7F52FBF7@KennyzMiniPC>
To: "'HTML Accessibility Task Force'" <public-html-a11y@w3.org>
Hi all,

Minutes from this call are now available in html at:

A text version of the minutes follows:



Janina, John_Foliot, Judy, Eric_Carlson, kenny_j






John: we should remain as agnostic as possible about specific technical 

... technical requirements should be defined on needs, and not on the basis 
of what technologies are available.

Janina: negotiation will be required with the html 5 wg when we get to the 
technical solution recommendation phase.

masatomo: I have a few points about the technical details, but not at this 

Judy: lets take the requirements in order.

John: In terms of audio descriptions, the technical implication is quite 
simple i.e. multiple tracks.

Janina: audio descriptions could be contained in the same track as the main 
audio, or separated out into a separate trac.

... what we do with legacy content is an important consideration.

john: There are two ways of referencing audio descriptions inside a media 
wrapper. 1: merged into the main track.

2: a separate track inside the media wrapper.

... For the technology we are recommending here, it has to be a separate 
track inside the media wrapper.

Judy: if we do come up with things on the authoring side, we should be able 
to capture them somewhere.

John: I will make a note for myself that this needs to be discussed with 

janina: The ATAG 2.0 last call went out last week.

John: Moving on to texted audio descriptions.

... Masatomo, I believe the proof of concept you are doing at IBM contains 
texted audio descriptions. any comments?

Masatomo: Our format is similar to SSML.

Janina: styling and semantic structure is important in the format we go 

John: we are saying that the text file that provides audio descriptions 
should be able to be marked up as other formats on the web.

... Whether the markup of this format is understood by browsers is a 
different subject.

... Styling and semantic structure is required in the format we decide to go 
with. We need to come back to deciding what that format is.

... Moving to extended audio descriptions.

janina: One option is that the main audio be paused when the extended audio 
description is played.

John: I think we are saying that 2.3 includes 2.1 and 2.2 in terms of 

... moving to 2.4

... john: it is an audio track. We will revisit this to define the technical 

... on 2.5, eric, comments?

... there needs to be a mechanism that makes sure that all the supporting 
files are in synch in the media asset.

eric: any external file that is played along with the timeline of the main 
resource has to be in synch. I think this is a separate requirement.

Janina: I am happy to split the requirements out.

Eric: the data file cannot define the timeline. there is no timeline 
inherent in a data file. there has to be a resource somewhere that defines 
the timeline

for the presentation.

... Whenever we refer to a file that is external to the media, it becomes a 
part of the presentation.

Janina: for example, lets say there is a 30 minute video. there is an audio 
description available, a sign language translation available, and a caption

available. If the next track in the video is played, all the supporting 
resources must synch up. something needs to affect this.

... On their own there would be no time reference in the files that contain 
the captions, audio descriptions, sign language.

<Judy> Kenny: in Daisy, we call this the "director," which makes sure that 
when you go to the next track in your video, the relevant parts are synched 

as well

Eric: I don't believe the working group needs to do anything about this. I 
think this should be left to the user agent. I think this is out of scope.

... I think all we need to say is that the synchronisation should be 

John: the main media resource file is better called primary asset than 

Janina: so are we saying that we leave the synchronisation to user agents 

eric: Whatever piece of code is responsible for playing the different 
resources in the media wrapper should be responsible for the 

janina: I understand the approach. The synchronisation is being left to each 
individual user agent/operating environment.

<Judy> Kenny: Are we saying that all the files should contain timeline 
information inside them?

<Judy> Eric: [missed, sorry]

<Judy> Kenny: What's to say that the time marker in this file would 
correspond to the time marker in the other file?

<Judy> Janina: So we've identified a problem that needs solving.

<Judy> John: let's capture well.

janina: our text file needs to contain timeline data. We also need to decide 
to what resolution or granularity.

eric: timestamp formats should contain such information e.g. srt.

<Judy> [judy notes that the rationale that Janina provided for potential 
offsets is where there is an extended audio description]

<Judy> Kenny: About audio description tracks -- that might play during a 
pause in the video -- would the timeline of the audio track and the timeline 

the video track perhaps not be the same?

<Judy> John: Everything has a start and an end-point. For descriptive audio, 
it will have a start point, but the end point may be asynchronous to the end

of that segment of video... the amount of time needed to provide the 
description exceeds the length of that video segment

<Judy> Janina: Right -- that's the extended audio case I described.

<Judy> John: There are various ways of handling that.

<Judy> Janina: So we've id'd two things now that we have to come to 
resolution on.

Janina: the second item we need to deal with is the case of extended audio 
tracks where the timeline of the extended track and the primary asset are 

the same.

eric: A text format must contain timestamp information or else it can't be 

John: I agree. timestamp information has to be available inside the text 

<Judy> Kenny: The audio track -- x seconds of the audio track correspond to 
the first five seconds of the video track... but where is that info 

<Judy> ...this is why in Daisy we resorted to "the director"

kenny: something like the daisy smil director would ensure that the timeline 
is synchronised across the raft of supporting resources.

<Judy> Eric: we don't know where we would store that

john: lets continue this conversation on the list.

<Judy> +1 to pursuing this point on the list, but i think this has been a 
good discussion to id the specific problem to be resolved

Janina: do we agree that captions should be text documents?

Eric: It is possible to have a binary file that has the same information.

Judy: I am happy for the removal of the text constraint from captioning.

Kenny: this discussion is about 2.6.

eric: I don't think we should use the words text file. Just using the word 
text is fine.

john: subtitles are just whats spoken on the screen, whereas captions could 
include other information i.e. applause ...

janina: I think there will be more subtitles created than captions created. 
merging them might have a favourable result for captioning.

john: moving on to 2.7.

... we could use something like the aria role captioning.

... In terms of 2.8, the switching mechanism for languages in audio tracks 
and sign language tracks would be similar

Janina: I prefer selecting over the word switching.

john: We can use the word selecting over switching. what I am refering to is 
the choice of a user to select between different language tracks i.e. 

language tracks for captioning, sign language ...

... 2.9 is accepted.

... lets discuss a few of the 3.* items on the list this week.

Judy: we need to turn the requirements over to the html wg by the end of 
next week.

Eric: We talked about people updating the wiki sending notes describing the 
changes to the list. Can we please enforce this?

Janina: clarify turning over.

Judy: I think the connotation is sharing with.
Received on Thursday, 15 July 2010 00:50:50 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:12 UTC