[menu] Menu.Item adding `data-highlighted` to items that are disabled can cause unintended effects on styling and behavior

[augusto-cesar-buildbox]

Bug report

Current behavior

The current behavior is adding the "data-highlighted" prop to menu items that are disabled. This causes some unintended behavior, such as the item's focus being directed to disabled items, and also affects the component's styling.

Expected behavior

When an item is disabled and you try to navigate to it using the keyboard, you should not focus on disabled items and also should not add the "data-highlighted" prop so as not to affect the styling.

Expected behavior

1. Go to the official shadcn website, select the Dropdown Menu component, and select the "Base UI" tab to indicate that you want to use the Base UI components. (https://ui.shadcn.com/docs/components/base/dropdown-menu)
2. Open the first example of the component with keyboard navigation.
3. Navigate through the menu items until you see one that is disabled called "API".
4. It will still be possible to focus on the navigation and add the unwanted prop.

Base UI version

v1.5.0

Which browser are you using?

Chrome

Which OS are you using?

Linux (CachyOS)

Additional context

menu-bug.mp4

[mj12albert]

It's intentional for disabled menu items to be focusable so screen readers are aware of their existence (many button-like components are like this)

For styling purposes you can additionally use [data-disabled] to distinguish them

[augusto-cesar-buildbox]

@mj12albert

Is there a way for me to disable this behavior? Is there something I can do so that disabled items don't receive focus?

[atomiks]

@augusto-cesar-buildbox what's the primary reason you want to do that?

We keep disabled items focusable in composite widgets for two reasons:

1. It's recommended in ARIA guidelines¹
2. Screen readers do not expect disabled items to be skipped in navigation. VoiceOver does not skip disabled items when it's active, so AT can see disabled items while navigating with arrow keys. While yes, they can use the virtual cursor to inspect skipped items, it's not the common path of interacting with the widget and doesn't match OS-level semantics. On the web, we can't detect screen readers, so we have to default to the safer option of always making items focusable when disabled.

---

The behavior exists in Chrome on macOS as well by default for its menus even when VO is disabled (though it's inconsistent across the OS).

---

[1] Explanation: #4666 (comment)

Disabled controls are usually removed from the tab sequence, but disabled items inside certain composite widgets should stay focusable during internal arrow-key navigation. APG explicitly lists these disabled composite items as focusable: listbox options, menu/menu bar items, tabs, and tree items. Source: APG: Focusability of disabled controls.

• Menu / menubar: disabled menuitems are focusable but cannot be activated. Use aria-disabled="true". Source: APG Menu and Menubar Pattern.
• Listbox / custom select: disabled options should remain reachable by listbox navigation, but not selectable/operable. Source: APG Listbox Pattern.
• Combobox with listbox popup: DOM focus usually stays on the combobox/input while AT focus moves among popup options via aria-activedescendant; disabled popup options can still be included in that navigation if following listbox guidance. Source: APG Combobox Pattern.