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

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

Received on Wednesday, 7 May 2014 15:28:55 UTC