Accessible Quantity Pickers: The Cart Control Keyboard Users Hit First
The quantity picker is the first interactive control most shoppers touch in a cart, and it is where keyboard access quietly dies on otherwise decent stores. A typical pattern looks harmless: a minus button, a number, a plus button. Under a keyboard, the minus and plus are often divs with click handlers, unreachable by Tab, invisible to a screen reader, and impossible to operate without a mouse. WCAG 2.1 Success Criterion 2.1.1 requires that all functionality be operable through a keyboard. A quantity control that only answers a pointer fails that criterion outright.
Screen reader users get a second failure on top of the first. When the buttons are real buttons but carry no accessible name, the reader announces button, button, with no hint of what either one does. Criterion 4.1.2, Name, Role, Value, is the one that covers this: the control's purpose has to be available programmatically, not just visible as a plus or minus glyph that a screen reader may read as nothing at all.
The pattern that works is boring
Use a real input for the number and real buttons either side of it. Label the buttons decrease quantity and increase quantity, either as visible text or as an accessible name tied to the product, because a cart with four line items needs decrease quantity for the blue shirt, not four identical announcements. When the value changes, update the line total without moving focus. Yanking focus back to the top of the cart after every quantity change is a common implementation shortcut, and for a keyboard user it means tabbing through the whole page again to change a second item.
Let people type the number. Buttons that step by one are fine for changing one item to two. They are a punishment for a trade buyer changing 4 to 40, and they are slow for anyone with limited dexterity, for whom each keypress has a cost. An input with inputmode set to numeric, a proper label, and validation that explains itself covers both groups with the same control.
Error handling is part of the control
Type 0 into a quantity field and three things happen across stores: the item silently vanishes, the field refuses and says nothing, or an error appears that a screen reader never announces. Criterion 3.3.1, Error Identification, requires the error to be described in text, and good practice announces it politely with a live region. Removing an item deserves its own explicit remove button anyway. A quantity of zero acting as a hidden delete is a surprise for every user, and for a screen reader user who mistyped, it is a purchase they have to rebuild from memory.
Stock limits need the same treatment. If the maximum is 5 and the shopper types 8, say the maximum, in text, next to the field, and keep the typed value visible so it can be corrected. Silently resetting the number to 5 teaches nobody anything and reads as the site ignoring the input.
A five minute audit for your own cart
Put the mouse aside. Tab to the cart, change a quantity using only the keyboard, type a number directly, set it to zero, and set it above the stock limit. Then repeat the change with a screen reader running and listen to what gets announced. Every failure you find in those five minutes is a failure a paying customer is having today, at the exact point in the journey where they had already decided to buy.
Related reading: Promo Code Entry in the Cart: Where Accessible Carts Still Fail, When a Cart Error Wipes the Form: An Accessibility Failure, Not a Nuisance, Cart Accessibility for Voice Control Users: Names Are the Interface.
Frequently asked questions
What WCAG criteria cover cart quantity controls?
Mainly 2.1.1 Keyboard, because the control must work without a mouse, and 4.1.2 Name, Role, Value, because a screen reader must be told what each button does. Errors fall under 3.3.1 Error Identification.
Should quantity be buttons, a dropdown, or a typed input?
A typed numeric input with step buttons either side covers the most users: buttons for small changes, typing for large ones. A dropdown caps the quantity and is slow for bulk orders.
Why should changing quantity not reload the cart?
A reload or focus reset forces keyboard and screen reader users to navigate back to where they were for every change. Update totals in place and leave focus where the shopper put it.
Is setting quantity to zero a good way to remove an item?
No. It hides a destructive action inside a number field. Give removal its own clearly labelled button and confirm the change in text a screen reader announces.