W3C home > Mailing lists > Public > public-html-a11y@w3.org > October 2010

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

From: <bugzilla@jessica.w3.org>
Date: Mon, 11 Oct 2010 02:42:51 +0000
To: public-html-a11y@w3.org
Message-Id: <E1P58Lj-00013h-2W@jessica.w3.org>
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 on the CC list for the bug.
Received on Monday, 11 October 2010 02:42:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:22 GMT