Why allow focus only, why not require activation?

[minorninth]

The spec says that when a user presses the access key, the user agent must focus the target element, but it may trigger the action of the command.

Why?

If user agents are allowed to not trigger the action of the command, then authors can't rely on accesskey as a replacement for existing shortcuts that trigger actions. That will result in authors sticking with JavaScript key handlers rather than switching to accesskey.

I propose that we require user agents to trigger the action of the command if accesskey is placed on an activatable element. That will make it more useful to authors and encourage its adoption.

[chaals]

I think we should generally recommend it, for the reason you suggest. But there are a couple of reasons not to require it always:

1. Where there is a duplicate accesskey - i.e. two or more things in the page with the same value, cycling among them is a pretty helpful behaviour (IE does this)
2. For some users, being able to find out where they are going is important.

I'd actually like to see implementations provide a mode where they continually accept accesskeys until the mode is turned off - which enable game-like controls without all the drawbacks of them being in javascript.

So I think we should be setting expectations of common implementation strategies, and explaining why other patterns might be used.

As another implementation point, it would be nice to allow the user to set the accesskey accelerator. Many browsers on mac use ctrl-alt by default, which means they run into a conflict with VoiceOver. VoiceOver always wins the conflict, so users are not surprised, but again this is a disincentive for authors. If VoiceOver could automatically move the accelerator to some other key or combo, everyone would win…

[chaals]

I updated the draft, so that commands (is the concept still defined?) should be activated if a shortcut is unique.