Keyboard navigation works for all interactive elements; focus order is logical and visible

Keyboard-only users—including people with motor impairments, power users, and anyone using assistive switches—cannot interact with any element unreachable by Tab or that traps focus without escape. WCAG 2.2 SC 2.1.1 (Level A) and SC 2.4.3 (Level A) are both at stake, as is Section 508 2018 Refresh 503.3.3. A modal that swallows keyboard focus indefinitely, or a custom widget that responds only to mouse clicks, locks these users out entirely. Federal procurement standards mandate full keyboard operability, and failure here triggers compliance findings.

Use semantic HTML (<button>, <a>, <input>) which receives keyboard focus by default. For custom widgets, add tabindex="0". Always preserve visible focus indicators—never suppress outline without a replacement:

button:focus-visible, a:focus-visible, input:focus-visible {
  outline: 2px solid #0066cc;
  outline-offset: 2px;
}

For modal dialogs, trap focus inside while open and restore it to the trigger on close. In src/components/Modal.tsx, implement a focus-trap loop:

modal.addEventListener('keydown', (e) => {
  if (e.key === 'Tab') {
    if (e.shiftKey && document.activeElement === firstFocusable) {
      e.preventDefault(); lastFocusable.focus();
    } else if (!e.shiftKey && document.activeElement === lastFocusable) {
      e.preventDefault(); firstFocusable.focus();
    }
  }
  if (e.key === 'Escape') closeModal();
});