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

I'll respond in depth later when I'm not otherwise traveling our in
meetings. Appreciate your thoughts.

For now I'll reiterate something I said earlier: it might be helpful to
review the features that you are struggling with and how they are impacted
by your proposals, keeping in mind that the goal is equal to or better than
TV captions, not identical. I don't have a good handle on what these are,
because they're spread out over so many threads. If you could condense them
in a single message, that would be very helpful.

One thing I can say with certainty is that doing positioning well is
absolutely essential. That is not negotiable. I'll get back to you about
some more use cases re positioning soon, too.

More later, including consumer stances (to whom I regularly provide
technical advice) and the importance of standardization.

Best wishes
Christian

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

> On Wed, May 7, 2014 at 1:02 AM, Christian Vogler
> <christian.vogler@gallaudet.edu> wrote:
> > 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 agree that accessibility is important, that's why I want to work on
> WebVTT! It matters to me, not least because I use subtitles myself
> almost every day.
>
> Since I hope to keep working on WebVTT, it's kind of my job to
> criticize new features. When I don't understand the good reasons
> behind them, legalities is all that remains, and that's not a
> compelling reason to work on something. (Obviously, I have no veto
> power, and maybe others will do the work instead.)
>
> > 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.
>
> I don't work for a browser vendor based in the US and am not a lawyer,
> so I'm not in a good position to evaluate this claim. Is it public
> knowledge that some organizations indent to go to court if browser
> vendors don't implement and ship specific WebVTT features, even if
> those features can be implemented in JavaScript?
>
> > 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.
>
> The fullscreen problem is serious, I agree. If you try the latest
> Chrome beta for Android you'll find that it has finally been fixed. I
> haven't tested it, but I assume that overlaying custom controls or
> captions using JavaScript also works. (I think this fix landed in
> Chromium 35, so before long Opera will also have it.)
>
> This problem was unrelated to the WebVTT implementation, though.
>
> > 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.
>
> With the fullscreen issue resolved, it sounds like native WebVTT
> support is more of a convenience than an actual requirement. Even
> though I hope that WebVTT implementations will improve rapidly, I'd
> bet that for at least a few years, rolling your own rendering in
> JavaScript is going to be more reliable.
>
> Philip
>