How to reset previous focus when moving away from Menu

[bengry]

I'm using a <Menubar> and <MenuItem> to implement a side-navigation, and seeing some behavior I can't find a way to disable - when Tab-ing away from the menubar and going back, the focus is kept on the last focused item.
Is there a way to disable this behavior?

This is best explained by this short video:

CleanShot.2024-03-27.at.20.14.40.mp4

Stackblitz reproduction

I'd like to have the focus on "About" when I tab back from header focusable element, not on Blog, which was the last focused item.

As a side question, is <Menubar> (and <MenuItem>) the best way to approach this layout the way I have it in the Stackblitz?

Lastly, what's the purpose of the <MenuProvider> here? Is it required?

[diegohaz]

I don't think you should use Menubar for that type of navigation. See Can I use Menubar for site navigation?.

Simply use good old semantic HTML:

<nav>
  <ul>
    <li><a href="/about">About</a></li>
    <li><a href="/contact">Contact</a></li>
    <li><a href="/blog">Blog</a></li>
    ...
  </ul>
</nav>

[bengry]

But then the user has the tab all the way through the menu items just to reach the header, instead of giving them the option to navigate within the menubar using the arrow keys, yet tab straight away to the header using Tab. Is that not better?

[diegohaz]

It's better to keep navigation links tabbable. You can use Skip Navigation Links to allow keyboard users to skip to the main content.

[bengry]

Thanks, I appreciate the help with your knowledge of aria concerns. I'll change it to a regular <ul>/<li>.

Just for my own curiosity's sake - is the behavior I asked about disable-able? I noticed it also exists in Tabs (and probably other components in Ariakit).

[diegohaz]

That's typically how composite widgets like menubar and tablist work. Though you can reset the activeId state on blur if necessary:

const store = useMenubarStore();

<Menubar
  store={store}
  onBlur={(event) => {
    // ignore blur events inside the menubar
    if (event.currentTarget.contains(event.relatedTarget)) return;
    // reset the active item id
    store.setActiveId(undefined);
  }}

[bengry]

Thanks, that works great.

What about:

Lastly, what's the purpose of the here? Is it required?

And on a bit of an off-topic, but might be helpful to others - would your recommendation still hold true if these top-level items would open or be related to a drawer of nested items? e.g.

i.e. the About/Contact/Store/Solutions do a navigation, but also have a related element of sub-pages. In the picture - the Store item has sub-sections you can navigate to.

(I updated the Stackblitz, in case you want to take a look at the rough layout, although the CSS there is hacky, just to quickly get an example up).

[diegohaz]

Lastly, what's the purpose of the <MenuProvider> here? Is it required?

It's for submenus (if you're using them). Each submenu controls its own state, which is provided by the MenuProvider component. See Anatomy of nested menus. If you're using Menubar without submenus, you don't need it because Menubar already provides the state for its items.

And on a bit of an off-topic, but might be helpful to others - would your recommendation still hold true if these top-level items would open or be related to a drawer of nested items?

i.e. the About/Contact/Store/Solutions do a navigation, but also have a related element of sub-pages. In the picture - the Store item has sub-sections you can navigate to.

It depends, how does the user open the drawer?

[bengry]

It's for submenus (if you're using them). Each submenu controls its own state, which is provided by the MenuProvider component. See Anatomy of nested menus. If you're using Menubar without submenus, you don't need it because Menubar already provides the state for its items.

That makes sense, thanks.

It depends, how does the user open the drawer?

The drawer can be either pinned or not (using the Close/Open drawer button I have pictured).
If it's not pinned - hovering the top-level items (e.g. Store) will slide it into view, and pointer-out will slide it out of view.

There's of course also the challenge of what to do for keyboard navigation - I suppose that in that case, while there's tab-focus on one of the items - the drawer will be open (it's contents change based on the hovered item).
But again, I'm open to suggestions on a better behavior.

[diegohaz]

The drawer can be either pinned or not (using the Close/Open drawer button I have pictured). If it's not pinned - hovering the top-level items (e.g. Store) will slide it into view, and pointer-out will slide it out of view.

There's of course also the challenge of what to do for keyboard navigation - I suppose that in that case, while there's tab-focus on one of the items - the drawer will be open (it's contents change based on the hovered item). But again, I'm open to suggestions on a better behavior.

In that case, yes, I'd still suggest using a standard HTML navigation. For the drawer, you can use Hovercard triggered by onFocusVisible and a custom position:

function TopLevelLink() {
  const [open, setOpen] = useState(false);
  
  return (
    <HovercardProvider open={open} setOpen={setOpen}>
      <HovercardAnchor href="/store" onFocusVisible={() => setOpen(true)}>
        Store
      </HovercardAnchor>
      <Hovercard
        portal
        // disable the popover position
        updatePosition={() => {}}
      >
        ...