The Checkout Terms Checkbox: The Agreement Keyboard Users Never Read

The buy button is disabled until you tick a box. The box has no label. The screen reader announces "checkbox, unchecked" and nothing else. You are being asked to agree to something, and the checkout will not tell you what it is.

An agreement nobody can read is not an agreement

Nearly every checkout ends with a terms checkbox: a small square, a line of text, and a disabled buy button until it is ticked. The pattern is so familiar that teams stop looking at it. That is exactly why it breaks. The checkbox is often a styled div with a click handler, not a real input, so it has no name, no role, and no state that assistive technology can read. The text beside it is often a plain span, not a label, so clicking the words does nothing and the screen reader never connects the two.

The numbers say this is not rare. The WebAIM Million 2025 report found missing form input labels on 48.2 percent of homepages, and 34.2 percent of the form inputs it counted were not properly labelled at all. A terms checkbox is the worst place for that failure to land, because it is the control that gates the purchase. A shopper who cannot tell what they are agreeing to has two choices: tick a box blind, or abandon the checkout.

WCAG 3.3.2, Labels or Instructions, requires labels for inputs, and it is a Level A criterion. A checkbox with no accessible name fails it outright. The fix is a real input element with a real label element, or an aria-label that carries the same text. If the label is a link to the terms, the link needs its own accessible name too, and it must open without stealing focus from the checkout.

The disabled buy button makes it worse

Most checkouts disable the buy button until the box is ticked. That is a reasonable pattern, but only when the shopper can tell why the button is disabled. A disabled button is skipped by the tab order entirely, so a keyboard user tabs from the checkbox to whatever comes after the button, with no announcement that the button exists or why it is greyed out.

The honest fix is to keep the button enabled and explain the problem when it is pressed. Let the shopper press buy, move focus to the unchecked box, and announce that the terms must be accepted first. That is what checkout error messages are supposed to do: identify the error, in text, where the shopper can find it. A disabled button with no explanation is an error message that was never written.

There is a second trap here. Some checkouts auto-tick the box, or tick it when the shopper presses Enter anywhere in the form. A pre-ticked terms checkbox is not consent, and it is not an agreement either. The box must start unchecked, and only the shopper's own action should tick it. Autocomplete tokens have the same root cause: a one-line fix that nobody sets, because the field looks finished.

What to check before the next deploy

Tab to the terms checkbox with the keyboard alone and listen to what is announced. You should hear the full label, the word checkbox, and its state. Press Space to tick it and confirm the buy button enables. Press Space again to untick it and confirm the button disables, or the error appears.

Then check the visual side. The focus indicator on the checkbox must be visible, which is WCAG 2.4.7, and the checkbox itself must meet the 24 by 24 pixel minimum target size in WCAG 2.5.8. A 14 pixel custom checkbox with a faint outline fails both, and it fails them on the control that completes the sale. Live regions decide whether announcements arrive at all, and the terms checkbox is where a missed announcement costs the order.

Frequently asked questions

Is a pre-ticked terms checkbox a WCAG failure?

Not directly under WCAG, but it fails the purpose of the control. A terms agreement must be the shopper's own act. A pre-ticked box also hides the control's state from screen reader users, who may never know it was ticked for them. Start unchecked, always.

Can the label be a link to the terms page?

Yes, and it usually should be. The label text names the agreement, and the link opens the full terms. Make sure the link has its own accessible name, opens in a way that does not lose the shopper's place in checkout, and does not submit the form when activated.

Should the buy button stay disabled until the box is ticked?

A disabled button is the common pattern, but it hides the reason from keyboard users, because disabled controls are skipped in the tab order. The better pattern is an enabled button that, when pressed with the box unticked, moves focus to the checkbox and announces what is missing.

What size should the checkbox target be?

WCAG 2.5.8 sets a minimum target size of 24 by 24 pixels at Level AA. Many custom checkboxes are drawn at 14 or 16 pixels, which is too small for touch and for users with motor impairments. Make the visible box at least 24 pixels, and make the label text clickable too.