Keyboard & Focus Management

Introduction

Keyboard and focus management ensures every interaction operable without a pointer (WCAG 2.1.1) with visible, unobscured focus indicators (2.4.7, 2.4.11). Staff engineers own tab order, focus traps, skip links, and roving tabindex in SPAs where route changes don't reset focus intelligently.

Business problem

Keyboard users include motor disabilities, power users, and QA — not edge case. Missing focus trap in modal lets tab escape to background; SPA route change without focus move leaves SR on stale content announcement.

• WCAG 2.2: 2.4.11 Focus Not Obscured — sticky headers/cookie banners hiding focused fields.
• Legal: Keyboard inaccessibility is among most common ADA complaint patterns.

Why this feature exists

HTML tabindex and focus() API exist to manage sequential focus navigation. Browsers default tab order follows DOM order for focusable elements (a, button, input, tabindex>=0).

• tabindex=0: Insert in natural tab order.
• tabindex=-1: Programmatic focus only — skip link targets, headings after route change.
• tabindex>0: Anti-pattern — disrupts natural order.

Browser internals

Focus ring rendered by user agent :focus-visible heuristic — mouse click may suppress ring, keyboard shows it. Authors must not outline:none without custom visible indicator.

• Sequential focus navigation: Tab/Shift+Tab cycle focusable elements.
• Focus trap: Not native except dialog.showModal() — custom modals need JS loop.

Rendering workflow

SPA focus protocol: Route change → move focus to h1 or main tabindex=-1 → announce page title via SR → restore logical tab order. Modal open → focus first focusable → trap Tab → Escape closes → restore trigger focus.

• Skip link: First focusable element — visible on focus.
• Roving tabindex: Arrow keys within toolbar/tablist — one tab stop for group.

Feature deep dive

Focus management patterns in HTML + JS:

• Skip to main: a href="#main" + main tabindex="-1".
• Modal: dialog element or focus trap with aria-modal.
• Dropdown: Escape closes, focus returns to trigger.
• Inert: inert attribute on background when modal open (modern browsers).

<a href="#content" class="skip-link">Skip to content</a>
<main id="content" tabindex="-1">
  <h1>Checkout</h1>
  <form>...</form>
</main>
<style>
  :focus-visible { outline: 2px solid #005fcc; outline-offset: 2px; }
  .skip-link:focus { position: static; }
</style>

Accessibility analysis

Keyboard test protocol: Unplug mouse — complete all flows. Tab through — focus always visible? Logical order matches visual? No keyboard traps except intentional modals? Shift+Tab reverses correctly?

• 2.4.11 test: Tab to each field — is focus fully visible or hidden under sticky nav?

SEO impact

Minimal direct SEO impact — but skip links and semantic main improve crawl structure marginally and are best practice for all users.

Security considerations

Focus hijacking via malicious iframe or overlay — related to clickjacking. inert + CSP frame-ancestors mitigate. Don't autofocus attacker-controlled inputs.

Performance impact

Focus loops in poorly written traps can cause excessive layout — use inert over display:none toggling for background. INP on keydown handlers should be lightweight.

Real production example

React Router focus management hook pattern:

• Test: E2E with keyboard — tab count to primary CTA per route documented.

useEffect(() => {
  document.title = pageTitle;
  const main = document.getElementById("main");
  main?.focus({ preventScroll: false });
}, [location.pathname]);

Enterprise usage

Design tokens include :focus-visible styles meeting 3:1 contrast against adjacent colors (WCAG 2.2 focus indicator). Global ban on outline:none without replacement in stylelint.

Common production failures

Modal without trap — tab reaches background checkout button underneath overlay. autofocus on search on every page load disorients SR users. tabindex=1,2,3 on marketing page — chaos.

Architecture review questions

• All flows completable Tab/Shift+Tab/Enter/Escape/Space?
• :focus-visible meets contrast and visibility requirements?
• SPA route changes move focus to main or h1?
• Modals trap focus and restore on close?
• Sticky UI doesn't obscure focused elements (2.4.11)?

Hands-on project

Project: Add skip link + main focus target + :focus-visible tokens; implement modal with dialog.showModal() and verify trap with keyboard-only test script.

Interview questions

Try it yourself

Edit the HTML, CSS, or JS panels — the preview updates as you type.

Summary

Keyboard and focus management delivers WCAG operability through skip links, logical tab order, visible focus indicators, modal traps, and SPA focus protocols — validated by keyboard-only testing, not mouse-only QA.