Using accesskey attribute in HTML forms and links (2006)
jkorpela.fi
jkorpela.fi
The MDN page about accesskeys has useful information, including a table of the modifier keys used in different OS+browser combinations.
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
Keyboard accessibility on the web is fraught and overdue for more attention from standards committees IMO. It's another thing pushing people toward Electron instead of sticking with standard web platform. Relying on modifier keys has too much risk of colliding with browser or OS behavior.
The most sophisticated approaches I've seen opt for a modifier-less multi-key "chord" approach, e.g. GMail/Fastmail web UIs.
(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.
But nobody knew what cool stuff it could do unless they digged up a webpage from 2006.
That's the modern web browser.
The lack of discoverability in modern UI design is reaching utterly ridiculous levels. And I firmly believe the lack of main menus and statusbars is to blame.
Look at how ridiculous this is https://developer.mozilla.org/en-US/docs/Web/CSS/Alternative...
Firefox used to have this in its main menu. You could stumble across it. Now nobody knows it even exists and they think light/dark themes are a real alternative to the full spectrum of colors and designs we could have before (if only webmasters implemented it, which they never did (but anyways I blame browsers for this because very few people even knew they could add alternative stylesheets to their own websites and users had no notification that they could switch rendering the incredible feature pretty much useless all the time)). Then browsers look at their metrics and how nobody is using the feature they told nobody about and decide to stop supporting it because why would they support a feature nobody uses, right?
Reddit had entire subdomains to do what Firefox could do with a single click in the main menu.
There could be a key that if I press it Chrome sends me to the search box at the bottom of this page, and I will never know about it because when I click the search box there isn't a status bar unintrusively hinting to me "hey, heads up, you can press Ctrl+Alt+Shift+S to quickly go to this box ;)" and I don't think we'll ever get that back.
Alternative Style Sheets are cool but the idea needs to be taken further In Firefox, if you browse full one page to another on the same site with the same sheets available, it still switches to the new page's default sheet. Imagine if sites could have a persistent theme picker using a browser UI!
Every single application used to follow it.
Alt+V, Y