Since the recent update to 2.8.0.beta2, the button to the admin menu is highlighted in yellow.
I thought that Discourse wanted to tell me something, but even after searching the web and this forum, I have no clue what that could be.
Can someone please enlighten me?
I think it’s telling you that the keyboard focus is on that item. This was a recent accessibility change:
After you’ve displayed the menu, try pressing Tab to move through the menu.
Yes, correct, as @simonk noted one way we were messing up is by not changing focus to overlays. The focus has to be in a sensible place as you navigate around the application.
So it is considered to be “working as intended” when I see this (mouse hovering over “Badges”)?
Hmm, not sure; do we need a hover state there @awesomerobot ?
I think we might want to switch from :focus to :focus-visible in our CSS. It’s not supported on Safari yet, but it’s easy to fallback on :focus in that case.
If the active element matches :focus-visible, and a script causes focus to move elsewhere, the newly focused element should match :focus-visible.
So that means if you open the hamburger menu by tabbing to it (which enables the :focus-visible style), when the menu is opened, the :focus-visible style appears. If you open the menu with a pointer, then the :focus-visible style does not appear:
There is one downside, in a mixed input scenario where you open the hamburger with a pointer and then attempt to tab nav… the :focus-visible style isn’t visible on the first link (even though it’s technically focused), so it looks like it gets skipped. Not sure if there’s a workaround for this…
Since I’m (mostly) a mouse-user, that’s exactly what I would expect it to behave.
On the other hand, sometimes I’m using my smartphone with touchscreen: Same problem there, Admin is highlighted, indicating that there might be something important in the admin section that needs attention.
From the related screenreader topic I see that there seems to be a need for setting the focus somehow.
I would already be happy with the behaviour mentioned above for pointers.
I have the same issue.
I don’t think this element currently has the UX value you folks intended – we instantly got bug reports about this from our forum. The focus disappears when you right click anywhere in the window and there’s a double focus when hovering over buttons. Overall it appears buggy to users, especially because Discourse doesn’t force this selection on any other views.
It would be better to only show the keyboard focus when the user first presses Tab, or only when the user navigated to open the hamburger menu with a keyboard action.
can you post a screenshot of this? not aware of this one
This is on latest version of Chrome
I see the same in Safari and Firefox, (macOS) this is also referenced in the post above:
If I’m understanding this feature correctly, I should be able to open that menu by clicking or pressing = and then navigate with something (arrow keys?) and press something (enter?) to navigate to the highlighted item.
In Safari and Firefox on macOS, whether I open that menu with a click or =, I can’t seem to navigate within that menu. Up/down arrow keys move the page up and down, left/right arrow keys don’t visibly do anything.
Tab switches focus to something else, such as a like button on a post, and removes the yellow highlight from the menu. Tabbing in Firefox did cycle through the menu items before I started writing this reply but now doesn’t, a private window was closed between those attempts.
I see these behaviours here on meta and on my own instance updated to efbc2481d8 (except Firefox tabbing successfully, which I only saw here)
The arrow keys shouldn’t do anything, but tab and enter should!
So when you open the menu with = and press tab you’re not cycling through the menu items? I’m on macOS and it works as expected in Safari, Firefox, and Chrome so this is a little perplexing!
I took a closer look at what’s going on here generally and the idea of using focus-visible I mentioned above won’t work.
The problem is that the hamburger menu appears in our HTML outside of the menu button container (the container holding search, hamburger, and user buttons). So this means the menu isn’t next in the natural tab order. To compensate we set focus on the first menu item using javascript. This has the side-effect of highlighting the item (because we also need to have :focus styles).
I don’t think we can necessarily rely on detecting a tab press because it’s not the only key screen readers use to navigate, and we’d interfere with other shortcuts if we captured all key presses…
I can think of two possible fixes:
Move the menu in the HTML so it appears immediately after the button that triggers it. This may have some layout side effects.
Trap the focus within the menu when it’s open, but don’t set the focus on any particular item. This means when the menu is open, you can only tab its contents and nothing else on the page. I think this is probably the preferable solution…
Correct. For the sake of additional specificity, this is macOS 11.4 and Safari 14.1.1. I’m viewing meta in a private window and my own instance in a not-private window.
I must have botched my initial testing of Firefox, that works in the way you describe if the system preference for Use keyboard navigation to move focus between controls is enabled and tabs to a like button in the way I described previously if it is disabled.
I can reliably switch between behaviours by toggling that system preference without needing to reload the page in Firefox.
In Safari, I’m seeing it tab to a like button regardless of that system preference, even after reloading the page. I have not yet tested restarting Safari after enabling it.
I have now looked at Chrome as well, that works in the way you describe regardless of the system preference.
I’ve found the cause for my problem in Safari. I noticed that unlike Chrome and Firefox, if I clicked somewhere in the header bar and pressed tab, it would not select any of the elements in the header.
This led to the discovery of this preference in Safari under Advanced:
I’m 99% sure that’s the default with a fresh install of Big Sur, I don’t believe I would have changed that. With that preference turned on, it starts working the way you describe. As the text above suggests, it also works that way when using Option-Tab with the preference off.