I don't see keyboard navigation as being standard, and what seems to be standard isn't very good. Perhaps browsers should have an option to limit JavaScript's ability to override keystrokes used in navigation. I use Pentadactyl, a vi-like keyboard navigation plugin for Firefox, which doesn't seem to be plagued by this problem. I learned about it here on HN.
I would settle for a way to see mappings. Browsers already have to know what the mappings are in order to support them, they just don't share that information with users.
In a menu, all I have to do is read to find out what the keys are for each command. Much like each browser has a Back button, it'd be nice if all browsers could agree to provide a "legend" displaying the keystrokes that a web site has defined.
Of course, once the browser can display the mappings it can offer a more sophisticated way to disable them. For example, checkboxes for each key so you can keep the ones you like but get rid of the stupid ones.
> Browsers already have to know what the mappings are in order to support them, they just don't share that information with users.
Unfortunately the way this works in the DOM makes that undecidable. An arbitrary piece of JS code from the web page gets invoked for every keystroke, if the page code has added a handler for key events. If it has not called cancelDefault() on the event object by the time it returns, the browser takes the default action. The question of whether or not user JS code will invoke cancelDefault() for a given event is equivalent to the halting problem.
>I would settle for a way to see mappings. Browsers already have to know what the mappings are in order to support them, they just don't share that information with users.
It's not that simple- the onkeypress event fires every time a key is pressed. What the function handler actually does is non-deterministic. The web app would have to somehow declare its keyboard shortcuts.
