“We’re doing this to give Web Audio API developers (e.g. gaming, audio applications, some RTC features) more time to update their code. The team here is working hard to improve things for users and developers, but in this case we didn’t do a good job of communicating the impact of the new autoplay policy to developers using the Web Audio API,” Pallet wrote.
“The policy will be re-applied to the Web Audio API in Chrome 70 (October). Developers should update their code based on the recommendations at: ^( .”
The reaction to the rollback is generally positive, but the same can’t be said about the plan to bring it back. Bennett Foddy, a vocal critic of the change, said in a response that it was “definitely the decent thing to do in the short term” but that it fails to address the fact that most of the online content impacted by the policy will not be updated, “and so we still face the effective cultural erasure of those works in October.”
“You guys definitely have the power to break everyone’s work, should you wish to exercise that power, but you do not have the power to make people add workarounds to code that they are not able to alter (for all the various reasons that have been given here). Nobody has that power,” Foddy wrote. “If you are sincere in your claim that the side effects of the policy were unintended and unwanted, you should commit—in clear, straightforward language—to finding other alternatives which do not break vast swathes of cultural work that was developed and distributed on the open web.”
Other comments call for a response from the Chrome development team, particularly with regard to suggestions for modifying the policy to indicate when audio is being disabled, and to enable users to easily switch it back on, either temporarily or permanently. One user also says that the reversion only partially addresses the problem: “Because the rollback was not applied to