First ask yourself this question: Why am I going to use web technologies for my game project?
If the answer is similar to this: "Because I like/am more productive coding in JavaScript" or "HTML+CSS save a lot of time doing the GUI", etc. Then, today there are ways to use those technologies to develop desktop/mobile apps.
For the desktop you have Electron and NW.js. Of all the advantages they offer, for your specific problem, you have to worry only for the audio/video formats they support. All users will be running the same runtime (the same "browser") when playing your game, no risk of your game page being loaded by an incompatible browser.
Development is handled in nearly the same way of any browser game. Compliant html/css/JavaScript will just work, you can even use js libraries like JQuery and they will just work. As a bonus, you can use the filesystem using apis not available in browsers.
Now, if it has to be a browser game, for whatever reason, then you will have to handle different browsers in the usual way, that is to provide multiple versions of each media file. This article comes to mind: http://diveintohtml5.info/video.html
The article is about video, but the strategy for audio is the same.
<audio id="electric_discharge_audio">
<source src="snd/electric_discharge.ogg" type="audio/ogg" />
<source src="snd/electric_discharge.aac" type="audio/mp4" /> <!--MSIE-->
</audio>
Or with JavaScript:
var audio = document.createElement("audio");
var source = document.createElement("source");
source.type = "audio/ogg";
source.src = "snd/electric_discharge.ogg";
audio.appendChild(source);
source = document.createElement("source");
source.type = "audio/mp4";
source.src = "snd/electric_discharge.aac";
audio.appendChild(source);
Game.Resources.Audio.ElectricDischarge = audio;
About "wav" files. Reasons to use that format for short sound effects in native games go from see no gain in storage save when encoding them to mp3/ogg/your_favorite_format, fear of audio artifacts in important game audio effects (bullet, magic, etc), prevent laggy decoding in slower machines (somehow more tolerable for the background music).
"It would be a shame if nobody played your game because instead of
downloading in 10 seconds, it took 2 minutes, of which 1 minute 50
seconds was downloading WAV files. It's like having all the images on
your website in BMP format. Nobody does that! So we really need a
compressed format." (from: https://www.scirra.com/blog/44/on-html5-audio-formats-aac-and-ogg)
The trick to prevent the quick sound effects to play with the wrong timing when using web technologies is not in using the WAV format. You can use ogg (or its replacement for each browser) for everything as long as you don't detect encoding artifacts (and if you do, then encode with a higher bitrate/quality setting).
The trick is in having the audio resource to preload during the game/level/area/map loading screen, and having it ready to play when the sound effect is needed.
This problem will be present either in true browsers as in platforms like Electron and NW.js. By design, when you set the src attribute of an audio element, controlling when the "browser" will start buffering it is tricky. Maybe one of the JavaScript game engines / media libraries that exists today may help here.
By my own experience, don't trust that the local storage will be faster than the network. This is not a local storage read speed problem, the browser will need to buffer certain amount of data before start playing, you probably don't need to care about this for the background music, but fast audio effects will probably make your game feel awkward and non professional, at least the first time each audio element is played. And having it already cached won't save you from this, you need to have, for all audio effects that will be used in the current scene, enough buffered data so the browser can start play immediately when you call audio_element.play(). For short audio resources, the expected is that they will be buffered in their entirety, but when using web technologies our control over this is limited.
Here a person is using a technique that consist in playing the audio for the first time with volume set to 0.00000001 (maybe just 0 works too). https://stackoverflow.com/questions/8375903/problems-preloading-audio-in-javascript
I think that is only acceptable for small sound effects. As I said, just let the background music start at any time. In cases where you want to change background music quickly without weird timings, but at the same time prevent a very large audio file to silently play to the end in the background, then you can use the canplaythrough event to stop it as soon as it has enough data buffered.
About very old IE versions (prior to 11): do as most game developers do with non NVidia/AMD/[Intel] GPUs (at least for the desktop). Pretend they don't exist.
So, if going for the multi browser support, you need to care only for Microsoft Edge and Microsoft Internet Explorer 11 and I'm not very sure about IE 11.
I think Edge won't give us troubles here: https://blogs.windows.com/msedgedev/2016/04/18/webm-vp9-and-opus-support-in-microsoft-edge/#0SgrdYfAKrdXOpaY.97
Web Audio API: If you decide to ignore IE completely, you can safely use it. I still have to test in Edge (feel free to edit this answer if you have done it already), but I guess it won't give us troubles with this.
