If browser have standard native shortcuts that can clash with access keys (and lets web-pages' HTML access keys take the priority), then there is something stra

If browser have standard native shortcuts that can clash with access keys (and lets web-pages' HTML access keys take the priority), then there is something strange going on in the browser. (Yes, I know, there really is something strange going on some browsers, cough, Chrome, cough.) But the whole point of this concept is that entire key palette in certain modifier key combination has to be left unclaimed by the browser. As simple as that. Firefox on Windows uses Alt + [letter] for its native shortcuts, and leaves Alt + Shift + [letter] in scope of focused content page exclusively for access keys. Chrome (and Edge) for some wicked reason let both its own and HTML web contents' access keys share the sole Alt + [letter], but in case of conflict let you still use Alt + Shift + [letter] for access key, but then defines some own commands bound to Alt + Shift + [letter]. So the result is, as we may confirm in the OP's page, that: - for accesskey="e" in Chrome we MUST use Alt + Shift + E, since Alt + E opens the main menu, - for accesskey="i" in Chrome we must NOT use Alt + Shift + I, since it opens some "Send Feedback to <browser vendor>" popup. This is indeed laughably unfortunate, but not the flaw of the standard mechanism itself, so web-page authors are not to be blamed for it. Situation around keyboard shortcuts done with JavaScript is completely different, and several orders of magnitude wilder topic with even more unresolved peculiarities. And I think these are those "hijacks" you are referring to.