W3C home > Mailing lists > Public > public-html@w3.org > July 2009

Re: Shifting gears for a second (was RE: Codecs for <video> and <audio>)

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Fri, 3 Jul 2009 19:39:24 +1000
Message-ID: <2c0e02830907030239x2ceb0401g5c816a073019f40c@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: public-html@w3.org
On Fri, Jul 3, 2009 at 5:36 PM, Ian Hickson<ian@hixie.ch> wrote:
> On Fri, 3 Jul 2009, Silvia Pfeiffer wrote:
>> After some further discussion it seemed that the currently possible
>> solutions are:
>> * captions inside media files -> the media framework deals with them
>> and displays them if it can
>> * captions in a separate file -> use some javascript solution that you
>> hand-craft to solve this problem
>> Ian seems happy with these solutions for the moment, even if neither
>> exposes a standard interface toward dealing with captions from the Web
>> page level, i.e. they cannot be crawled and indexed by search engines,
>> or exposed to screen readers or other such instruments.
> Captions inside media files can be crawled and indexed by search engines,
> and can be exposed to screen readers.

Video files are currently handled as opaque elements in the <video>
tag - there is no API to expose any captions that may be inside the
file. The only system that is able to get access is the media
framework and it is typically buried deep inside the browser. As long
as there is no standard API to access captions for a media file, they
are not exposed to search engines and screen readers.

> Captions in a separate file are indeed a less optimal solution in that
> they aren't necessarily clearly associated with the video file, they can't
> be viewed if the user disables scripting, they don't get saved with the
> video file so accessibility is lost when repurposing the video file, and
> their accessibility story is much more dependent on technologies like ARIA
> (and therefore there is a higher chance that sites will fail to make them
> suitably accessible). In general, I would recommend using captions inside
> media files, as Maciej suggests.

10 years ago I was mkaing the same arguments that you are. But now,
after having tried to push for time-aligned text inside audio-visual
files for so long, I have come to the conclusion that it is actually
easier to deal with separate files than with captions inside media
files. As external files, they are easier to edit, easier to share,
easier to access, easier to parse, easier to handle on a server (e.g.
in a database) and generally easier to manage. All you get with
putting them inside the media file is that you do not lose them when
you hand them around or edit the file, but this can be solved in a
different way. Having captions inside a file turns them from a text
format into a binary format and that is detrimental for most

In fact, my suggestion is not to look at these as completely different
and incompatible forms for captions, but as different states of the
same resource. Sometimes it is better to get the fully integrated
resource and sometimes it is better to get the text and the video
parts of the resource as separate representations.

Received on Friday, 3 July 2009 09:40:27 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:50 UTC