W3C home > Mailing lists > Public > public-html-a11y@w3.org > April 2011

Re: [media] adding autoplay requirements to requirements doc

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Thu, 21 Apr 2011 07:33:06 +1000
Message-ID: <BANLkTik+CK8Qir4KcR4tqWSCatDevx_yHQ@mail.gmail.com>
To: Philip Jägenstedt <philipj@opera.com>
Cc: public-html-a11y@w3.org
On Thu, Apr 21, 2011 at 4:27 AM, Philip Jägenstedt <philipj@opera.com> wrote:
> On Wed, 20 Apr 2011 18:24:43 +0200, Eric Carlson <eric.carlson@apple.com>
> wrote:
>
>>
>> On Apr 20, 2011, at 4:11 AM, Philip Jägenstedt wrote:
>>
>>> On Wed, 20 Apr 2011 12:08:09 +0200, Silvia Pfeiffer
>>> <silviapfeiffer1@gmail.com> wrote:
>>>
>>>> On Wed, Apr 20, 2011 at 5:41 PM, Philip Jägenstedt <philipj@opera.com>
>>>> wrote:
>>>
>>>>> If it's a problem that media starts playing without user consent then
>>>>> it's
>>>>> not enough to disable autoplay, as there will certainly be sites that
>>>>> use
>>>>> scripts to start playing.
>>>>
>>>> Yes, we agreed on that, too. But we didn't see a way to catch the
>>>> script-created autoplays in a simple and reliable way.
>>>
>>> The browser inevitably has to know when a video should start playing. At
>>> that point, one could simply not play until an asynchronous confirmation has
>>> been given, similar to how pop-up blockers work.
>>>
>>  The problem is knowing when to block script-initiated playback and/or ask
>> the user for confirmation. "If play() was not called from a user gesture
>> handler" is an easy answer, but that break playlists, scripts that call
>> play() after a delay (eg. to let an animation run), etc. Requiring a user
>> gesture doesn't really solve the problem anyway - someone that really wants
>> to start playback automatically can call play() from an event handler
>> registered on <body> like "pop-under window" scripts do to get around pop-up
>> blockers today.
>
> It doesn't have to use exactly the same logic as pop-up blocking, I was
> mostly thinking about the asynchronous approval. As for when to ask, if
> nothing else works one could simply always ask and remember it per-origin to
> reduce the annoyance somewhat. This is assuming that playback without user
> confirmation is a catastrophic failure to avoid at all cost, which might not
> be entirely true.
>
>>  We had this discussion at great length on the WhatWG several years ago.
>> In his "Accessibility of HTML 5 video and audio elements" blog post [1],
>> Bruce Lawson originally questioned the 'autoplay' attribute but after a few
>> days updated the post to say "I’m now reluctantly accepting that autoplay
>> should stay" because of Simon Pieters point [2]  that:
>>
>>    Removing the attribute will not make pages stop autoplaying video.
>> Instead they will use
>>    script to make videos autoplay, and then it becomes harder for the user
>> to prevent
>>    videos from autoplaying. (You could have a pref in the UA to disable
>> autoplay="".)
>>
>>  The 'autoplay' attribute on the HTMLMediaElement is useful because it
>> allows a page authors to *request* automatic playback, but it allows a UA to
>> *deny* that request if a user so desires. Why would the same not apply to a
>> group of media elements?
>
> I have no issue with the autoplay attribute, or I wouldn't have added a user
> pref to "deny that request". As for autoplay on MediaController:
>
> On Mon, 18 Apr 2011 10:59:28 +0200, Philip Jägenstedt <philipj@opera.com>
> wrote:
>
>> I have no strong opinion, but we should have consistency such that
>> changing the paused attribute (e.g. by calling play()) has the exact same
>> effect. It's not clear to me what the spec thinks should happen when play()
>> is called on a media element with a controller.
>
> Also, where should the autoplay attribute be in the markup?


On one of the slaves.

Silvia.
Received on Wednesday, 20 April 2011 21:33:54 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:19 UTC