A control that moves after render steals the tap meant for it

What it is

The human cost of a layout shift is not a worse score. It is the finger or pointer landing on the wrong control. The target was still in place while aiming; by pointerup it has moved, and hit-testing returns whatever now occupies that coordinate. That is a misclick from layout shift. CLS can be low—the moved area is small—while the one node that moved is exactly the one being pressed.

Why it happens

Motor planning locks a spatial target before press. Hit-testing queries the hit tree at sample time. If layout runs in between, the coordinate is unchanged and the tree is not, so the winner changes. Touch is especially exposed: tens to a couple of hundred milliseconds separate aim from lift, enough for a late insert to finish. A mouse press and release that straddle a shift can likewise activate a different control.

The failure is intent coordinate and hit coordinate no longer naming the same control, not “the page jumped.” A tiny shift that crosses a hit-region boundary raises error rate; a large shift in a region with no pointer may interrupt reading without causing a misclick.

Studying it

CLS does not count misclicks, so the score and the human outcome can metric mismatch. In the lab, inject a delayed insertion after the target is already hittable, and record whether pointerup still hits the aimed control, plus whether a layout-shift entry occurred between down and up. In the field, time-align layout-shift attribution with clicks, repeated taps, and undo—bursts right after a shift are often misses, not extra demand. Do not substitute CLS percentiles for misclick rate.

Where it stops holding

Keyboard and assistive tech do not use the pointer hit tree; this misclick mechanism does not apply to them—they suffer reordered focus and reading position instead. A shift after the pointer has already left the hit region cannot falsify that click. Dragging and scrolling track a moving target by design; coordinate change during follow-through is not a misclick. Canvas or game hit-testing is application-owned, not the document hit tree.

Applying it

• Freeze the flow position of irreversible controls (submit, buy, close, send) once they are hittable; late content must not shove them from above or from inside.
• Keep a gap around touch targets that late-growing slots cannot cross; do not park small buttons against a slot that will gain height.
• Confirm irreversible actions on lift, or delay commit slightly, so a target swap between down and up does not fire.
• Verify on device: insert a banner after the button is hittable and check the first tap still lands on it. In RUM, align shifts with subsequent tap bursts; misclicks should fall as those shift sources are removed.

Related

• Same group: R3.05.1 Late-arriving content pushes already laid-out nodes · R3.05.3 Dynamic content needs reserved space · R3.05.4 Render-blocking resources determine the first visible moment · R3.05.5 Already-interactive regions must not be reflowed by late content · R3.05.6 Async inserts should occupy positions that do not interrupt reading
• Adjacent: I2.07 Perceived performance · R3.15 First-paint metrics and interaction readiness
• Search terms: misclick · layout shift · hit testing