For Chromium based browsers you can use getLayoutMap() instead of prompting the user and then rely on the manual fallback for Safari/Firefox/Other unsupported browsers. In either case, detecting/asking for the layout makes sense for displaying the controls graphics but you should still ultimately use the keycodes for positional keys in the actual code so someone on the misdetected or on an unlisted layout can still use the positional keys as expected.
This API doesn't know what my keyboard layout is, and there's no way it possibly could; it's in the keyboard's firmware, not software.
Better than a fallible API that didn't exist when this was made, or a way-too-limited layout choice, would be to make it work well with arrow keys and mouse (arrows already do the basic movement), or to make the 6-key instruction screen configurable.
Adding configurability is a good additional option (even outside the layout detection) but because people like different layouts not because a few HN style folks break OS detection via custom firmware. It's certainly not a reasonable cause to redesign your control scheme around the limitation either. Something of 10%+ of internet users don't use qwerty, something of 0.01% set their layout via the keyboard's firmware.
Good note on the game being released ~2015 though, the API wasn't added until ~2018.
