Re: Support for advanced caption features (inc rollup)

Comments inline.

Sent from my mobile phone.  Please excuse any touchscreen-induced weirdness.
On Dec 11, 2012 7:31 PM, "Ian Hickson" <ian@hixie.ch> wrote:
>
> On Tue, 11 Dec 2012, Christian Vogler wrote:
> >
> > Basically it says: if you distribute TV programming on the Internet, you
> > must also send the closed captions, and the software or hardware that
> > you provide to users for viewing your programming must display those
> > captions.
>
> Publishers don't generally provide such software

Incorrect. Almost all do. Apps on mobiles,  tablets, IPTVs, embedded
players in webpages (JWPlayer, OSMF, YouTube web player, etc). The list of
distributors who do this is long: Apple,  Google, Netflix,  Amazon, Hulu,
ABC,  CNN, Fox, Discovery, PBS, SyFy, Yahoo, Microsoft,  etc. It's very
hard to find anyone who doesn't on at least some platforms.

Who's to blame if ABC
> puts a WebM and VTT file pair on the Internet, Jane Doe creates a Web page
> with <video> elements pointing to it, and the user runs Opera to read it,
> and the captions don't show? Who should the user sue? On what grounds?

If Opera was bundled with hardware,  Section 203 makes the hardware
distributor responsible. It would be in opera's best interest to comply
with the requirements,  as otherwise they can never engage in bundling
deals.

> > And that's where the browsers come in.
>
> The requirement only extends as far as TV programming on the Web. If I
> film my cats and put them online and then someone uses Firefox to watch
> the video, nothing here applies to us, as there's no TV programming.
>
> My network router is capable of playing back video -- I could SSH into it
> and upload a script that downloads MPEG4 files of TV shows and then
> converts them to ASCII animations played back over SSH. Does that mean
> that my router's manufacturer has to implement scrolling captions?

That's exactly the principle of functional equivalence.  Hearing people can
access video programming in a certain way,  then so must people with
disabilities.

That said there is the achievability test. If not technically achievable as
in the ascii case,  no requirement kicks in. But web browsers most
definitely do not fall under this test.

> I think you're making a leap that isn't justified by the text you're
> citing. There are specific situations where the text requires captions
> supported in specific ways, but it isn't at all clear to me that all
> browsers are affected by these regulations, since not all browser vendors
> find themselves in those situations.

Only because of the bundling with hardware. That was a concession to
prevent independent third party software vendors from being hit by the
requirements. And I'd seriously suggest talking to a lawyer at Google. What
doesn't make sense to me is arguing about stuff that has already been
settled by the people involved in the implementation of the cvaa.

Christian

>
> I think in practice it might be better to just have the browsers that feel
> they need to follow these regulations implement straight 608 captions
> (that is, just a binary file consisting of the raw caption byte pairs, or
> maybe binary files in the 708 wrapper), and the people who want to put out
> TV programming on the Web include 608 captions, and then for the 608
> captions to be entirely ignored by everyone, with the "real" captions
> transmitted in VTT in a layout optimised for the Web. Then the regulations
> are satisfied, and yet we can still get on with doing sensible stuff on
> the Web (rather than worrying about whether we have to support "serif
> monospace" or text with sunken edges or scrolling captions).
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'