Re: Roll-up captions in WebVTT

On Dec 19, 2011, at 16:21 , Christian Vogler wrote:

> I am concerned that repetion is also a way to make captions totally inaccessible to blind users. Even if you marked repetitions specially, screen readers would still have to support such markup explicitly.
> 
> 

yes, that was my 'disadvantage' number 2…

I need to chat with my screen reader colleagues to learn how they cope with text objects that move, today...

> Christian
> 
> Christian Vogler, PhD
> Director, Technology Access Program
> Department of Communication Studies
> SLCC 1116
> Gallaudet University
> http://tap.gallaudet.edu/
> VP/Voice: 202-250-2795
> 
> On Dec 19, 2011 7:11 PM, "David Singer" <singer@apple.com> wrote:
> 
> On Dec 19, 2011, at 16:00 , Glenn Maynard wrote:
> 
>> On Mon, Dec 19, 2011 at 11:30 AM, David Singer <singer@apple.com> wrote:
>> > It's only evil if you can't tell it's a duplicate when you need to know (e.g. when using TTS), and what I am suggesting is tagging to say that, for those that need to know.
>> 
>> It's evil and ugly regardless.  For credits, you would need hundreds or even thousands of copies of each cue to scroll all the way up the screen.  I'm actually a bit taken aback that it's being put forward seriously.
> 
> 
> I agree it doesn't work well for long credits.  I am also a bit taken aback at having an idea dismissed as 'evil and ugly' before we've really either worked it out or seen the alternatives. Can we debate the ideas along with (or preferably without) the value adjectives?
> 
> I understand it doesn't *look* clean to repeat a text line that occurs in two different places in two consecutive cues, but it has a number of advantages.
> 
> The disadvantages: 
> * it doesn't 'feel right' to repeat things (but the bit-rate gain is minimal, in my opinion)
> * tagging is needed so that systems that need to know when it has happened can tell (e.g. screen readers)
> 
> The advantages:
> * no cue-to-cue dependency -- no I frames and P frames (this is pretty big, IMHO); each cue contains all its own text
> * allows the expression of any transition, not just scrolling: moving to stay with the speaker or out of the way, changes of color, background, etc.
> * allows the use of CSS transitions to express the optionality and effect of the transition
> 
> (The last deals with some of Gal's complaint; a user could choose a user-agent that doesn't do smooth transitions, if they don't like them; CSS aspects are configurable in a natural way).
> 
> I note that repetition for text that moves is likely to be used anyway (it's the cheap way to do speaker-follow and jump-scroll) so getting the markup to say when it has happened might be a win, anyway.
> 
> 
> 
> David Singer
> Multimedia and Software Standards, Apple Inc.
> 

David Singer
Multimedia and Software Standards, Apple Inc.