Monitoring Focus Order in Sticky Add to Cart Bars

Sticky add to cart bars often sit at the end of the tab order while sitting at the top of the screen. How to spot the mismatch and what a sane focus order looks like.

Open a product page, start tabbing, and count. Gallery, options, quantity, add to cart in the main column, reviews, recommendations, footer, and then, long after you stopped expecting it, the sticky bar that has been floating at the top of your screen the whole time gets focus. Visually it was first. In the tab order it is fortieth. That gap between what the eye sees and what the keyboard does is WCAG 2.4.3 Focus Order failing in slow motion.

Sticky bars are not going away. They sell. The monitoring job is not to argue them off the page, it is to catch the three ways they rot: focus order that contradicts the layout, a bar that appears and covers the focused element, and a second add to cart button with a slightly different name that screen readers announce as a separate, confusing control.

What good looks like, in keystrokes

Tab from the top of a product page and write down the sequence. Header, then the main product controls in the order you see them, then the rest of the page. The sticky bar should either share the main add to cart button, so there is only one control, or enter the tab order at the point where it becomes visible and sit next to that button logically. Two add to cart buttons twenty tabs apart is a defect even if both work.

Then scroll halfway down with the keyboard by tabbing, not with the mouse. When the bar appears, does it cover the element that currently has focus? WCAG 2.4.11 Focus Not Obscured (Minimum) in 2.2 exists for exactly this component. A focused size option hidden under a sticky bar is a fail you can screenshot, which helps, because this class of bug otherwise gets closed as cannot reproduce by someone testing with a mouse wheel.

Signals worth alerting on

Automated scans catch almost none of this. What they can catch is change: the bar's markup changed in a deploy, a new element with tabindex appeared, or the page gained a duplicate control with the same accessible name. Those are the alerts worth wiring up. A DOM change to a known fragile component should trigger a five minute manual keyboard pass, not another automated score report that says 100 while the tab order is broken.

Keep the manual pass scripted. Same product, same variants, same sequence, recorded as a short checklist with the expected order written down. The value is in the comparison. Without a written expected order, every tester invents their own, and a regression that moves the bar to the end of the page reads as a preference instead of a break.

Fix patterns that hold

The durable fix is boring: one add to cart control, moved or cloned in the visual layer only, or a bar rendered in the DOM right after the main buy section so visual and keyboard order can match. Cloned buttons with hidden duplicates are where this keeps breaking, because the clone gets the click handler and the original gets the accessible name, or the reverse after an update.

If the app providing the bar cannot do that, hide the bar's duplicate control from the tab order and from assistive technology, and keep the main button reachable and visible enough to do the job. That is a compromise, and compromises like it should be logged with a review date, because the next app update will not respect a decision nobody wrote down.

Related reading: Monitoring Skip Links: The First Tab Stop Nobody Tests, Monitoring Button Names After Every App Install, Monitoring Tab Order in Drawers and Menus After Theme Updates.

Frequently asked questions

Why does focus order matter if both buttons work?

Because keyboard and screen reader users navigate in the order the code gives them, not the order on screen. A working button in the wrong place costs dozens of extra keystrokes on every purchase and reads as a different control. WCAG 2.4.3 requires an order that preserves meaning and operability, not just operability.

Can a scan detect a bad sticky bar focus order?

Not reliably. Scans can flag duplicate accessible names, positive tabindex values, and markup changes in the component. The actual order problem needs a short manual keyboard pass. Use scan alerts about component changes as the trigger for that pass.

Should the sticky bar be removed for accessibility?

Usually not. One control shared between the bar and the main section, or a bar placed logically in the DOM, fixes most cases. Removal is the answer only when the vendor component cannot be made keyboard sane and no equivalent route exists.

What does Focus Not Obscured add here?

WCAG 2.4.11, new in 2.2, says the focused element cannot be entirely hidden by author created content like sticky headers and bars. A size selector or quantity field sitting under the bar while it has focus fails it, even if the tab order itself is logical.