Toolbar
Groups related tools for keyboard navigation.
Preview
Local preview. It doesn't affect real accounts, environments, or run data.
Compare the same example at each size and density. Switching keeps input values and selection state. Size guidance and comparisons
Pinned results: no
Arrow keys move between toolbar controls. The search input keeps its native editing keys.
No command executed.
Usage
Group a screen's related actions and display settings in one toolbar. Surfaces, not borders, separate the container from its controls. Inner corners use the outer radius minus the inner padding. Compose Button, Toggle, and Menu triggers through render so buttons don't nest.
Don't add a Toolbar to every simple group of buttons. Use Inline instead. Let text inputs keep their editing keys. Use Toolbar.Link for navigation instead of disguising it as a command.
Size: SizeProvider size="small" resizes the whole composition, including portals. The default size is Default. Size guidance and comparisons
Anatomy
Root(role=toolbar) → Group(Button/Toggle) + Separator + Input + composed popup trigger + Link
Keyboard and accessibility
The toolbar is a single Tab stop. Arrow keys along the orientation, Home, and End move focus. Editing keys inside inputs keep their behavior. Disabled Buttons stay focusable, since focusableWhenDisabled defaults to true, but they don't run. Links keep native navigation, and Root.disabled doesn't disable them.
Give each control a name that describes its purpose. Connect error messages to their controls, and signal state with more than color. Automated checks don't replace manual keyboard and assistive technology testing.
Example code
Shared components take their styles from design tokens. Each example sets its own composition and accessibility attributes. The calling screen defines callbacks, refs, and product data.
Key API
The table lists the common wrapper's main props. See the package type declarations for the full types.