Autoplaying of audio, and videos that contain an audio track, is disabled by default in the latest release of Safari. From a participant's point of view, audio and video must be triggered by a user action (i.e. a click or a tap) before they can play. In March/April 2018, this behaviour will also be coming to Chrome. It is likely that other browsers will follow suit.
What you should do now
If you have a study ready to go that uses audio or video zones, check whether they are set to autoplay. If they are, you have two options:
research.sc. We will soon have a sample task that shows your participants how to do this.
If you are currently running a study that uses autoplaying audio or video zones, and you can finish your data collection before March 2018, then consider disabling Safari in your experiment Requirements and continuing with your current setup. If you cannot finish your data collection before March 2018, you will need to consider revising your protocol.
If you need help configuring your task to work with the new requirements, do get in touch with us via the Support Form
There is nothing that Gorilla can do to prevent or counteract this change in how browsers work. We plan to create a custom task that will provide participants with instructions on how to enable autoplay and only allow participants to proceed once this has been done.
In the latest release of Safari, autoplaying of audio and videos that contain an audio stream is blocked. Videos without an audio track will work as before. From now on, audio and video can only be played following a user action i.e. clicking on a play button, unless the user expressly changes their browser settings to allow autoplay on a specific site.
Chromium will be bringing this feature to Chrome in March 2018, following a beta release of the feature in January 2018. While it is yet unconfirmed, it is likely that the remaining browsers will follow suit. Chrome and Safari alone represent a considerable quantity of users.
For several years, Apple have prevented autoplaying (and even preloading in some cases) of audio and video elements on their tablet and mobile phones. This was primarily to protect users bandwidth/download limits. Adding autoplay blocking by default to desktop Safari brings the desktop in-line with other Apple products.
There has also been longstanding problems of loud, difficult to find and ultimately unwanted ads playing immediately on a page load or after a short delay. Preventing this behaviour is one of the most commonly discussed (and welcomed!) effects of this change discussed in articles online. Another important effect is preventing the autoplaying of distressing or disturbing videos that are sometimes distributed across the internet on websites and via social media.
These changes to mark a considerable improvement in the internet environment for most users.
However, there are many legitimate reasons why autoplaying of videos is desirable in behavioural science research.
There is nothing we can do to force autoplay to function as before. Disabling autoplay for media with an audio track is being authored by the organisations that develop and maintain the browsers themselves. We cannot subvert nor override this functionality. We can only work with the options given to us and abide by them.
We’re working on creating a small, customisable task which would act as pre-screening – it would detect if a participant has autoplay disabled and instruct them on how to enable it for the experiment.
We’ll improve the video and audio widgets to collect reaction times from when the media started playing.
We know that many of you use autoplaying audio and video and we appreciate the difficulty that these changes may cause you in deploying your experiments online. We will continue to monitor information on these changes as it becomes available from the browser developers, as well as explore new options for presenting audio/video stimuli that may allow you to use autoplay again.