Re: Absolute region positioning (was Re: Alternative approach to scrolling, with demos)

Saying that we need to do something because of some legalities is not the
right stance to take. It is because video accessibility to people with
disabilities matters, that we are doing this. A lot of the FCC legalities
with respect to internet video actually exist because that is what
consumers with disabilities, who first-hand depend on the outcome and use
captions on a daily basis, asked for. Not all the nooks and crannies are
wonderful or make sense, but a lot of them are there for good reasons.

I apologize for being so blunt, but my biggest fear right now is that we
end up rehashing arguments again that were very hard fought over, because
everyone has a different idea of what is important. That in part caused us
to end up where we are now: web browsers missed the 2014 deadlines and are
not complying with accessibility laws and rules. This isn't a legality but
something that affects us concretely on a day to day basis, and the only
reason that advocacy organizations are taking a wait and see stance, rather
than going after noncompliance, is that they are aware that WebVTT
standardization efforts are not complete yet.

One way this situation concretely affects us is that the mobile browsing
experience is just inaccessible. As an experiment, try
http://tap.gallaudet.edu/articles/fcc/ on mobile browsers. Take Android
JellyBean with the old WebKit browser. No captions at all. Take Android
KitKat with Chrome, or standalone Chrome, and captions work - as long as
you don't try to switch to fullscreen mode. Take a desktop browser and
fullscreen works. But mobile isn't there and content providers have already
stated that they need to get the browser manufacturers to get their act
together in order to meet their obligations to caption everywhere. Because
that hasn't happened yet we are missing a huge part of the mobile
existence. We're kind of hoping that WebVTT will get us there, not the
least because we don't have good alternatives in sight.

Consumers probably won't care if we do a feature via native WebVTT or
JavaScript, but they will care if JavaScript polyfill doesn't work in
fullscreen, which is where we are right now. Either way, browser
manufacturers are on the hook, and in my view it's better to have a
standard than a wild west of JavaScript based methods that are inconsistent
from site to site and browser to browser.

Thank you for listening.

Best wishes
Christian

Sent from my mobile phone.  Please excuse any touchscreen-induced weirdness.
On May 6, 2014 6:21 PM, "Philip Jägenstedt" <philipj@opera.com> wrote:

> On Tue, May 6, 2014 at 4:45 PM, Nigel Megitt <nigel.megitt@bbc.co.uk>
> wrote:
> > On 06/05/2014 14:17, "Philip Jägenstedt" <philipj@opera.com> wrote:
> >
> >>On Tue, May 6, 2014 at 12:19 PM, Nigel Megitt <nigel.megitt@bbc.co.uk>
> >>wrote:
> >>>
> >>> On 05/05/2014 15:14, "Philip Jägenstedt" <philipj@opera.com> wrote:
> >>>
> >>>>On Mon, May 5, 2014 at 2:50 PM, Silvia Pfeiffer
> >>>><silviapfeiffer1@gmail.com> wrote:
> >>>>
> >>>>> NB: Incidentally, following CEA708 rendering as exactly as possible
> is
> >>>>> inline with what the US law prescribes, namely identical rendering
> >>>>> between TV and Online. Though, to be honest, there is a line of
> "rough
> >>>>> identity" that I am prepared to accept and I would call overlap
> >>>>> avoidance an optimisation of sorts, which is why I'm not really
> >>>>> accepting this as an argument.
> >>>>
> >>>>What will we do if the European Union introduces similar legislation
> >>>>and broadcasters say that their existing content is EBU-TT, a TTML
> >>>>flavor? Should the TTML model be added to WebVTT?
> >>>
> >>> I don't know about adding the TTML model precisely but I do think it
> >>>would
> >>> be worth considering the logical semantics encapsulated in TTML for
> >>>region
> >>> definition and overlap processing, which has an accepted mapping from
> >>> CEA708 already, and has therefore tackled these questions. Given that
> >>> WebVTT is on Rec track in the TTWG and one of the deliverables is a VTT
> >>> <--> TTML mapping it would make everyones' lives easier in creating
> that
> >>> deliverable if the regions models are as closely coincident as we can
> >>>make
> >>> them, accepting the differences in rendering approach and syntax
> between
> >>> the two formats.
> >>>
> >>> I haven't seen anything in the discussion so far that looks like a
> >>>CEA708
> >>> requirement that can not already be met using TTML regions. If you want
> >>> region overlap avoidance that would be different, but I suspect that
> >>>isn't
> >>> actually needed, and in any case would be a separate case from the
> >>>z-index
> >>> overlap order definition: I can't see how both approaches could apply
> to
> >>> the same content simultaneously.
> >>
> >>So, my question was actually rhetorical. I don't think it should be a
> >>goal in itself to map other formats to WebVTT, or for WebVTT to be one
> >>format to rule them all.
> >
> > Sorry I didn't spot the <rhetorical> tag! In any case there is a point to
> > discuss there. I agree that format mapping isn't an end in itself, but in
> > this case we know that some form of mapping will be generated and we can
> > aim to make life easier by reducing the size of the task. To be clear,
> > there is a TTWG goal to map between WebVTT and TTML - it is in the
> group's
> > charter.
>
> If the required changes are trivial or are supported by common use
> cases then that would be valuable feedback like any other. It is
> making non-trivial changes for no other purpose than format mapping
> that I am wary of, because it is a road with no apparent end, and one
> that we don't need to walk if we take advantage of the fact that
> WebVTT is a part of the Web platform where less common use cases (a
> judgement call) can be left to custom rendering using JavaScript.
>
> >>If other formats have features that address common use cases that
> >>WebVTT is missing then we should consider supporting those use cases,
> >>of course.
> >
> > I get the impression this is about FCC-mandated requirements rather than
> > usage frequency. It makes sense to do as little as possible to meet those
> > requirements and expand & enhance later if people want to use it in new
> > ways. Lifting the existing region model from TTML would probably fit that
> > description.
>
> As far as I am aware the FCC doesn't require using a specific
> technology to meet the requirements. However, I'm having trouble
> getting clear answers on this topic from legal, and don't know the
> plans of any browser company.
>
> Philip
>
>