Re: [minutes] 2010-02-17 telcon, Media accessibility group

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:50:36 UTC