keyboard-navigationlisted

# Keyboard navigation Everything a mouse can do, a keyboard must do: this is the baseline for users who cannot use a pointer (motor disabilities, screen-reader users, power users). Keyboard access is also the foundation screen readers build on, so getting it right serves multiple needs at once. ## Method 1. **Make every interactive element focusable and operable.** Native interactive elements (`<button>`, `<a>`, form controls) are keyboard-operable for free; custom ones (see aria-usage) need `tabindex="0"` plus key handlers (Enter/Space activate buttons, arrow keys navigate composite widgets). If a mouse user can click it, a keyboard user must be able to reach and activate it: a click handler on a `<div>` with no keyboard equivalent is the classic exclusion. 2. **Keep focus order logical.** Tab order follows the visual/reading order (top to bottom, left to right in most locales): driven by DOM order, not by positive tabindex values (which create maintenance nightmares and confusing jumps). If the visual order and DOM order diverge (CSS reordering), fix the DOM order or the layout; a tab order that jumps around the screen disorients. 3. **Never trap focus unintentionally.** Focus must be able to leave every component via keyboard; a widget that captures Tab and never releases it strands keyboard users (a real, common bug in custom modals and embeds). The one *intentional* trap is a modal dialog, which should trap f