Re: [media] how to support extended text descriptions

Hi Masatomo,

I believe there may be a misunderstanding.

On Wed, Jun 15, 2011 at 6:58 PM, Masatomo Kobayashi <MSTM@jp.ibm.com> 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:
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#paused-for-user-interaction
. 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".


> 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.


> 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.

Received on Wednesday, 15 June 2011 09:20:04 UTC