It’s an ongoing debate – users do not like videos to autoplay (apart from YouTube), and designers want their website to feature their video and audio immediately on visiting the page.

In the distant past, this has often been ‘solved’ by using Adobe Flash to play videos. Browsers soon caught up to this madness, and added ‘click to play’, forcing users to click to view Adobe Flash players. Since the replacement of Adobe Flash with better technologies such as HTML5, audio and video playback has still been a bone of contention for many people. Many browsers would interpret this in different ways, and especially mobile phone users would have a very different experience.

Since September 2017, Apple’s Safari took the lead to change how this worked, and Google’s Chrome has recently (January 2018) followed suit, and Mozilla Firefox has a similar feature.

What exactly are the changes?

Websites should assume any use of <video> or <audio> requires a user gesture click to play. Auto-play may be denied, and users now have the ability to turn off all forms of auto-play, including silent videos.

This means that videos may not automatically play, depending on the users’ setting. By default, some browsers are allowing ‘silent’ videos to autoplay. Audio never will be automatically started, without a user interaction such as a click.

Is this just for mobile devices?

No, this will apply to all users – including desktop browsers. Many mobile phone devices; Android and iOS have already implemented this. This same functionality will be soon applied to Google Chrome, Mozilla Firefox, and Microsoft Edge.

What does this mean for me?

Users should never expect to hear music playing on page load, unless they have enabled it.

For site admins, your videos and audio can never automatically play on a website.
This includes banner adverts with silent audio, as users may have disabled all automatic playback.
If you want audio to be playing automatically when visiting your page, you will need to rethink how this works. It will be a requirement that a user clicks a button to start playback.

This may be a huge annoyance for some website creators – but more annoying is unrequested audio playback.

What should developers be looking for?

  • Don’t assume a media element will play, and don’t show the pause button from the start. Look at the Promise returned by the play function on HTMLMediaElement to see if it was rejected.
  • Autoplay is enabled per-element, and reusing a video tag is permitted.
  • Don’t play ads without media controls, or rely on play() events.
  • Relying on silent video is not recommended, and even videos with ‘silent’ audio tracks are not completely silent. Removing the audio track may help, but this is not an advisable solution as it may still be disabled.
  • It may also be possible to mute the video before initiating automatic playback, but this may not work in all browsers or with all settings.
  • Currently there are some ‘workarounds’ to enable playback, by using timing or other triggers. It is likely these will be fixed in future, and playback must be initiated by a user event.

How are other companies getting around this?

Youtube have recently added a feature with a “hover to unmute” button. This can be found on Android web browsers (not the YouTube app). This appears when the video is able to play, and only when the audio is muted. Hovering over the video is considered a user action which the browser then uses to unmute. Where autoplay is completely disabled, the media controls are still available to use in the normal way.

This solution doesn’t seem to be heavily-discussed, but it could be assumed that the Video tag is set with volume muted. Playback is then started, and if this is is successful, the ‘hover to unmute’ option is shown on top of the video. On a hover event of the video, this is accepted as a user interaction by the browser, and the hover event changes the volume back to the default.

An alternative and similar solution seems to be that it would also be possible to start playback when the user has clicked another button on the site (e.g. closing a popup, or clicking a call to action) as this would be considered a user interaction event. However this may be confusing to some users and should be made clear.

 

We’ve been asked previously to workaround these restrictions, and often it is possible – but not recommended. The only way to be sure is to investigate your needs fully, and test against the majority of your users. We’ve worked on many of these problems before, do let us know if we can help.