What is focus management and why does it matter for accessibility?

JavaScriptAccessibility

The short answer

Focus management is controlling where keyboard focus goes as the interface changes. Keyboard and screen reader users move through a page using focus, so when you open a dialog, reveal content, or navigate, focus has to land in a sensible place and stay where the user expects. Done well it is invisible. Done poorly, focus gets lost, jumps to the top of the page, or escapes a dialog, which makes the interface unusable without a mouse.

Moving focus into a dialog

When a modal opens, move focus into it so the next keypress acts on the dialog, not the page behind it:

// Kept at module scope so closeDialog can read it later
let previouslyFocused = null;
function openDialog(dialog) {
  previouslyFocused = document.activeElement;
  dialog.hidden = false;
  const firstField = dialog.querySelector('input, button');
  firstField?.focus();
}

previouslyFocused lives outside the functions so both can share it. Saving document.activeElement first is what lets you restore focus later.

Restoring focus on close

When the dialog closes, send focus back to the element that opened it. Otherwise the user is dropped at the top of the document and loses their place:

function closeDialog(dialog) {
  dialog.hidden = true;
  previouslyFocused?.focus();
}

Trapping focus inside a dialog

While a modal is open, Tab should cycle through the dialog's own controls and not reach the page behind it:

function trapFocus(dialog, event) {
  if (event.key !== 'Tab') return;
  const focusable = dialog.querySelectorAll(
    'a[href], button, input, select, textarea, [tabindex]:not([tabindex="-1"])'
  );
  const first = focusable[0];
  const last = focusable[focusable.length - 1];
  if (event.shiftKey && document.activeElement === first) {
    event.preventDefault();
    last.focus(); // wrap backward to the end
  } else if (
    !event.shiftKey &&
    document.activeElement === last
  ) {
    event.preventDefault();
    first.focus(); // wrap forward to the start
  }
}

Roving tabindex for composite widgets

In a menu, toolbar, or tab list, the whole group should be one Tab stop, with the arrow keys moving between items. The roving tabindex pattern keeps exactly one item focusable at a time:

function moveFocus(items, currentIndex, nextIndex) {
  items[currentIndex].setAttribute('tabindex', '-1');
  items[nextIndex].setAttribute('tabindex', '0');
  items[nextIndex].focus();
}

Interview Tip

The two moments interviewers listen for are opening and closing. On open, move focus into the new content. On close, restore it to the trigger that was focused before. If you can also describe trapping Tab inside a modal and the roving tabindex pattern for menus and tabs, you have covered the cases that matter most. The native <dialog> element handles trapping and restoration for you, which is worth mentioning.

Why interviewers ask this

Focus management is where most accessibility bugs in interactive components live. Modals, dropdowns, and custom widgets work fine with a mouse but break for keyboard users when focus is not handled. Interviewers want to see that you think about the keyboard path through your UI, that you restore focus after transient content, and that you know patterns like focus trapping and roving tabindex.

Table of Contents