Android apparently provides 2 simple ways to invoke a few system sounds. https://developer.android.com/reference/kotlin/android/view/View#playsoundeffect
The 2 proposed solutions for system sounds without defining a web standard for invoking them both have significant flaws which prevent them from providing the ideal user experience.
Browsers may be able to provide the appropriate effects for some cases, such as clicks on DOM buttons, but there are many cases where that would not be practical.
Many different DOM components are implemented by sites due to lack of suitable native primitives. Browsers would have a difficult time understanding the mechanics of such components and how to apply system sounds to them. Not applying sounds to every appropriate interaction would result in the poor user experience of sounds for some interactions but not others without a rational distinction to users.
Due to reasons such as the use of a game engine, needing greater flexibility than provided by the DOM, or the implementation of a different UI system for use in web browsers (ex Flutter), canvas would be used to implement some UIs. It would be practically impossible for browsers to infer the functionality of canvas based UIs, leaving them without the possibility of using system sounds.
Site reimplementation: Sites could implement sounds for interactions without additional help from browsers, but doing so would have several problems.
Sites do not know the user’s system sounds settings, so would need to provide users with a sounds option for each site they use. In many instances the initial sound experience would not match the user’s preferences.
Unless a desired part of the experience, such as in a game, having interaction sounds for sites be different to each other and to the operating system is a jarring user experience. For example, try Kodi on Android TV. Different operating systems and maybe even different versions have significantly different system sounds. In order to match the native sounds, sites would need to actively maintain audio matching a wide variety of operating systems, versions, and flavors, with the probable result of only matching sounds on very popular operating systems.
As such, providing the ideal user experience of system sounds would necessitate browsers providing a API to manually invoke them.