Preventing sites from prompting users on Autoplay

[sushraja-msft]

What are the mitigations to prevent sites from throwing prompts that require users to turn off auto play to continue browsing?
The current Play method on the HTMLMediaElement already provides information via the rejection handler https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/play#exceptions, that media playback was NotAllowedError - if a site is truly interested in providing fallback content, they can catch this exception and try again with the stream muted.

[alastor0325]

require users to turn off auto play to continue browsing?

I suppose you mean "turn off blocking autoplay"?

Not sure I understand this quesition correctly. No matter we have Autoplay Detection API or not, websites can always ask users to turn off blocking autoplay if they really want to make their media playing. (because they can know that by the rejected promise)

Autoplay Detection API is used to give websites a better way to know whether media can be allowed to autoplay, in order to let them have a chance to implement something which has a better user experience, instead of showing still images or nothing.

If prompting to users is because website can't detect autoplay policy well, then I think this API is defintely helpful for preventing showing more prompts. But if prompting to user is just because websites really want everything on their site playable, then that would be website's choice and we can do nothing.

[sushraja-msft]

Yes, I meant - "turn off blocking autoplay".

Are there examples of sites that would like to detect autoplay being blocked and switch to different media? All the feedback we have received so far are about how autoplay limit is not comprehensive enough and that users want a stricter ability to prevent autoplay and more control (restricting gifs for example).

The current proposal moves the balance more towards the site, and restricts future UAs from doing things like delaying the resolution of the play promise until the user consents to it - since the policy is exposed upfront and sites may change their behavior based on the response.

Perhaps the strategy with this proposal is to work with web developers and if they had a way to detect user preference, they would not auto play media. I would like to learn more about this aspect, are there public asks that I could look at.

[chrisn]

Minutes from Media WG discussion on 8 March 2022: https://www.w3.org/2022/03/08-mediawg-minutes.html#t01

If the result from calling the API is only informative, does this impact how sites want to adapt based on browser auto-play policy?

I suggest seeking developer input on this, for example via the video-dev slack group.

[gkatsev]

Reading the minutes, I do not think that making this API non-binding is useful and will potentially lead websites to ignore the API altogether and continue with detecting the autoplay behavior by trying to play a video element like the can-autoplay module does.
Specifically, a big issue is around ads. Ads that are played with audio vs muted ads come from different inventories and have different costs associated with them, so, it's important to know ahead of time what the autoplay policy is. In these cases, the appropriate ad that corresponds the autoplay detection will then be loaded. For example, ads that are allowed to play muted or ads that are with audio when autoplay isn't allowed altogether.
In addition, player libraries that provide simplified tooling around autoplay will not be able to simplify their code either. For example, in Video.js, we have autoplay enums like muted, and any which specify autoplay behavior for the player. With any the player will try to play with sound and then if the promise fails, mute the player and try again, and if it fails again, fall back to click to play. With the new autoplay policy API, it should theoretically be possible to simplify this code and go directly to the correct interaction based on the policy, but if it isn't binding, we can't rely on it and have to maintain the code we have currently.