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.
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:
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.
UPDATE JUNE 2020 Gorilla now has a Web Audio zone, a replacement for the original Audio zone. The Web Audio zone makes use of the Web Audio API, which is one of the most modern infrastructures for playing audio natively in the browser. As well as providing improved support for different audio types and reduced onset latency, the Web Audio API allows us to use another javascript audio library to significantly reduce the affect of Autoplay restrictions. When using Web Audio zones, provided you have at least one clickable button in your current task, prior to the first Audio being autoplayed, you should experience far fewer issues with Autoplay being blocked on a participants device. While we still advocate using manually played audio where-ever possible, use of the Web Audio zone is strongly advised for situations where autoplaying of audio is paramount!
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.
Options now:
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. UPDATE JUNE 2020 Ultimately, the circumstances in which autoplay would or would-not be triggered proved to be too tempremental and unpredictable to generate a reliable task for testing. Further, the mechanisms for detecting whether playing of audio/video had failed are not implemented consistently across browsers and devices!
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.