Your build starts here
Replace bracketed details with your own goal, context, and checks. Keep the first build small enough to inspect.
Implement keyboard interaction for [toolbar, tabs, listbox, or other named composite] using its applicable semantic pattern. Prefer existing native controls where they meet the requirement. Define entry into the component, internal navigation keys, activation, disabled items, and where Tab leaves it.
If the chosen pattern uses roving tabindex, keep one intended item in the tab sequence and move actual focus consistently. State whether selection follows focus or requires activation. Keep a visible focus indicator and choose a recovery target when the active item is removed or disabled.
Verify Tab and Shift+Tab, the required navigation keys, activation, an empty state, dynamic item changes, and supported directionality. Do not intercept typing shortcuts that belong to an editable field. Report which pattern and assistive-technology checks were used.Make this prompt yours
Choose the pattern before copying key bindings. A toolbar, tab list, and ordinary group of buttons need not behave identically.
You might also hear
- roving tabindex
- composite widget
- arrow keys
- focus selection
- keyboard toolbar
The docs behind it
These references explain the underlying concepts and APIs. The prompt templates and project plans are original examples to adapt to your own setup.
Research sources reviewed .
Editorial review · October 28, 2026
Supported: Original composite-control template. WAI supports roving tabindex and separating focus from selection; key bindings, disabled-item policy, and activation must follow the selected component pattern.