Checkout Focus Order: The Tab Sequence That Loses Shoppers at Payment

A shopper who cannot use a mouse reaches the payment step by pressing Tab, one element at a time, and the order those elements come in is the checkout. Get it wrong and the shopper tabs past the card number field into the footer, or into a promo code box, or into a chat widget, and the sale is gone. The focus order is not a detail. It is the path to the money.

The tab order is the checkout

Keyboard users do not see your checkout the way you do. They experience it as a sequence: the order the browser follows through the page, which is the order the elements sit in the document, not the order they appear on screen. When the visual layout and the document order disagree, the tab sequence jumps around the page, and the shopper loses track of where they are. A checkout that looks clean can tab like a maze.

The payment step is where this breaks most often. The card number field, the expiry, the security code, and the pay button should come in that order, one after the other, with nothing between them. In practice the promo code field sits between the card number and the expiry, or the billing address toggle comes first, or a trust badge with a link interrupts the sequence.

WCAG 2.4.3, Focus Order, says the navigation sequence has to preserve meaning and operability. That is the standard, and it is a low bar: the tab order should follow the order a sighted user reads the page. Most checkouts fail it at the payment step, and the failure is invisible to the team that built it, because the team tests with a mouse.

Where focus actually goes wrong

Run the test yourself. Open your checkout, put the mouse aside, and press Tab from the first field to the pay button. Count the stops. If you pass more than two elements that are not part of paying, the order is wrong. The usual suspects: a promo code field that appears before the card fields, a billing address checkbox that jumps focus to the top of the form, a chat widget that grabs focus when it loads, and a footer link that appears in the middle of the sequence because the footer is in the document before the payment form closes.

The promo code field is the worst offender, because it is the field shoppers tab into by accident and then cannot tab out of cleanly. It sits in the visual layout between the order summary and the payment fields, and in the document it sits wherever the developer put it, which is often before the card number. The error message problem is the same shape: the information exists, but it is not where the keyboard user can reach it.

The billing address toggle is the second offender. When a shopper unchecks the box that says the billing address matches the shipping address, the new fields appear, and focus should move to the first new field. In most checkouts it does not move at all. The autocomplete fix is the same kind of one-line change: small, cheap, and invisible to mouse users.

The three-line fix and the test that proves it

The fix is usually three lines. Move the promo code field after the pay button in the document. Move focus to the first billing field when the toggle opens it. Set the chat widget to load without taking focus.

The test that proves it is the same test a screen reader user runs every day: tab through the checkout with the screen off and see whether you can pay. If you can, the order is right. If you get lost, the order is wrong, and the fix is in the document order, not in the styling. The mini-cart focus trap test is the same discipline applied one step earlier: the keyboard path has to work end to end, not just on the page you tested.

Frequently asked questions

What is focus order, and why does it matter at checkout?

Focus order is the sequence a keyboard user moves through when pressing Tab. It follows the order elements sit in the document, not the order they appear on screen. At checkout it matters because the shopper has to reach the pay button without getting lost, and a wrong order sends them into the footer or a chat widget instead.

How do I test focus order on my checkout?

Put the mouse aside, open the checkout, and press Tab from the first field to the pay button. Count the stops. If you pass more than two elements that are not part of paying, the order is wrong. The promo code field and the chat widget are the usual suspects.

Does WCAG require a specific focus order?

WCAG 2.4.3 Focus Order requires the navigation sequence to preserve meaning and operability. In practice that means the tab order should follow the order a sighted user reads the page, so the card fields, expiry, security code, and pay button come one after another with nothing between them.

Why is the promo code field a focus order problem?

It sits between the order summary and the payment fields visually, but in the document it often sits before the card number. Keyboard users tab into it by accident on the way to paying. Move it after the pay button in the document order, or into the order summary.