The point of this reminder is to alert people that most preexisting content will break regardless of whether it waits for user input.
That is, even content that only plays sounds when a button is pressed will, in general, break, unless it happens to also call `context.resume` in the same event handler (which content predating this policy generally had no reason to do).
I'll add a note to the post to make this clearer...
Ringtones/notification sounds for a communication app.
User is (almost always) logged in from previous session, just opens tab and (because he was never before asked to do anything else) opens another tab with facebook/jira/news/whatever.
It's small-ish UX breakage in niche use case, but it is still valid and will cause our app problems (dev time and worse UX).
(btw NO permission system for this is available or even planned when you look at the chromium bug tracker)
> An AudioContext is said to be allowed to start if the user agent and the system allow audio output in the current context. In other words, if the AudioContext control thread state is allowed to transition from suspended to running.
> Note: For example, a user agent could require that an AudioContext control thread state change to running is triggered by user activation (as described in [HTML]).
This means the user agent (the browser) is allowed to choose when the AudioContext can be used. It's up to Chrome to determine when playing audio is allowed.
I can't think of an example where auto playing audio without user interaction is a good idea anyway. This was explicitly warned for in the moving standard since at least late 2016(http://web.archive.org/web/20161031141656/https://webaudio.g...).