The Checkout Button Nobody Can Reach: Focus Order Through Payment Steps

A keyboard user reaches the payment step of a checkout, presses Tab, and focus disappears. It is inside the card number field, which loaded in an iframe, and the focus indicator does not show. Two more tabs and focus is back at the top of the page, because the step change moved it there. The checkout works with a mouse. With a keyboard it is a maze.

The tab order is the checkout

A keyboard user does not see a checkout. They experience it as a sequence: email, shipping address, shipping method, payment, review. The sequence is the tab order, and the tab order follows the DOM, not the visual layout. When the DOM order matches the visual order, the sequence makes sense. When it does not, the user tabs from the email field to a promo code box that sits at the bottom of the screen, then to a shipping field, then back up to a checkbox they passed three tabs ago. The form is not broken in any way a mouse user can see. It is broken in the only way a keyboard user can experience it.

WCAG 2.4.3, Focus Order, Level A, is the criterion: if a page can be navigated sequentially, the focus order has to preserve meaning and operability. A checkout that jumps around fails it, and the failure is not theoretical. It is a sale lost to a user who could not finish paying.

Where payment steps break it

The payment step is where the breakage concentrates, for three reasons. First, card fields often load in iframes, and an iframe with no accessible name is a black box to a screen reader, even though the keyboard can tab into it. Second, step changes move focus badly. A single-page checkout that swaps the shipping step for the payment step without moving focus leaves the user at a button that no longer exists, and the browser drops focus to the top of the page. Third, errors after submit do not return focus to the field. The user fixes nothing, because nothing told them where the problem is. The modal that returns focus is the same principle at smaller scale: focus is a place, and when the page moves it, the page has to put it back somewhere sensible.

The target size rules matter here too, because a keyboard user who also uses a touchscreen, or a switch device, hits the same small targets. But the order problem comes first. A target you cannot reach in sequence is worse than a target that is small.

The fixes, in the order they matter

First, make the DOM order match the visual order. If the promo code box appears at the bottom of the screen, it should sit at the bottom of the DOM. Use CSS for layout, not source order tricks, and the tab sequence will follow the page the user sees. Second, when the step changes, move focus to the step heading or the first field of the new step, and make sure the heading is announced. The user should know they are on the payment step because the page told them, not because they guessed. Third, when a modal or a payment iframe closes, return focus to the control that opened it. Fourth, give every card field an accessible name and a visible focus indicator that meets 3 to 1 against adjacent colors under WCAG 1.4.11. The indicator is the only way a keyboard user knows where they are, and on a payment form, not knowing is the same as being lost.

Test it with the keyboard only

Put the mouse away and complete a purchase with Tab, Shift Tab, Enter, and Space. If you can reach every field, if focus never vanishes, if every step announces itself, and if an error takes you to the field that needs fixing, the checkout works for keyboard users. If focus disappears into an iframe, or jumps to the top on a step change, or loops through a modal that never returns it, the checkout is broken in a way no mouse test will ever find. The test takes five minutes and it is the only one that matters.

Frequently asked questions

What decides the order a keyboard user tabs through a checkout?

The DOM order. Tab order follows the source order of the document, not the visual layout. If the visual order and the DOM order disagree, the keyboard user tabs through the page in an order that makes no sense. Fix the DOM order, and use CSS for the visual layout.

Where should focus go when the checkout moves to the next step?

When the step changes, move focus to the step heading or the first field of the new step, and announce the change. If focus stays on the button that was just clicked, or drops back to the top of the page, the user has to find their place again on every step.

Are card fields in iframes a problem for keyboard users?

They do not have to be. Card fields often load in iframes, and the keyboard can tab into and out of an iframe normally. The failure is when the iframe has no accessible name, or when the fields inside it are not labeled, or when focus cannot leave the iframe. Test the card fields with the keyboard, not just the rest of the form.

What focus indicator should checkout use?

Use the same one you use for the rest of the site: a visible outline that meets 3 to 1 against adjacent colors, on every focusable element, in every state. The checkout is the worst place for a weak focus indicator, because it is the place where losing your place costs a sale.