Quantity Selectors Are Where Accessible Carts Quietly Fail

Ask a screen reader user where carts break and quantity steppers come up fast, right alongside promo fields. The control looks trivial: a minus button, a number, a plus button. Underneath, it is three separate failure modes wearing a trench coat.

The buttons often have no accessible name at all, just a plus glyph the screen reader reads as nothing, or as plus with no context. The value changes silently. And the input in the middle is frequently read only or keyboard trapped in ways that only appear when you test without a mouse. None of this is exotic. It is WCAG 2.1 Level AA basics: Name Role Value (4.1.2), Keyboard (2.1.1), and Status Messages (4.1.3) when the total updates.

Name the buttons like someone is listening

Because someone is. Plus should announce as increase quantity for the named product, not as a bare symbol. When a cart holds four different items, four identical plus announcements in a row give the user no way to know which line they are changing. The product name in the accessible name is not polish. It is the only map the user gets.

The same applies to remove controls, which are often an x icon with the accessible name close or nothing. Remove is a destructive action on the user's own money. It deserves a full name: remove this product from cart. If your design system cannot say what a button does in words, the button is not designed yet.

Announce the change and the new total

Changing quantity changes price, and price is the whole point of the page. When the line total and cart total update visually with no live region announcement, a screen reader user has changed a number and learned nothing. A polite status message covering the new quantity and the updated total closes that loop.

Test it with the screen reader running, not by reading the code and nodding. Implementations that look correct frequently announce the stale total, announce twice, or announce the entire page. The fix is dull engineering: one live region, updated once, with the final values. Dull is good here. Dull is what passing looks like.

Keyboard order tells the truth about your cart

Tab through the cart in order. The stepper should arrive as a logical group, operable with standard keys, with a visible focus indicator at every stop. If focus disappears into the quantity input and the user cannot tell where they are, you have a Focus Visible (2.4.7) failure sitting in the highest value page on the site.

Also check what Enter does inside the quantity field. On more carts than you would believe, Enter submits the checkout form. A user trying to confirm a quantity of two finds themselves at payment with a quantity of one and no idea what happened. That is not a quirk. That is a defect with revenue attached.

Fix the design system, not the page

Steppers come from a shared component, which means one fix repairs every cart, basket drawer and product page quantity control at once, and one defect breaks them all at once. Audit the component in isolation: names, roles, live behaviour, keyboard pattern, focus style. Then check that no team has forked it into a local variant with the accessibility properties stripped.

Keep a regression check in the release process. Quantity controls get redesigned constantly for conversion reasons, and each redesign is a chance to lose the accessible names again. The control is small. The lawsuits and the lost customers are not.

Frequently asked questions

Which WCAG criteria do quantity steppers usually fail?

The repeat offenders are 4.1.2 Name Role Value for unnamed icon buttons, 2.1.1 Keyboard when the control needs a mouse, 2.4.7 Focus Visible when focus styling is removed, and 4.1.3 Status Messages when totals update silently. Most failing steppers break two of these at once.

Should a quantity input be directly editable?

Yes, if it is an input at all. Users must be able to type a number as well as step it, and the field needs a proper label. Making the field read only and forcing ten clicks to reach ten items punishes everyone and breaks the expectation the element itself creates.

How should quantity changes be announced to screen readers?

With a single polite live region that reports the new quantity and the updated totals after the change settles. Announce the result, not every intermediate step, and never reannounce the whole cart. Test with a real screen reader because timing bugs only show up in use.

Are icon only plus and minus buttons ever acceptable?

Only when they carry a complete accessible name that includes the action and the product, and a visible text alternative is still the safer pattern in a cart. A plus glyph alone, announced as plus or as nothing, fails the name requirement and confuses every user who cannot see which line they are editing.