When a Cart Item Is Removed, Where Does Focus Go?

When a shopper removes an item from the cart, the button they were focused on is deleted from the page. The browser has nowhere to put focus, so it falls back to the body, and the keyboard user is back at the top of the page. They have to tab through the header, the navigation, and the whole cart again to get back to where they were.

This is not an edge case. Removing items is one of the most common things people do in a cart, and it happens exactly when a shopper is trying to fix a mistake. The moment they most need the cart to cooperate is the moment it throws them out. WCAG 2.1.1 requires all functionality to be available from a keyboard, and a cart that ejects keyboard users on remove is failing that in practice, whatever the audit says.

The disappearing element problem

Before you remove the element, decide where focus goes next. The next item's remove button is the honest choice: the shopper was working through the list, and the list is still there. If the cart is now empty, focus goes to the cart heading, which needs a tabindex of minus one so it can receive focus without entering the tab order.

Move focus after the DOM updates, not before, and announce the change. A short live region message, 'Item removed. Three items remain,' tells a screen reader user what happened without moving their focus for them. The focus move and the announcement are two different jobs, and they need two different mechanisms.

The fix is three lines of intent

Tab to a remove button, press Enter, and watch where focus lands. If it lands on the next remove button, the fix works. If it lands at the top of the page, it does not. If it lands nowhere visible, it is worse: focus is on the body, and the next Tab press starts from the top.

Test with the sticky header in place, too. WCAG 2.2 criterion 2.4.11 says a focused element must not be fully hidden by a sticky header, banner, or chat widget. A focus move that lands behind the header is a fix that fails its own test, and the W3C guidance uses a cookie banner hiding the focused control as its example of a failure.

What to test with a keyboard, not a mouse

The empty cart is where most teams forget focus entirely. The cart clears, the page shows an empty state, and focus is nowhere. A keyboard user tabs forward from the top and has to find the empty message by accident. Move focus to the empty-cart heading, announce that the cart is empty, and offer the continue-shopping link right there.

Keep reading: Mini cart keyboard traps: the focus test that catches them, Cart error messages that name the field that failed.

The empty-cart case

Automated checkers will not catch this for you. They test the page as it loads, not the page after a shopper removes an item. Focus management after a DOM change is a manual test, and it takes about two minutes with a keyboard. That is the whole cost of getting it right.

Frequently asked questions

Where should focus go after removing a cart item?

To the next item's remove button, so the shopper can keep working through the list. If the cart is now empty, focus goes to the cart heading, which needs a tabindex of minus one to receive it.

Why does focus jump to the top of the page?

The focused element was deleted from the page, so the browser falls back to the body. The fix is to move focus deliberately after the DOM updates, to a real element the shopper can use next.

Does WCAG cover focus after an element is removed?

Yes, in practice. WCAG 2.1.1 requires keyboard access to all functionality, and 2.4.7 requires a visible focus indicator. A cart that ejects keyboard users on remove fails the spirit of both, even if no single criterion names the case.

What is tabindex minus one for?

It lets an element receive focus from script without adding it to the tab order. Headings and status messages use it so focus can be moved to them deliberately, without making keyboard users tab through them on every pass.