Re: [media] how to support extended text descriptions

Hi Janina,

On Thu, Jun 16, 2011 at 12:13 AM, Janina Sajka <janina@rednote.net> wrote:
> Silvia Pfeiffer writes:
>> 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".
>
>
> 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?

Cheers,
Silvia.


>> > 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
>                sip:janina@asterisk.rednote.net
>
> Chair, Open Accessibility       janina@a11y.org
> Linux Foundation                http://a11y.org
>
> Chair, Protocols & Formats
> Web Accessibility Initiative    http://www.w3.org/wai/pf
> World Wide Web Consortium (W3C)
>
>

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