W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > January to March 2011

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

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Fri, 28 Jan 2011 12:02:23 +1000
Message-ID: <AANLkTik136OwgFrsC8zhdzPnpJzJ9QYAjjtxbc3rWjgE@mail.gmail.com>
To: Eric Carlson <eric.carlson@apple.com>
Cc: Jim Allan <jimallan@tsbvi.edu>, david.bolter@gmail.com, Charles McCathieNevile <chaals@opera.com>, Sean Hayes <Sean.Hayes@microsoft.com>, WAI-UA list <w3c-wai-ua@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>, Philip Jägenstedt <philipj@opera.com>
On Fri, Jan 28, 2011 at 11:57 AM, Eric Carlson <eric.carlson@apple.com> wrote:
>
> On Jan 27, 2011, at 5:14 PM, Silvia Pfeiffer wrote:
>
>> On Fri, Jan 28, 2011 at 8:12 AM, Eric Carlson <eric.carlson@apple.com> wrote:
>>>
>>> On Jan 27, 2011, at 12:06 PM, Eric Carlson wrote:
>>>
>>>>
>>>> On Jan 27, 2011, at 10:39 AM, Philip Jägenstedt wrote:
>>>>
>>>>>
>>>>> Short answer: Yes, it's possible.
>>>>>
>>>>> I've recently added a user preference to Opera to disable autoplay, and this should be in a not too distant release of our desktop browser. If it turns out that it's common with sites that use script to force autoplay, then it's possible to go further. Specifically, one could use the same techniques that are used for pop-up blockers to see if the play() request was from user interaction or a background script. If isn't from direct user interaction, one could ask the user to explicitly allow the media to play, perhaps remembering the choice for the site.
>>>>>
>>>>> However, this kind of thing would be an opt-in setting, since we don't want to bother users with lots of dialogs by default.
>>>>
>>>>  iOS devices have this restriction - playback of a <video> or <audio> element can only be triggered in response to a user gesture (like pop-up blockers). This has caused no end of bug reports because it is impossible to differentiate script originated "auto play" from playback triggered by a script after a delay, eg.
>>>>
>>>>       onclick= "setTimeout(function(){ video.play() }, 200)"
>>>>
>>>> or in response to another event, eg. to start playback after something else happens:
>>>>
>>>>       button.addEventListener('webkitAnimationEnd', function (){ video.play) }, false);
>>>>
>>>>  Neither of these is a much of an edge case as you might think, I get bug reports all the time about web sites where <video> "doesn't work on the iPhone" because they use script to trigger playback.
>>>>
>>>  I meant to add that one real danger with this kind of change is that many (most?) developers won't test with the setting enabled, so audio and video on their pages won't just not auto-play - it won't play at all.
>>>
>>
>> It seems to me that completely disabling video.play() is not really a
>> good thing. That would mean that any video that has custom controls -
>> even one that has been developed with large buttons and the like to
>> make it more accessible - will not work.
>>
>  I don't think that anyone was proposing to disable play(), only to disable it when it is not called from code triggered by a user gesture event (click, touchend, etc). This is what we do on iOS, and as I noted it causes all sorts of problems with legitimate use cases.


OK, I misunderstood.


>> Can there be something like a user setting that disables @autoplay
>> without disabling video.play()? Or at least disable video.play() only
>> during the window load period such that user interaction will still
>> work afterwards?
>>
>  This will only prevent scripts from triggering playback when the window loads, which I don't think will be very common because it is much simpler to use the 'autoplay' attribute and we can easily prevent that (btw, 'autoplay' was added specifically so a UA can have a "don't autoplay" preference).
>
>  It seems to me that the more likely case will be scripts that trigger audio playback in response to other events: playing a sound when a UI element gets focus, playing an "audio cue" to prompt the user to do something after a period of inactivity, etc, etc.
>
>  The problems is when audio plays (and so interferes with/masks the screen reader) *for any reason* unless the user requests it. As I noted earlier, I don't think we can solve this problem programmatically in way that doesn't cause other problems for everyone.


I agree. It would be very hard to solve this programmatically without
negative side effects.


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

Cheers,
Silvia.
Received on Friday, 28 January 2011 02:04:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 28 January 2011 02:04:21 GMT