List of steps to reproduce (step by step, including full links if applicable):
What happens?:
The watchlist button gains focus and a blue outline.
What should have happened instead?:
The browser should navigate to the watchlist.
Browser: Firefox 101.0.1
Access keys have never worked for me on Firefox (Mac OS). I can confirm however I do see a focus state in Vector 2022.
@Rummskartoffel does this access key work for you on legacy Vector? Are you seeing inconsistent behaviour?
@TheDJ any idea what might be happening here?
Per T291671#7900951 I don't think this is an accessibility problem, but please correct me by re-tagging if I'm wrong.
Yes, this accesskey works on Vector 2010, i.e., it navigates to the watchlist; it also works the same way on Monobook and Timeless.
@Jdlrobson Access key on macOS in legacy Vector works for me. It follows the link. In Vector 2022 the link is only focussed.
@Volker_E it work for you on Firefox? How do I do that? For me the ctrl+option L does nothing in legacy but works fine in Chrome.
The reason it only focuses is that there are three elements with the same accesskey on the page, as evidenced by doing $( '[accesskey=l]' ); in the browser console: One is the button that is visible at the top of the page, while the two others are present, but always hidden (presumably because there is a button). The second one is within the p-personal menu (the one in the header), while the third one is within p-personal-sticky-header (the one in the sticky header).
The behaviour in Firefox when there are several elements with the same accesskey is to focus them and toggle between them when the accesskey is pressed again. Here the toggling doesn't happen because two of them are hidden, but the behaviour of only focusing and not navigating remains. In contrast, the behaviour in Chrome seems to be to ignore all the extra elements with the same accesskey and only care about the first one.
The solution is simple: Just don't add the accesskey attributes to the two hidden links in the headers. (Or even remove it later with something like $( '[accesskey=l]:not(:first)' ).removeAttr( 'accesskey' );.)
Just don't add the accesskey attributes to the two hidden links in the headers.
I agree with the approach here if we do decide to fix this (although with a big caveat that we need to make sure hidden elements with accesskeys still work - we had issues with that in the past).
The solution is simple:
Simple in concept but not implementation! We'll need to refactor skin menu code to make it easier to extract menu items without the accesskey (right now all menu items are presented to the skin as a LI block of raw HTML with the access key included). See html-items key in https://skins-demo.wmflabs.org/w/index.php?useskin=skinjson for example.
BTW, this is most noticeable with the watchlist (because that's the most used one, I suppose), but it also happens for the other accesskeys in the personal tools menu: . for going to your userpage, n for your user talk, and y for your contributions page, Not very surprising, but good to keep in mind nonetheless.
+1. I hardly ever use other shortcuts than for watchlist. I'd appreciate a fix, although I understand it can be challenging from an engineering perspective.