HTML5 accessibility media subgroup discussion

<silvia> 1. Multitrack JavaScript API

<silvia> Discussion & Agreement

<silvia> Specification:

<silvia> http://www.w3.org/WAI/PF/HTML/wiki/Media_MultitrackAPI

<scribe> scribe: MikeSmith

Multitrack JavaScript API

http://www.w3.org/WAI/PF/HTML/wiki/Media_MultitrackAPI

silvia: can have multiple tracks: caption tracks, subtitle tracks, etc.
... so far there is no API for the browser to know [how to differentiate among the various tracks]
... we discussed a declarative way for exposing the tracks to browsers
... but after discussion, came to conclusion that we need an API

eric: nothing in this API is specific to a11y
... instead it is a general-purpose API [for accessing multiple tracks]
... so it brings additional value in general, not just for accessibility

JF: we have an issue in that, e.g., section 508, still have a requirement that no critical accessibility require Javascript to be enabled

eric: the accessibility features are in no way dependent on this API

JF: OK, I want to make sure that it's not misconstrued

eric: one of my goals is to make sure that any feature we add inside the UA -- anything the UA can put into its UI (controller) -- should also be exposable to script -- so that developers can create alternative UIs

silvia: agreed about the need for this to be exposable through script

<silvia> interface MediaTrack {

<silvia> readonly attribute DOMString name;

<silvia> readonly attribute DOMString role;

<silvia> readonly attribute DOMString type;

<silvia> readonly attribute DOMString lang;

<silvia> attribute boolean enabled;

<silvia> ...

<silvia> };

silvia: role = caption, subtitle, etc.
... type=media type
... lang = an IANA language tag
... so we want to get opinions about the propose API

JF: role values are predefined?

silvia: we are, btw, doing some similar work in Ogg along these lines

<dsinger> how does this intersect with Richard's idea of basing the media queries on access-for-all ?

eric: I think it does need to be a predefined [enumerated] list of roles

<dsinger> no, the bus is too noisy

janina: These are synchronized tracks?

silvia: yes

janina: what about structural navigation? is it just FF and rewind?

JF: you thinking about something along the Daisy model?

silvia: chapter-marking mechanism.. that is a meta-structural mechanism [that would reside on top of this]

eric: QT movies and MPEG4 files do have a chapter-track mechanism to find named sections of a file

silvia: but the mechanism of moving among [those is outside of the work we are doing here]
... I think we need to do some more experimentation with this and then eventually propose it to the HTML WG as an addition to the spec

eric: essentially what we want to do is provide script-level access to the same set of information that the UA already has

<silvia> 2. Declarative syntax for associating external text resources

<silvia> Discussion & Agreement

<silvia> Specification:

<silvia> http://www.w3.org/WAI/PF/HTML/wiki/Media_TextAssociations

Declarative syntax for associating external text resources

http://www.w3.org/WAI/PF/HTML/wiki/Media_TextAssociations

[Geoff summarizes the state of current discussion]

silvia: we have to schemes, one that Philip is currently defending, and one that is based on the wiki link above

<silvia> <video src="video.ogg">

<silvia> <track role="subtitle">

<silvia> <source src="video_sub_en.srt" type="text/srt; charset='Windows-1252'" lang="en">

<silvia> <source src="video_sub_de.srt" type="text/srt; charset='ISO-8859-1'" lang="de">

<silvia> <source src="video_sub_ja.srt" type="text/srt; charset='EUC-JP'" lang="ja">

<silvia> </track>

<silvia> </video>

plh: so how does the track element get exposed to the multitrack API?

eric: we are in the midst of having a discussion about that now

<silvia> <video src="video.ogv">

<silvia>         <track src="subs.de.srt" srclang="de" role="SUB">

<silvia>         <track src="subs.sv.srt" srclang="sv" role="SUB">

<silvia>         <track src="subs.jp.srt" srclang="jp" role="SUB">

<silvia> </video>

silvia: the above is an alternative that has been proposed
... [the semantics of that would need to be determined and specified]

eric: clearly the UA would need to have a heuristic for making choices [among the roles provided]

silvia: If I have my browser prefs set to always display subtitles in German if they are available, then the UA would play the first one above

gfreed: what Silvia has described is almost exactly what Real Player did -- that the user can state a preference of, being able to state that they want to see captions and in what lang they want to see those captions

<dsinger> is there an access-for-all spec that uses media queries already? I know Richard is working on one

janina: the Media Queries through CSS in implemented [in Canada] through the access-for-all [project? application?]
... the point is the we need a cascading set of choices

eric: Dave Singer and I have started to have a discussion with RichS about this

janina: I think it's important that we don't want to end up having multiple [redundant] ways of doing the same thing

<silvia> <video src="video.ogv">

<silvia>    <track src="cc.en.srt" srclang="en" role="CC" active>

<silvia>    <track src="tad.en.srt" srclang="en" role="TAD">

<silvia>    <trackgroup role="SUB">

<silvia>       <track src="subs.de.srt" srclang="de">

<silvia>        <track src="subs.sv.srt" srclang="sv">

<silvia>        <track src="subs.jp.srt" srclang="jp">

<silvia>    </trackgroup>

<silvia> </video>

silvia: above is yet another proposal under discussion
... I think within the next week or so we will get agreement amongst ourselves on the final proposal

gfreed: would this most recent example that you pasted into IRC allow multiple displays of the same role?
... that is, would I be able to display to subtitle track simultaneously?

silvia: so the way to do that now would be to take them out of the trackgroup and just make them tracks
... [because the trackgroup semantics are that it contains alternatives]

gfreed: my concern is just that we make sure we end up with a way that does allow display of multiple tracks with the same role at the same time

silvia: I am confident that we can come up with agreement

eric: I would go so far as to say that it's a requirement [nothing we spec should prevent multiple tracks of the same role from being displayed at the same time]

gfreed: I sent an example to the list of how iTunes deals with a case like this (the specific menu it provides for controlling this)

eric: so what we are working on is making that all configurable through script, so that authors/developers can provide their own UIs

<dsinger> w3c timed text?

<silvia> 3. External caption format support

<silvia> Discussion & Agreement

<silvia> Proposed:

<silvia> * srt

<silvia> * DFXP

<dsinger> what would be parsing the format? scripts or the UA?

External caption format support

gfreed: I would prefer that we lean toward DFXP, because it's been vetted and because it's a W3C spec

<dsinger> is there a scripted implementation of DFXP?

gfreed: on the other hand, srt has not been fully vetted and is not a spec [in the same sense]
... it is true that DFXP is too big [complex] for some

<dsinger> we could recommend both, and give reasons for them?

<frankolivier> yes, there is (at least one) scripted implementation of dxfp (I have it in my bookmarks somewhere)

<plh> frank, yes there is :)

silvia: I think ultimately what we will end up with is a subset/profile of DFXP

plh: I did implement DFXP in JS
... which by the way is just called "timed text" too
... I would suggest also that we subset/profile it

<dsinger> it would have to be a profile, agreed, because it needs to be 'linear', at least

plh: DFXP is currently "stuck" due to a particular feature

<plh> http://lists.w3.org/Archives/Public/public-tt/2010Feb/0000.html

plh: and the group and chair seemed poised to remove that particular feature

gfreed: for the greater percentage of captioning and subtitling use cases, I would agree that DFXP has more features than needed, so it would make sense to subset/profile it

janina: when we are at Stanford last year, one outcome we discussed was documenting the list of requirements

silvia: there is in fact a page at the Wiki for that
... I think we don't need to impose a deadline on this, but let the discussion proceed as it has been

gfreed: It might be useful to schedule a call for two weeks or three weeks [and try to get PhilipJ on]... particularly if it seems like we are stuck on e-mail

silvia: yeah, if it seems like we are stuck on e-mail, then would be good to have another call
... I am not in a hurry to have another call, would suggest that we consider having one again if/when it seems like we need to