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

This is well put, and I share the goal of making content accessible to all. My comment was merely a reflection on the need to match 708 regions, which in itself isn't an accessibility target but a 'matching this other spec' target, due to legal/regulatory requirements which we can not avoid. Of course I would support specification and implementation of the genuine use cases for this functionality as a matter of priority.  I do not think we need to reopen old debates here.

Nigel

On 07/05/2014 00:02, "Christian Vogler" <christian.vogler@gallaudet.edu<mailto: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 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<mailto:philipj@opera.com>> wrote:
On Tue, May 6, 2014 at 4:45 PM, Nigel Megitt <nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>> wrote:
> On 06/05/2014 14:17, "Philip Jägenstedt" <philipj@opera.com<mailto:philipj@opera.com>> wrote:
>
>>On Tue, May 6, 2014 at 12:19 PM, Nigel Megitt <nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>>
>>wrote:
>>>
>>> On 05/05/2014 15:14, "Philip Jägenstedt" <philipj@opera.com<mailto:philipj@opera.com>> wrote:
>>>
>>>>On Mon, May 5, 2014 at 2:50 PM, Silvia Pfeiffer
>>>><silviapfeiffer1@gmail.com<mailto: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




----------------------------

http://www.bbc.co.uk

This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

---------------------