[combobox] Combobox keyboard navigation not working while NVDA screen reader is active

[StefanDejanovskiOcuco]

Bug report

Current behavior

When using a multiple select combobox with chips, keyboard navigation fails when a screen reader is active:

• Pressing the left arrow key while focused on the input moves focus to the last chip
• Pressing the right arrow key from a chip keeps focus on the chip instead of returning to the input field

This issue only occurs with screen readers enabled.

Expected behavior

Arrow keys should provide consistent bidirectional navigation between chips and the input field, allowing users to:

• Move left from the input to navigate through chips
• Move right from chips to return focus to the input
• Navigate seamlessly without getting stuck on any element

This navigation pattern works correctly when screen readers are disabled.

Reproducible example

Combobox example
Copied from https://base-ui.com/react/components/combobox#multiple-select

Base UI version

"@base-ui/react": "^1.0.0"

Which browser are you using?

Chrome

Which OS are you using?

Windows

Which assistive tech are you using (if applicable)?

NVDA

Additional context

The issue appears to be related to screen reader mode switching. NVDA may be conflicting between browse mode and focus mode when navigating between the interactive elements, causing the unexpected keyboard behavior.

[atomiks]

Thanks for the report - does adding role="button" to <Combobox.Chip> resolve it?

[StefanDejanovskiOcuco]

Doesn't work, even if I add tabIndex={0} still gets stuck

[atomiks]

I'm curious if Material UI's Autocomplete chips also have this issue with NVDA if you can confirm? We use the same pattern (real DOM focus goes on the chips).

This seems to be an NVDA-specific “browse mode vs focus mode” issue, as it works correctly with VoiceOver.

---

Another potential fix: role="toolbar" on <Combobox.Chips> container (+ keeping role="button" on <Combobox.Chip>)? After reading, it seems like NVDA expects an ARIA composite/widget role for arrow keys not to be "swallowed". This could also be technically more correct, anyway.

[StefanDejanovskiOcuco]

TBF, VoiceOver does work.

Yes, the issue is present in Material UI's Autocomplete.

There are certainly some workarounds, like applying role="application" to the whole component, which enforces focus mode.
The role="toolbar" will also work but doesn't seem appropriate here: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/toolbar_role#descri%E2%80%A6 → Only use the toolbar role to group 3 or more controls.

Yes Exactly, I'm curious though: why the decision to make the input have the role="combobox"? Why not treat the whole thing as a combobox and have the input have a role="textbox" or "searchbox"?

[atomiks]

The role="toolbar" will also work but doesn't seem appropriate here: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/toolbar_role#descri%E2%80%A6 → Only use the toolbar role to group 3 or more controls.

In my view this is more of a useful guideline, not a hard/strict rule, especially for more bespoke widgets like this combobox one. No behavior is broken (quite the contrary when using NVDA!) when this role is added as keyboard navigation/looping/semantics remain in tact (it acts like a toolbar). Home/End functionality is currently missing, but those are listed as optional.