This is unlikely to be caused by responsive monobook, as no changes were made to any of the access keys. The entire cactions block is hidden in mobile when js is enabled, but this includes edit etc, so if edit etc still work, that's not it either.
I've changed the title to clarify exactly when the access keys aren't working, per the comments I just made about this issue at the village pump discussion. On the prototype, I can reproduce this issue in both JAWS and NVDA, the two most popular Windows screen readers, in both IE and Firefox (using the latest stable versions of all these programs)
Probably what would fix this is visually hiding specific menus instead of hiding them entirely with display:none;. I would guess that they don’t work exactly by that logic: if they aren’t displayed in browser, they aren’t actionable. However the edit button working is definitely strange and can’t be described by this.
Yeah, the clarification says it is the display:none after all. There's actually a mixin in monobook's variables.less already for hidifying things properly that we can use, so the fix is really easy here.
@Graham87 You can test this change now on the Beta Cluster (https://en.wikipedia.beta.wmflabs.org/). Please let us know if it works well for you, and if it does, I will get it deployed to the production Wikimedia wikis soon as well (otherwise it would have to wait until the scheduled deployments next week).
Exactly. However, I don't know precisely how that'd work without causing other side effects, seeing as as far as I know there's no non-invasive way to detect the presence of a screen reader. I do appreciate the new preference to turn it off universally though.
An aria-hidden="true" smacked on any new redundant things should resolve that for screen readers.
As a side note, this produces a very weird experience for non-screenreader keyboard navigation, as the now-invisible links can get focus now when tabbing (try e.g. clicking the search box, then pressing Tab a couple times).
You might want to make the menus appear when they get focused (either with JS, or with :focus-within pseudoclass, I'm not sure which will be easier). But that's a corner-case (these styles are meant for devices with no keyboards, after all) so I'm merging this as-is.
Not sure how to resolve this issue for people on tiny screens, though.