- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Thu, 18 Feb 2010 22:58:45 +1100
- To: "Michael(tm) Smith" <mike@w3.org>
- Cc: public-html@w3.org
Ups, I was under the impression this went to the accessibility task
force mailing list, but just noticed it did not.
I was going to introduce it to public-html only after the a11y task
force has provided feedback. This spilled out a bit too early, but of
course feedback / input is welcome at any stage!
There will be trial implementations next, which will later, once more
experience is gained and the current drafts have been adapted, lead to
spec addition proposals - possibly just by replying to some open media
a11y bugs or through a formal change proposal.
Cheers,
Silvia.
On Thu, Feb 18, 2010 at 10:49 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
> Hi all,
>
> Just as an update - the mentioned two schemes for associating external
> text resources with media has been resolved in the meantime and we
> have converged on a compromise that is the best of both proposals. The
> Wiki page at
> http://www.w3.org/WAI/PF/HTML/wiki/Media_TextAssociations has already
> been updated with this compromise proposal and is being harmonised
> with the JavaScript API proposal at
> http://www.w3.org/WAI/PF/HTML/wiki/Media_MultitrackAPI .
>
> We're basically close to giving them a "Ready to implement" status to
> start putting support for them into Web browsers. So, now is a good
> time to provide input.
>
> Best Regards,
> Silvia.
>
>
> On Thu, Feb 18, 2010 at 9:22 PM, Michael(tm) Smith <mike@w3.org> wrote:
>> We had a one-time telcon on 2010-02-17 to discuss some open
>> proposals for improving accessibility of HTML media content.
>>
>> The minutes are copied in below and also available here:
>>
>> http://www.w3.org/2010/02/17-html-a11y-minutes.html
>>
>> Attendees
>>
>> DaveSinger, John_Foliot, PhilippeLeHegaret, MikeSmith,
>> SilviaPfieffer, EricCarlson, JaninaSajka, FrankOlivier, GeoffFreed
>>
>> * Topics
>> 1. Multitrack JavaScript API
>> 2. Declarative syntax for associating external text
>> resources
>> 3. External caption format support
>> * Summary of Action Items
>> _________________________________________________________
>>
>> <silvia> 1. Multitrack JavaScript API
>>
>> <silvia> Discussion & Agreement
>>
>> <silvia> Specification:
>>
>> <silvia> http://www.w3.org/WAI/PF/HTML/wiki/Media_MultitrackAPI
>>
>> 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
>>
>> 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
>>
>> 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
>>
>> 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
>>
>> 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
>>
>> --
>> Michael(tm) Smith
>> http://people.w3.org/mike
>>
>>
>>
>
Received on Thursday, 18 February 2010 11:59:40 UTC