Focus Loss on DOM Removal

Removing or replacing the element that currently owns keyboard focus can cause focus to disappear or move somewhere unexpected. Accessible interfaces should deliberately preserve or restore focus when DOM updates remove the user's current interaction target.

Keyboard focus belongs to a particular DOM element, identified by the browser as the active element. If that element is removed from the document, it can no longer receive keyboard input, so focus may fall back to another location such as the document body or another browser-determined target.

This commonly occurs in dialogs, menus, tabs, route transitions, autocomplete controls, and dynamically rendered components. For example, deleting a focused button after an action can leave keyboard users without a useful next control to operate.

The fix is to decide what the user's logical next interaction point should be before removing the focused node. Store a reference to that target, perform the DOM update, and call `focus()` on the replacement element when appropriate. The target must be focusable, either natively or through an appropriate `tabindex` such as `-1` for programmatic focus.

Focus restoration is especially important for transient UI. When a modal closes, focus usually belongs back on the control that opened it. When a menu item disappears, focus may need to move to the menu container or another valid item. The correct destination depends on the interaction pattern rather than simply choosing the first available element.

When focus is intentionally moved, the change should preserve a coherent keyboard sequence and should not unnecessarily steal focus from the user. Tests should exercise keyboard-only interaction and verify `document.activeElement` after the relevant DOM mutation.

Key points

• Removing the focused node can cause keyboard focus to be lost or relocated.
• Choose the logical focus destination before removing the current target.
• Use `focus()` after the replacement element exists in the DOM.
• Use `tabindex="-1"` when an otherwise non-tabbable element needs programmatic focus.
• Focus management should follow the component's interaction pattern, not an arbitrary DOM order.

Interview questions

What happens when the currently focused DOM element is removed?

The focused element can no longer be the active focus target once it is removed from the document. The browser may leave focus on another target or effectively leave the user without a useful keyboard interaction point. Therefore, dynamic UI should deliberately manage focus when it removes a focused element.

How would you safely remove a focused button from a dynamic interface?

First determine the logical control that should receive focus after the removal and keep a reference to it. Then perform the update and focus the replacement once it exists in the DOM. The destination should be appropriate for the interaction pattern, such as the next item, a containing control, or a trigger that remains available.

How should focus be handled when a modal dialog is closed?

If the opener still exists and the interaction has not changed context, focus is commonly returned to the control that opened the dialog. If that control no longer exists, the application needs a sensible fallback based on the current interface state. The important point is that closing the dialog should not strand keyboard users at an arbitrary location.

Why can a React or other component-based UI unexpectedly lose focus during a render?

A component update can replace a DOM node rather than merely changing its properties, particularly when element identity changes or a subtree is remounted. If the old node owned focus, the new node does not automatically inherit that focus in every case. Stable element identity should be preserved where possible, and deliberate focus restoration should be used when replacement is intentional.

How would you test a component for focus loss after DOM removal?

Start with keyboard-only interaction and place focus on the element that will be removed. Trigger the state change that removes it, then inspect `document.activeElement` and verify that focus is on the intended replacement. Also test cases where the preferred destination is unavailable, because robust focus management needs a fallback.