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

Re: [media] Moving forward with captions / subtitles

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Sun, 14 Feb 2010 11:48:02 +1100
Message-ID: <2c0e02831002131648g691202d1mf67240a1b98c8609@mail.gmail.com>
To: Philip Jägenstedt <philipj@opera.com>
Cc: HTML Accessibility Task Force <public-html-a11y@w3.org>
On Sun, Feb 14, 2010 at 2:01 AM, Philip Jägenstedt <philipj@opera.com> wrote:
> On Sat, 13 Feb 2010 21:04:36 +0800, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>> In general I like the idea of calling it <track>. However, I have a
>> slight issue with it because they are only virtual tracks - normally
>> only the "tracks" that are multiplexed together inside a encapsulation
>> format are called tracks. This would make the content inside a source
>> element called tracks, but also the parallel external files. I predict
>> confusion.
> I think it would be good to treat them as the same as far as possible,
> including in the DOM API and MediaTracks collection. That way the same user
> JavaScript could operate on the resource without caring if the tracks are
> resource-internal or added using <track>.

This integrates it with the Multitrack API proposal. I like it!

I have tentatively changed the name of "textassoc" to "track" in the wiki.

>>> role="" is fine, but I'd like to see more ideas on what UAs should to
>>> with
>>> it.
>> The thought is to use it not just for captions, subtitles, and textual
>> audio descriptions, but also for karaoke, lyrics, chapters, timed
>> comments, timed metadata, and other such time-aligned text and
>> annotations. There are examples with lyrics
>> (http://svg-wow.org/audio/animated-lyrics.html, and
>> http://annodex.net/~silvia/itext/chocolate_rain.html), and chapters
>> (http://annodex.net/~silvia/itext/elephant_no_skin_v2.html). I'm sure
>> we will come up with more similar examples.
> Yes, but is it expected that the UA should do something with the attribute,
> like make context menus based on it? Or should it be part of the track
> selection algorithm? (Where "track selection algorithm" does not exist yet,
> but is what will select which tracks are enabled by default based on...
> language and such?)

I think it should be both. It should help create a context menu - and
that menu can even include the tracks from the selected media
resource. That would be something like

  <source src="video.ogv" type="video/ogg">
  <source src="video.mp4" type="video/mp4">
  <track role="subtitle">
    <source src="video_sub_en.srt" type="text/srt;
charset='Windows-1252'" lang="en">
    <source src="video_sub_de.srt" type="text/srt;
charset='ISO-8859-1'" lang="de">
    <source src="video_sub_ja.srt" type="text/srt; charset='EUC-JP'" lang="ja">

and the context menu create includes any subtitle tracks available
from within the resource.

Received on Sunday, 14 February 2010 00:48:55 UTC

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