Re: [media] how to support extended text descriptions

Hi Janina,

On Thu, Jun 16, 2011 at 12:13 AM, Janina Sajka <> wrote:
> Silvia Pfeiffer writes:
>> Hi Masatomo,
>> I believe there may be a misunderstanding.
>> On Wed, Jun 15, 2011 at 6:58 PM, Masatomo Kobayashi <> wrote:
>> > Hi Silvia,
>> >
>> > Maybe I have some misunderstanding of the spec or the implementation you
>> > expected, but for the second problem, my concern is as follows:
>> >
>> > 1. When voicing has not finished by the end time of a cue, the video is
>> > paused as the cue's pause-on-exit flag is true.
>> Yes, this is true.
>> > 2. Then the user clicks on the pause button to pause the video, but this
>> > will resume the video unexpectedly as the video is already paused and the
>> > button is a toggle button.
>> No, this is not how I understand it. Since the video will be in a
>> non-paused state, just a "paused for user interaction" state like
>> described here:
>> . Thus, if the user hits "pause", the video's state will change to
>> "paused" and the video will not start playing. Also, if the user hits
>> "play" again, I believe the video will also continue to stay in
>> "paused for user interaction" state until the "pauseOnExit" flas is
>> set to false. I am not sure about that latter part though.
>> > This will confuse the user.
>> Actually, any user interaction in this state may be confusing. Maybe
>> we need to have the player bring up a message such as "waiting for AT
>> to finish".
> No, the computer ALWAYS waits on the user, not the other way around.
> Recall that silencing speech is a critical feature of TTS based
> interfaces. Screen readers are judged on how quickly they respond to
> "shutup" commands.

Sorry to have confused you: we were talking about the pause/play
buttons of the video, not the pause/play buttons of the TTS. They are
different and my reply was targeted at defining the behaviour that
happens when a user hits the pause/play of the video - the pause/play
behaviour of the TTS is indeed well defined.

Would you mind re-reading the questions with this understanding and
explaining what you would expect when the TTS is talking and the user
hits the video's play/pause button?


>> > As when the TTS pauses/resumes the video is unpredictable for the user, it
>> > is difficult to properly choose browser's pause or TTS's pause in time.
>> Indeed. Maybe if the user decides to hit "play" twice, it should
>> overrule the waiting for the TTS and unset the "pauseOnExit" flag? Or
>> we can have only the AT "stop" key be the key that can overrule the
>> waiting. I would actually be curious what kind of behaviour people
>> would like to see.
> We have two controls, one based on heuristics, the other on user
> commands. The former always gives way to the latter.
> So, if the heuristic pauses video because TTS is still talking, but then
> the user presses 'pause,' the TTS stops talking and the heuristic
> control is reset to default state so that the user initiated pause
> command is now fully in control of pause/play.
> Pressing play (unpause) at this point does NOT resume TTS of the
> extended text description, but rather it resumes playback of the primary
> resource.Perhaps this is the point of confusion here?
> Should the user wish to hear the extended description again, a slight
> rewind (nav-point back) into the primary resource would requeue that
> extended description.
> We should also recall that the user will have full access to a texted
> video description is a file that can be independently read, brailled,
> etc. The superior media playback tool will facilitate that. There's no
> reason the user is restricted to hearing descriptions only in
> conjunction with the primary video resource. This is the reason I
> believe my behavior scenario is correct--the reason why pause and resume
> within the extended TTS voicing should not be of too great a concern.
> John? Geoff? Others? Am I wrong on this behavior?
> Janina
>> > Perhaps this problem will be alleviated if the "pause" interface is not a
>> > toggle, at least in the keyboard control?
>> It has to be, but there is the overruling with the "paused for user
>> interaction" state, so I don't think that's the problem. However, the
>> expected UI behaviour is a problem and we should make recommendations
>> to AT/browsers.
>> Cheers,
>> Silvia.
> --
> Janina Sajka,   Phone:  +1.443.300.2200
> Chair, Open Accessibility
> Linux Foundation      
> Chair, Protocols & Formats
> Web Accessibility Initiative
> World Wide Web Consortium (W3C)

Received on Wednesday, 15 June 2011 23:08:48 UTC