Keyboard Navigation

How every Byteion component supports keyboard-first interaction.

Overview

Many users rely on keyboard navigation, including screen reader users, people with motor impairments, switch-device users, and power users. Every interactive Byteion component should be reachable with Tab, operable with activation keys, and dismissible with Escape where applicable. If a component requires a mouse, it is not complete.

Keyboard interaction contract

Interactive Byteion components should follow these rules:

Be reachable with Tab when they are interactive
Be skipped by Tab when disabled or hidden
Show a visible focus state
Use native keyboard behaviour where possible
Support expected activation keys
Close dismissible overlays with Escape
Keep focus inside modal / drawer overlays while open
Restore focus to the trigger after closing overlays
Preserve logical focus order matching the visual reading order

Core key table

Key	Expected behaviour
Tab	Move to the next focusable control
Shift+Tab	Move to the previous focusable control
Enter	Activate buttons, links, selected menu items, or selected tabs where appropriate
Space	Activate buttons, checkboxes, toggles, and selected menu items where appropriate
Escape	Close dismissible overlays such as modals, drawers, dropdowns, popovers, and menus
Arrow keys	Move within composite widgets such as tabs, menus, radio groups, listboxes, and roving-tabindex groups
Home / End	Move to first / last item in tab lists, menus, or listbox-like widgets where supported

Use native elements whenever possible so browsers provide correct keyboard behaviour automatically.

Component-specific keyboard behaviour

Component	Keyboard behaviour
Button	`Enter` and `Space` activate. Disabled buttons are not interactive.
Link	`Enter` follows the link. Use links for navigation, not actions.
Input / Textarea	Native typing, selection, and focus behaviour. Labels and errors must be connected.
Checkbox / Switch	`Space` toggles state. State must be visible and announced.
Select / Combobox	Use native select where possible; custom comboboxes need arrow navigation and clear expanded state.
Modal / Dialog	Focus moves inside on open, `Tab` cycles inside, `Escape` closes, focus returns to trigger.
Drawer	Same overlay rules as modal when it blocks the page.
Dropdown / Menu	Trigger opens with `Enter` / `Space`, arrow keys move between items, `Escape` closes, focus returns.
Tabs	Arrow keys move between tabs, `Home` / `End` jump, `Enter` / `Space` activates if activation is manual.
Tooltip	Appears on focus / hover, does not trap focus, dismisses on `Escape` if interactive behaviour is present.
Toast / Alert	Should not steal focus unless immediate action is required.
Table / DataTable	Native table reading order; interactive controls inside rows remain reachable.

Focus management

Focus should move intentionally when overlays open
Modal / drawer focus should be trapped while open
Focus should return to the trigger after close
Background content should not be reachable while modal overlays are active
Do not move focus unexpectedly during normal page updates
Use tabindex="-1" for programmatic focus targets such as dialog containers or headings
Avoid tabindex="0" unless creating a valid custom interactive pattern
Never use tabindex greater than 0

Practical examples

Modal keyboard flow

User tabs to the trigger button
Enter or Space opens the modal
Focus moves to the first useful control or the dialog container
Tab and Shift+Tab cycle inside the modal
Escape closes the modal
Focus returns to the original trigger

Dropdown keyboard flow

User tabs to the trigger
Enter or Space opens the dropdown
Arrow keys move between menu items
Enter activates the focused item
Escape closes the dropdown and returns focus

Tabs keyboard flow

User tabs to the tab list
Left / Right arrows move between tabs
Home / End jumps to first / last tab
Enter or Space activates the focused tab if activation is manual
Tab moves into the active panel

Custom control guidance

Prefer native controls first. If it behaves like a button, use <button>. If it navigates, use <a href="">. Use tabindex="0" only when a custom interactive pattern is unavoidable, and only after adding the correct role, keyboard handlers, state attributes, and visible focus styles.

Keyboard testing checklist

Complete a full workflow using only keyboard
Test Tab and Shift+Tab order
Test Enter and Space activation
Test Escape dismissal for overlays
Test arrow-key behaviour in tabs, menus, radio groups, and listbox-like widgets
Test focus trap and focus return for modals / drawers
Test visible focus in light and dark mode
Inspect document.activeElement while debugging
Run automated accessibility checks, but verify manually

Do and Don't

Do

Use native interactive elements first
Keep logical DOM order
Show visible focus states
Use tabindex="-1" for programmatic focus when needed
Return focus after overlays close
Test every interactive component with keyboard only

Don't

Use <div onClick> for buttons
Use tabindex greater than 0
Hide focus indicators
Trap users without Escape or close controls
Move focus unexpectedly after every render
Rely on hover-only interactions

Developer tips

• Disconnect your mouse and complete a real workflow — forms, modals, dropdowns, tabs. • Use document.activeElement in DevTools to see which element currently has focus. • Run screen-reader smoke checks with VoiceOver (macOS) or NVDA (Windows). • Byteion JS handles supported keyboard patterns for data-bi-* components, but custom compositions still need manual testing. • Keyboard testing should include forms, modals, dropdowns, tabs, sidebars, data tables, and settings pages. • Test in both light and dark mode — focus indicators must be visible on all surfaces.

Accessibility Overview — Accessibility principles and testing
Focus Management — Focus trap and focus restore rules
ARIA Patterns — ARIA roles, states, and properties
Modal / Dialog — Overlay keyboard behaviour
Dropdown / Menu — Menu keyboard behaviour
Forms — Labels, validation, and keyboard-friendly fields

Unlock Premium Patterns

Get access to copy-paste ready Pro blocks, SaaS templates, and advanced component patterns.

Explore Pro Components