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

I think your reading about whether these are important core features is
probably correct. One common complaint that we are getting is that people
with visual impairments are not getting enough attention, and these, while
relatively small in number, are the ones who are the most affected by
background and foreground color issues. They are also the ones most likely
to use unusual font and color combinations. One thing I've heard from
consumers is that everytime they thought there was a font or color no one
used, someone spoke up and said that this was the combination that provided
the best reading experience to them.

Christian


On Wed, May 7, 2014 at 7:06 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:

> On Thu, May 8, 2014 at 1:52 AM, Christian Vogler
> <christian.vogler@gallaudet.edu> wrote:
> > 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.
>
> WebVTT regions were created to bring in the following features:
>
> * rollup captions
> * handling of a group of captions as an entity, in particular:
>   ** explicit fixed width and height box for rendering a group of
> captions into ("fixed width" in terms of px right now, but proposed to
> be changed to em to approximate number of characters; "fixed height"
> in terms of a maximum number of lines of caption cues that are visible
> on screen at the same time in the caption group)
>   ** background color and border on groups of captions (rather than
> just a single caption) so that there won't be any gaps between the
> rendered captions' backgrounds and borders
>   ** defining how change in font size changes the group box size,
> namely around an anchor point (this is a concept borrowed from 708)
> * overlap is being dealt with through z-index
>
> Also, there are other possible features when you deal with a group of
> captions rather than individual ones, such as moving the group
> together (without having to repeat text and thus destroy the
> simplicity of doing semantic analysis on cue text), transitioning on
> the whole group (e.g. fading out the whole group together), flex-box
> like distribution of the caption cues within the region box etc. These
> latter are possibilities for the future, not something we need now,
> but something that is enabled when we introduce the concept of a
> "group of cues" rather than just individual cues.
>
> If all of these are regarded as non-essential features, then of course
> I am prepared to drop the concept of regions right now, stop these
> discussions, and focus on getting the core of WebVTT polished.
>
> However, if my reading of the FCC rules is correct, rollup captions,
> explicit width/height control, and the handling of background color
> and border on a group of captions have been deemed important core
> features. This being the case, and having followed the last 3 years of
> discussions around how to add rollup support, my conclusion is that
> the concept of cue groups is both specific enough to solve the core
> features that the FCC requires, and generic enough to allow satisfying
> other use cases in future that relate to a group of captions.
>
>
> > 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.
>
> Positioning has been a key feature from the start of WebVTT. We have
> recently added some clarification to that by making it clear how
> alignment and positioning interact. This gives sufficient ability to
> authors to have fine-grained control over the placement of
> *individual* cues. I do not believe that positioning of *individual*
> cues is a reason to introduce WebVTT regions.
>
>
> > 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
>



-- 
Christian Vogler, PhD
Director, Technology Access Program
Department of Communication Studies
SLCC 1116
Gallaudet University
http://tap.gallaudet.edu/
VP: 202-250-2795