That's an extremely simplistic look at the problem. The issue isn't looking at the keyboard, it's the extra mental effort of doing the keymapping every time you run into a new application which has stupid defaults that don't take alternative layouts into account.
That is true. Wouldn't mapping specific keys (physical, on the keyboard) to actions/events better than mapping actions to the characters pressed? I thought that was how things worked now.
Nobody using Dvorak will want WASD as movement controls for a game for example, but they will most likely want to use the same keys, right?
The problem is, only the keyboard hardware knows where the keys are physically located. The OS knows the layout and could probably expose the QWERTY-equivalent keys, which would be sufficient for not-too-exotic keyboards, but I don't know if that is available to applications in a way that is sufficiently portable for browsers to expose it.
Chromium seems to expose this to Pepper plugins; here is the bug for making it an experimental js api: https://code.google.com/p/chromium/issues/detail?id=119362
Getting the lowlevel keycode is nonportable (I didn't find the implementation, but found switch cases and fallbacks if it doesn't exist). Conversion to a portable usb-hid-equivalent keycode is left as a stub in the patch that introduced the Pepper feature.
