RE: [media] adding autoplay requirements to requirements doc

That all makes a certain amount of sense; it would carry a little more weight if there were some language in the spec to the effect that autoplay is a request that the user agent can deny. For example,
 
Rather than defining autoplay as:
" When present, the user agent (as described in the algorithm described herein) will automatically begin playback of the media resource as soon as it can do so without stopping "
Instead define it along the lines of:
" When present, the user agent (as described in the algorithm described herein) will; unless a user agent setting has been set indicating that immediate playback is allowed, move the media into a potentially playing but blocked state: http://www.whatwg.org/specs/web-apps/current-work/complete/video.html#blocked-media-element which is waiting for user interaction  http://www.whatwg.org/specs/web-apps/current-work/complete/video.html#paused-for-user-interaction "

Sean.


-----Original Message-----
From: public-html-a11y-request@w3.org [mailto:public-html-a11y-request@w3.org] On Behalf Of Eric Carlson
Sent: 20 April 2011 17:25
To: Philip Jägenstedt
Cc: public-html-a11y@w3.org
Subject: Re: [media] adding autoplay requirements to requirements doc


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.

  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?

eric


[1] http://www.brucelawson.co.uk/2009/accessibility-of-html5-video-and-audio-elements/
[2] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019647.html

Received on Wednesday, 20 April 2011 17:11:14 UTC