import React from 'react';
export type ToolbarOrientation = 'horizontal' | 'vertical';
export interface ToolbarProps extends Omit<React.HTMLAttributes<HTMLDivElement>, 'role'> {
    /** Names the toolbar — "Bulk actions", "Formatting". Required, or `aria-labelledby`. */
    'aria-label'?: string;
    'aria-labelledby'?: string;
    /** Which arrow keys move between controls. Horizontal: ← →; vertical: ↑ ↓. */
    orientation?: ToolbarOrientation;
    /** Buttons, MenuTriggers, a SegmentedControl, and a vertical Divider between groups. */
    children?: React.ReactNode;
}
/**
 * Toolbar — a row of controls that act on one thing, reached as one stop.
 *
 * React Aria's `useToolbar` gives it `role="toolbar"` and `aria-orientation`,
 * arrow keys between its controls (mirrored in right-to-left), Tab that leaves
 * the whole toolbar rather than walking every button, and focus returned to the
 * control used last when Tab brings the user back. A toolbar inside a toolbar
 * becomes a `group`, so nesting one for grouping is safe.
 *
 * Every control keeps its own tab stop in the DOM — React Aria moves focus to
 * the first or last control on Tab and lets the browser take it from there —
 * so nothing here rewrites a child's `tabIndex`, and a control that mounts
 * later (the bulk actions appearing on selection) needs no registration.
 *
 * WHAT IT IS NOT FOR
 *
 * A filter bar. Tab leaves a toolbar in one press, so a search field inside one
 * strands the filters after it: Tab skips them and ← → belong to the caret.
 * That is WAI-ARIA's own caution about text fields in toolbars. A table's
 * search and filters stay ordinary tab stops; the toolbar is the row of
 * actions — the batch bar, a record's actions, an editor's formatting.
 */
export declare const Toolbar: React.ForwardRefExoticComponent<ToolbarProps & React.RefAttributes<HTMLDivElement>>;
//# sourceMappingURL=Toolbar.d.ts.map