Re: Media: Question about autoplay (video in browsers)

David Singer writes:
> 
> On Jan 28, 2011, at 11:20 , Silvia Pfeiffer wrote:
> 
> > On Fri, Jan 28, 2011 at 12:12 PM, David Singer <singer@apple.com> wrote:
> >> 
> >> On Jan 28, 2011, at 11:02 , Silvia Pfeiffer wrote:
> >>> 
> >>> 
> >>>>  Kenny Johar had an interesting idea when we talked about this issue last week on the task force telcon: have each UA provide a "pause all media elements" API for assistive technology products so the user can pause playback by touching a key. I like this idea because it puts control in the hands of the user, the only one that actually knows when they don't want to hear something play.
> >>> 
> >>> 
> >>> That is a very interesting idea and I think it would be very useful to
> >>> everybody. When my browser crashes and I reload it with all the tabs
> >>> that were open beforehand, I sometimes have videos start playback in
> >>> tabs that I didn't even remember I had open. It would be very good to
> >>> have a button: "pause all media elements on any tab", which then
> >>> avoids me having to go look through all the tabs to find the one that
> >>> is causing the autoplay trouble. That's really a great idea IMO.
> >> 
> >> 
> >> This is promising, but I am puzzled.  If a page has a video that the site has set auto-play, no default controller, and no custom controls, and then the UA does a 'pause all', how does that UA now enable the user to re-enable play?
> >> 
> >> Slight variation:  'UAs may have a setting "standard play is disabled" which means that auto-play, play(), the built-in controller, none of them can play the content.  Instead, the UA must offer some affordance to control play/pause.'
> >> 
> >> This is not ideal, especially for audio-only elements, where it's not obvious what affordance would work, and it is probably not obvious to the user that something *might* have played (and hence they should look for the affordance).
> >> 
> > 
> > 
> > I understood that the button would pause all currently playing media
> > elements at that instant - not disable playback altogether.
> 
> I was suggesting an alternative which, for an accessibility UA, would really close the door.  Basically it says it's OK to give control completely to the UA and take it from the markup and scripts.  It has obvious downsides; if playback is supposed to be accompanied by other page actions, it won't be, unless the page is written in such a way to do those based on events.
> 
> > 
> > You do have a point about background audio elements though, which
> > would be impossible to re-enable if the Web page author did not
> > provide a possibility. It would, however, have been an <audio> element
> > that was set to autoplay and had no user controls, so its content
> > can't have been that important to the page author anyway.
> > 
> 
> I don't think we can assume that.  If I click on a link that takes me to a new page whose sole purpose was to play me an audio (maybe accompanied by other material), for example, the audio is the primary content.
> 
Well, if I know that I will get audio BEFORE clicking on the link,
that's one thing. But, if I'm surprised into the situation it's quite
another kettle of fish. As a user, I have very low regard for any author
who thinks their audio is more important than the audio from my UI
(namely the TTS from my screen reader). I'm unlikely to care about
whatever "message" they're trying to push at me at that point.

Janina

> David Singer
> Multimedia and Software Standards, Apple Inc.
> 

-- 

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 Friday, 28 January 2011 16:17:56 UTC