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

RE: [Minutes] Media Sub Team of the Accessibility Task Force - Feb 2., 2011

From: John Foliot <jfoliot@stanford.edu>
Date: Fri, 4 Feb 2011 17:44:39 -0800 (PST)
To: "'Silvia Pfeiffer'" <silviapfeiffer1@gmail.com>, "'Eric Carlson'" <eric.carlson@apple.com>
Cc: "'Matt May'" <mattmay@adobe.com>, "'HTML Accessibility Task Force'" <public-html-a11y@w3.org>
Message-ID: <005e01cbc4d6$409e9050$c1dbb0f0$@edu>
Silvia Pfeiffer wrote:
> Apologies if i seemed off topic, but Eric explained it well.
> I was just questioning the implicit statement that were made in the
> teleconference, firstly that SMPTE-TT has widespread support and
> secondly that it surely will become the specification of choice by the
> FCC. Since the FCC process has only just started, I was hoping there
> would be a bit more technical needs analysis and judgement of where
> things are going. I could, for example, fully understand if the FCC
> chose both SMPTE-TT and WebVTT as standards for the Internet and the
> Web respectively. I wouldn't understand if the reasoning that the
> browser vendors chose to oppose TTML was ignored and SMPTE-TT chosen
> by default.

Hmmm.... I think that this might be skewed slightly off the mark.

Personally, I don't think the FCC is going to prescribe a specific
technology solution like this, but rather simply insist that capability
exists and the entities affected by FCC regulations are mandated to ensure
that (for example) captioning is made available for X% of all web-based
video (where X may indeed = 100%, and 'web-based' being broadly defined as
over the internet network). While the FCC *might* consider feedback from
browser vendors, theirs will be but one voice of many; others might
include Ultraviolet (a consortium standardized, cloud-based DRM system)
and other business interests in the same space, including SMPTEE. If
SMPTEE says to the FCC, "yes, we agree, and we've looked at this already,
and we can achieve this with SMPTEE-TT. Our membership is prepared to, and
in fact is already doing this, using this technology", then I think that
the FCC will weigh that very heavily.

I think that what we have is a large collection of international
commercial content providers who will be producing captions in a format
that they have coalesced around; they (not the FCC) made their choice and
that format is SMPTEE-TT. If SMPTEE can make the case to the FCC that the
Time Text format they've agreed upon meets the *user needs* for captioning
as understood by the FCC, then I really don't see the FCC putting up too
much of an argument against it.

While the FCC may indeed be the catalyst for deployment here, the FCC's
reach only extends within the USA. SMPTEE content producers however are
international in scope, and commercial video producers around the globe
will all be investing money and resources in a format that they have
collectively chosen. I honestly don't think they will care if the browsers
will support that format natively, or whether they will need to stream
their content to SMPTEE-TT aware/capable <objects> embedded into the web
browser (as they are already doing today with video content, with Netflix
being a bit of a poster-child here). I am sure they would be happy if
SMPTEE-TT support was native in the browsers, but I don't see it as being
a barrier in their adoption of SMPTEE-TT - they will be less religious
about the 'native' part of the delivery chain.

Thus, whether or not native support of SMPTEE-TT is in a browser or not
will then become a business decision of the individual browser vendors, in
a way very similar to the codec issue we face today. If one or more
browsers does not support SMPTEE-TT natively, and a company like NBC
Universal is doing all of their captioning (intended for web delivery) in
this format, I don't think that they will wring their hands and bemoan the
fact that Browser X doesn't support it natively - they will simply find
another solution (with technologies such as Flash and Silverlight standing
very ready to do just that).

At the risk of being overly controversial, I think that the browser
vendors need to re-read and reflect on the development goals of HTML5,
which stated "Users over content producers, producers over implementers,
and implementers over technical purity". If in-browser, native support of
video is important to the implementers, then they should be listening
carefully to the content producers: if the Academy of Motion Picture Arts
& Sciences, BBC, NHK and other established video content producers* around
the globe are already using a technology to achieve their mandated goals,
then the browsers either get on that bus, or leave those business
interests out of their mix. It's a question of who owns the fiddle, and
who does the dancing...


* SMPTEE Membership:
Received on Saturday, 5 February 2011 01:45:13 UTC

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