If I can't play a sound, just make it browser feature -- let the web page call the APIs continue as normal, mute the tab, and browser notifies the user.
Instead, responsibility is pushed from the browser developers (small in number) every single web page developer to deal with rejections, prompt users, retry the request, and cover a bunch of edge cases that mostly they'll never see.
The policy ends up frozen in time around the needs of eg. 'desktop' and won't be able to adapt in future.
Also, the inevitible concern around fingerprinting a user based on the pattern or timing of rejected events.
Not sure about WebAudio spec specifically, but there are certainly places where media specs are basically just a reflection of "what Safari does" to work its way around corners its boxed itself into.
For example, I have built a few music visualizers and have had to run a local youtube-dl server that disables cors, just to be able to visualize music for a youtube video. I just want to draw patterns on my screen while some music plays, I'd even be fine with the ads! But I have to engage in some form of piracy to do this.
The music is already playing through my speakers, so I should be able to access that data!
(edit: I want to clarify: I know that one can set cors options on audio elements to enable cross-origins references, but it requires the server to allow you to -- which is what I'm doing with the youtube-dl server. That is the real problem: CORS is being used by youtube for copyright protection, not for user-safety. I know that accessing a youtube video across origins from a page I wrote myself is safe, but CORS enables youtube to stop me from accessing that data, in the name of safety.)
Those things should already require authorization to access their streams, and your creds for e.g. meet.google.com shouldn't be available in other tabs/windows at other domains to send along, but it still would likely be reasonable to default to preventing access to/from domains unless they are marked as safe, in much the same way accesses are already requested/allowed.
I acknowledge that a feature like that would take real work to write and support and keep secure, but control over access to data should be the user's choice, not the server's.
Does that work in practice? You can 'expect' all you want if they don't choose to implement it.
- try not to obtain and initialize the audio context until the triggering event has occurred
- make sure the audio context + playback occurs directly as a result of the triggering event. If the event just sets some state, and then something else is periodically watching for that state to change, it may fail. A workaround here is to just mute+play some sound on that first tap, then you're good for any later Audio contexts created+initiated however you'd like.
As a mobile first web developer, ios is the thing that's really holding us back.
The very frustrating thing about this is that the end user tends to blame the app, and there's not a good way to communicate to them "hey, we would totally do this, but mobile Safari has limited functionality and Apple won't allow other browsers to be installed"