[Bug 10941] Media elements need control-independent "pause" for presenting lengthy descriptions/captions

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10941

--- Comment #12 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2010-10-11 02:42:50 UTC ---
(In reply to comment #11)
> One more thing that I just realised: sometimes it is very obvious that a
> description cue will not fit into a given time frame - in particular if there
> isn't actually any time available to put it in and it is basically associated
> with a time point rather than a segment.
> 
> In this case, it would be possible to record into the WebSRT file the requested
> pause duration for the screenreader for the cue and have the player pause for
> that duration as it reaches the cue. This solution is based on heuristics as to
> how long an average screenreader will take to finish reading a cue and can turn
> out rather inaccurate, but it allows solving the situation without having to
> wait for an event from the screenreader to stop / continue playback.
> 
> Actually, this is the way in which I will be implementing this functionality in
> a JavaScript demo for now, which of course means introducing a non-standard
> marker into WebSRT. Gah, damned custom extensions... :-(

This raises an interesting option: we could add a parameter to the pauseonexit
event that tells it to pause for how long. Then, such a parameter might
actually make sense to include in WebSRT.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 11 October 2010 02:42:52 UTC