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

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

From: Michael(tm) Smith <mike@w3.org>
Date: Thu, 18 Feb 2010 19:22:39 +0900
To: public-html@w3.org
Message-ID: <20100218102237.GB33551@sideshowbarker>
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 10:22:44 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:14 UTC