There doesn't seem to be any consideration for when multiple elements have the same assigned access key in a given document in its processing model.
Blink / WebKit seems to focus the last element with a given assigned access key, and Firefox focus the first such an element then allows the user to rotate the focus around like we do for normal focus navigation.
Firefox's behavior makes most sense, and we should probably be using the composed tree order here.
I think we should allow the user agent to either give some kind of list or trigger the Action of the first, in that case.
The specification does not currently require the values to be unique. Perhaps that needs updating too.
Also seems reasonable to ignore tree boundaries. Though if someone ever defines some kind of API on top of accesskey that would need careful auditing.
cc @whatwg/a11y
as much as i'm not a fan of accesskey and would not shed a tear if it actually disappeared altogether, i could imagine the first press of the key going to the first element in source order/tree hierarchy with that accesskey getting focus (similar to what happens with things like multiple elements with the same id and doing a document.getElementById). beyond that, it could be an idea that on pressing the same key again, the browser cycles to the next one in order? so something similar to a tab cycle?
This test case from a bunch of accesskey tests by chaals may be useful
Blink / WebKit seems to focus the last element with a given assigned access key
To be clear, it _activates_ the last element. Testcase:
<a accesskey="a" href="#1" onclick="console.log('click')">type accesskey "a"</a><br>
<a accesskey="a" href="#2" onclick="console.log('click')">type accesskey "a"</a>
Results:
Firefox: first link is focused, no click event fired
Chrome: second link is focused, fires a click event
Firefox' behavior is intentional, per:
https://searchfox.org/mozilla-central/rev/c61720a7d0c094d772059f9d6a7844eb7619f107/dom/events/EventStateManager.cpp#1047,1051-1060
(translation: "if more than one element matches the accesskey, then focus, otherwise activate")
We start matching from the currently focused element (non-inclusive):
https://searchfox.org/mozilla-central/rev/c61720a7d0c094d772059f9d6a7844eb7619f107/dom/events/EventStateManager.cpp#1016-1022
which results in the behavior that pressing the same key again cycles through the matching elements.
HTH
Most helpful comment
as much as i'm not a fan of
accesskeyand would not shed a tear if it actually disappeared altogether, i could imagine the first press of the key going to the first element in source order/tree hierarchy with thataccesskeygetting focus (similar to what happens with things like multiple elements with the sameidand doing adocument.getElementById). beyond that, it could be an idea that on pressing the same key again, the browser cycles to the next one in order? so something similar to a tab cycle?