Keyboard & focus

Keyboard access is real access

A pointer can click what it sees. A keyboard moves through the page one focused control at a time, then sends key events to that focused place. If your interface cannot be reached, opened, escaped, and understood from a keyboard, many people cannot use it comfortably at all.

This lesson connects two systems that work together: keyboard events tell you what happened on the keyboard, and focus tells you which element receives those events. We will build inspectors, shortcuts, logs, a modal trap, and a live status widget using the browser’s real behavior.

The browser fires keydown when a key goes down and keyup when it comes back up. If you hold a key, most browsers repeat keydown; repeated events have event.repeat set to true. The matching keyup fires once when you release.

The old keypress event is deprecated. It mixes “a key was pressed” with “text might be typed” and does not handle modern input well. For text entry, listen to input. It covers typing, paste, autocomplete, mobile keyboards, and input method editors.

1box.addEventListener("keydown", (event) => {2  if (event.key === " " || event.key === "ArrowDown") event.preventDefault();3  show({4    key: event.key,5    code: event.code,6    repeat: event.repeat,7    shiftKey: event.shiftKey,8    ctrlKey: event.ctrlKey,9    altKey: event.altKey,10    metaKey: event.metaKey,11    capsLock: event.getModifierState("CapsLock"),12    isComposing: event.isComposing,13  });14});15 16box.addEventListener("keyup", showRelease);17// `keypress` is deprecated; use `input` for text and `keydown`/`keyup` for keys.

Notice the modifier flags: shiftKey, ctrlKey, altKey, and metaKey. Caps Lock is different: ask event.getModifierState("CapsLock"). During IME text composition, event.isComposing can be true, so shortcut code should avoid treating those keystrokes like final text.

event.key is the meaning of the key for the user’s current layout: "a", "A", "Enter", "ArrowLeft", " " for Space, or sometimes "Dead" for a dead key waiting to combine with another character. event.code names the physical seat: values like "KeyA", "Digit1", "Space", and "ShiftLeft".

1const target = "page";Run2const event = { key: "k", metaKey: true, ctrlKey: false, repeat: false };3const editingText = target === "input";4const commandKey = event.metaKey || event.ctrlKey;5const opensPalette = commandKey && event.key.toLowerCase() === "k" && !editingText;6console.log(opensPalette ? "open palette" : "let the browser type");

Shortcuts should be scoped. This lesson’s command palette listens only inside its demo surface, handles Command on macOS and Ctrl elsewhere, and calls preventDefault() only for the exact shortcut it owns.

1demo.addEventListener("keydown", (event) => {2  const editing = event.target.matches("input, textarea, [contenteditable]");3  const command = event.metaKey || event.ctrlKey;4  if (command && event.key.toLowerCase() === "k" && !editing) {5    event.preventDefault();6    openPalette();7  }8});

Focus is not only a visual ring. It is the browser’s routing table for keyboard input. Native controls such as links, buttons, inputs, selects, and textareas are focusable. A custom element can join normal Tab order with tabindex="0". Use tabindex="-1" for elements you will focus only with code. Positive tabindex values are discouraged because they create a surprising order.

1container.addEventListener("focus", log, true);2container.addEventListener("blur", log, true);3container.addEventListener("focusin", log);4container.addEventListener("focusout", log);5 6laterButton.focus({ preventScroll: true });7console.log(document.activeElement);

document.activeElement tells you the active element after focus settles. relatedTarget is the element focus is moving from or to; it can be null when focus crosses document or browser boundaries. When you move focus with code, use element.focus({ preventScroll: true }) if scrolling would be disorienting.

Style focus clearly. Modern browsers expose :focus-visible so you can show a strong ring for keyboard focus without forcing the same treatment on every mouse click.

A modal dialog interrupts the page. While it is open, Tab should cycle through the dialog’s focusable controls, Escape should close it unless there is a good reason not to, and focus should return to the opener. Otherwise keyboard users can fall behind the overlay or lose their place.

1const focusables = [...dialog.querySelectorAll("button, input, [href]")];2dialog.addEventListener("keydown", (event) => {3  if (event.key === "Escape") closeDialog();4  if (event.key !== "Tab") return;5  const first = focusables[0];6  const last = focusables.at(-1);7  if (event.shiftKey && document.activeElement === first) {8    event.preventDefault();9    last.focus();10  } else if (!event.shiftKey && document.activeElement === last) {11    event.preventDefault();12    first.focus();13  }14});

1const focusables = ["open", "cancel", "save"];2let activeIndex = 0;3function moveFocus(direction) {4  activeIndex = (activeIndex + direction + focusables.length) % focusables.length;5  return focusables[activeIndex];6}7console.log(moveFocus(1));8console.log(moveFocus(-1));

When a button opens and closes a panel, keep the relationship visible to assistive technology: put aria-expanded on the button and point aria-controls at the panel. The button still needs real button behavior; ARIA describes state, it does not add click or keyboard behavior by itself.

1button.setAttribute("aria-expanded", String(open));2button.setAttribute("aria-controls", "filter-panel");3panel.hidden = !open;4 5status.textContent = `3 results found`;6// The live region existed before this text changed.

Put the live region in the document before changing its text. Use polite for ordinary updates such as “3 results found.” Use assertive live regions or role="alert" sparingly for urgent information because the standard intent is to interrupt.

Where you will use this

Keyboard and focus details show up in almost every serious interface: search boxes that submit on Enter, menus that close on Escape, command palettes, skip links, form validation summaries, disclosure panels, autocomplete lists, and modals.

1const target = "page";2const event = { key: "k", metaKey: true, ctrlKey: false, repeat: false };3const editingText = target === "input";4const commandKey = event.metaKey || event.ctrlKey;5const opensPalette = commandKey && event.key.toLowerCase() === "k" && !editingText;6console.log(opensPalette ? "open palette" : "let the browser type");

• Use keydown for commands, not text validation.
• Check the focused target before stealing a shortcut.
• Prevent the browser default only for the key combination you own.
• Return focus after temporary UI closes.

Common misconceptions

• “keypress is the text event.” It is deprecated; use input for text changes.
• “key and code are interchangeable.” key follows meaning and layout; code follows physical position.
• “A div with click is a button.” A real button already has focus, Enter/Space behavior, disabled state, and semantics.
• “focus and blur bubble.” They do not; use capture or the bubbling focusin/focusout pair.
• “A modal is accessible once it is visually centered.” It also needs focus management, inert background, labeling, Escape behavior, and return focus.
• “Live regions are magic.” They communicate standard intent, but assistive technology behavior varies and must be tested.

Key takeaways

• keydown starts a key action, can repeat, and is good for commands; keyup marks release.
• key means “what the user intended”; code means “which physical key seat.”
• Use input for text changes, especially for IME, paste, mobile keyboards, and autocorrect.
• focus/blur do not bubble; focusin/focusout do.
• Modals must keep focus inside, support Escape when appropriate, make the background inert, and return focus.
• aria-expanded describes disclosure state; live regions announce updates without moving focus.

Up next: Page & resource loading.