Re: [media] how to support extended text descriptions

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.
> 
> 
> > 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 14:13:45 UTC