Capítulo 46 de 51
A roving-tabindex container for mixed control types (buttons, links, an input, grouped sub-sections) sharing one Tab stop with arrow-key movement between controls — the key usage constraint is that arrow keys are overloaded for both toolbar navigation and (inside an Input) text-cursor movement.
Toolbar.Input, use at most one, and place it as the last element — otherwise arrow-key navigation and text editing conflict.Root → Button, Link, Separator, Group (→ nested Buttons), Input.Button, Link, Input) under the same single-Tab-stop + arrow-key model.Group: visually/semantically clusters related buttons (e.g. a formatting sub-group) within the toolbar without breaking the shared roving-tabindex sequence.focusableWhenDisabled: on Button/Input, keeps a disabled control focusable (and thus part of the arrow-key sequence and screen-reader-discoverable) instead of removing it from the tab order entirely — important so users can discover why something is disabled instead of it silently vanishing from navigation.| Part | Notable props | Notable data attributes |
|---|---|---|
Root | loopFocus, orientation, disabled | data-orientation, data-disabled |
Button | focusableWhenDisabled, nativeButton, disabled | data-focusable, data-disabled |
Input | focusableWhenDisabled, defaultValue | data-focusable, data-disabled |
Group | disabled | data-orientation, data-disabled |
Link | — | data-orientation |
Toolbar.Input in a horizontal toolbar, and always place it last — this is an explicit, easy-to-violate accessibility guideline in the docs, not just a suggestion.focusableWhenDisabled on disabled toolbar buttons by default — an unreachable disabled button is a worse UX than a focusable-but-inert one for keyboard/AT users trying to understand toolbar state.Group to visually cluster related buttons (e.g. text-align left/center/right) without breaking the toolbar's single shared roving-tabindex sequence.Toolbar.Button follows the same nativeButton/semantics rules.