Click sounds for feedback on buttons

On Android in native apps there are click sounds practically every time you click a button in native apps. This feedback helps you know that the thing you clicked is a button and that an action will be performed. I’m not sure if iOS has similar sounds or not.

It would be nice to be able to have click sounds on the web for the same feedback reasons. You can of course play sounds but it would not be easy to match the click sounds that the host OS provides.

I don’t have a proposal on what such an API should look like. I can see HTML attributes working, or perhaps a lower-level JavaScript API.

This seems to me like it is a UA/OS feature, I’m not sure there would/should be an API for it beyond the ones that would allow you to create something that was just custom and the same across the board?

Do any UAs provide these sounds?

Of the ones that do not, what is the reason for not doing so?

iOS does not have clock sounds for anything tappable, except, optionally, the keyboard.

@othermaciej Thank you. Are there any other types of feedback that iOS has for buttons in native applications, for example vibrations?

No. Haptics are mostly reserved to the “deep press” gesture.

As far as Android goes, browser engines generally already have enough info to know what is a button so they could choose to respect the Android click sound setting if they wanted to. I don’t think a specification is needed to make it happen.

Yeah perhaps not, right now I’m trying to figure out if there is commonality between platforms or not. If not then I agree it becomes a browser feature request.

/cc @Peter_Beverloo

To me this is squarely a UA decision/issue, not something that needs to be codified in any kind of standard. And if an author wants to provide some form of custom sound effects, they can/should code it themselves (same way we also had to do the same in, say, Flash or whatever back in the day).

Just to clarify, this issue is about standard system sounds, not custom sounds.

Just noted that a bunch of my words were in a direct reply to Matthew so missing from my reply above. As I said, it seems like there is nothing to spec here, UA/OS integration can do it… In fact, it seems ‘easy’ – However: I do believe that if anyone wanted to do this, it would probably require some UX research. It seems unlikely to me that only <button> should participate in this as it would almost certainly create much confusion for end-users as the web has a plethora of things that at east some end-users recognize as a button but are not - so you’d have to find a sweet spot somehow.

That said, I personally do wish that android (off topic for this a bit I guess) would try to figure this out because I have noted it too - when the whole OS ‘clicks’ but your installed PWA (to a user, there isn’t a differene) does not, it feels …“wrong”.

Seems to be the conclusion here that there isn’t a cross-platform thing here to specify, I can accept that.

@briankardell What other things should participate? I would think <button>, role="button" and <label> make sense.

Not sure I understand why you say <label> makes sense, but I would assume <a href=""> links would have to be a part of it or it would wind up really confusing users since too much of the web is <a href="" class="btn"> variants… idk, like I say it would probably require UX research for the platform and it’s probably not (at least for the forseeable future) a standardizable thing, so kind of off topic for here. Happy to reflect any of that a specific browser issue or you can feel free to…

I disagree here, that’s an argument to never make improvements at all. Should we not have focus rings on buttons because it doesn’t work on div buttons? The current state is an inconsistent experience so making an improvement to properly built sites doesn’t create new inconsistent experience. It’s a net improvement.

Here’s a chromium bug for those interested: https://bugs.chromium.org/p/chromium/issues/detail?id=1105226

Android apparently provides 2 simple ways to invoke a few system sounds. https://developer.android.com/reference/kotlin/android/view/View#playsoundeffect https://developer.android.com/reference/kotlin/android/media/AudioManager#playsoundeffect

Example: webview.playSoundEffect(SoundEffectConstants.NAVIGATION_UP)

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.

Browser inference: 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.