Removing a Row Should Not Lose Keyboard Focus

A delete action can succeed while leaving the interface harder to use.

Imagine a list with a Remove button on each row. A keyboard user tabs to one of those buttons and activates it. The row disappears, including the control that held focus. The data is correct, but the interface still needs to decide where the user’s next action begins.

That decision belongs in the feature design.

For a simple list, a reasonable policy is to move focus to an appropriate control in the next remaining row. If there is no next row, use the previous one. If the list becomes empty, choose a stable action such as Add item.

This is a suggested interaction policy, not a universal rule. A shopping cart, an editable table, and a search result list may need different destinations. Choose the destination that lets the user continue the task with the least surprise.

WCAG’s guidance on focus order explains the underlying principle: keyboard navigation should retain a logical relationship to the content and its operation.

Identify the intended destination while the current row still exists. After the UI update completes, resolve that destination against the remaining controls and move focus if needed. Use stable item identifiers rather than assuming a row index still points to the same item.

The browser’s HTMLElement.focus() method can focus an eligible element. The important implementation detail is timing: the destination must exist when the call runs.

For asynchronous deletion, also check whether the user has moved elsewhere while waiting. A late response should not pull focus away from a new task.

Verify deletion using only the keyboard: remove a middle row, the last row, and the only row. Check failed deletion too. After each case, confirm where focus is and whether Tab continues sensibly.

Treat a visible, useful focus destination as part of the completed action. The feature is easier to use when the interface preserves the user’s place as carefully as it updates the data.