Should gift wrap price be in the checkbox label?

Yes, or immediately next to it in text. A buyer should not have to select an extra to discover its cost in the total, and screen reader users in particular need the price associated with the control itself.

How should a gift message character limit work?

State the limit in the field's description before typing, provide a count that can be checked on demand, and announce when the limit is reached. Never silently stop accepting characters with no explanation.

What belongs on the review step for gifts?

The wrapping choice, the full message text, and its cost inside the total. If any of those is missing at review, the buyer has no accessible way to verify a paid extra before paying for it.

Are per item gift options harder to make accessible?

They need more care, not different principles. Group each item's options under that item's name, label every control in context, and make the total wrapping cost readable as text before checkout.

Accessible Build-a-Box Flows: Multi-Step Customisation Without the Traps

October 31, 2026

Build-a-box subscription flows stack the hardest patterns on one page: steppers, quantity controls, toggles, and a running total. Making each step operable and announced.

Build-a-box flows are where subscription stores put their best margin and their worst accessibility in the same place. Choose a size, pick six items from forty, set a frequency, review a total that changes as you go. Every step is an interactive widget, and the widgets are usually custom: steppers, cards that toggle, a progress bar, a sticky summary.

A screen reader user needs the same running picture a sighted user gets at a glance: which step they are on, how many items they still owe, what the box costs now. WCAG 4.1.3 covers status messages, 4.1.2 covers the names and states of those custom controls, and 3.2 and 2.4 cover not losing the shopper when the page changes under them. All of it is testable in one sitting.

Selection state is the whole game

A product card that is in the box needs to say so in words its control can announce: add or remove, pressed or not pressed, and the product name in the name of the control, not just the word add repeated forty times. When a shopper adds a fifth of six items, an announcement should confirm the state of the box: five of six chosen. That count is the information sighted shoppers read off the summary without thinking, and it is the information most often missing entirely for screen reader users.

Quantity steppers fail in a familiar way: minus and plus buttons named only with a symbol a screen reader reads oddly or skips, and a value that can be seen but not edited directly. Label the buttons with the product and the action, make the quantity field itself editable, and announce the new quantity when it changes rather than leaving the shopper to go hunting for it.

Steps, totals, and not losing your place

Multi step flows should identify the current step properly, the same discipline as checkout: a list of steps with the current one marked with aria-current. Moving forward should move focus deliberately to the new steps heading, not leave it on a button that no longer exists, which dumps focus back at the top of the page and forces the shopper to navigate the whole step again.

The running total needs announcing when it changes in response to an action, as a status message, in plain figures. A total that only changes visually will be wrong in the shoppers head for the rest of the flow, and the first time they hear the real number is at payment. Surprises at payment are where subscriptions get abandoned and, sometimes, disputed.

Rules the interface must state out loud

Every build-a-box flow has rules: minimum items, one premium item per box, frequency discounts, a cut off for the first delivery date. If a rule is enforced, it has to be explained in text at the point it bites. A continue button that stays disabled with no explanation is a wall. A message saying add two more items to continue, placed where assistive technology will find it and linked to the action needed, is a door.

Error handling follows the same pattern when the box fails validation at review. Name the step with the problem, link back to it, and preserve everything chosen so far. A flow that empties a half built box because one step failed will not be rebuilt by the shopper. It will be abandoned, and fairly.

Frequently asked questions

How should selected items be announced in a build-a-box flow?

Each product control should carry the product name and expose its selected state, and changes should trigger a status announcement of progress, such as five of six items chosen, mirroring what the visual summary shows.

What do quantity steppers need to be accessible?

Buttons labelled with the action and product, not just a plus or minus symbol, an editable quantity field, and an announcement of the new quantity when it changes.

Should the running total be announced?

Yes, as a status message when an action changes it. A total that only updates visually leaves screen reader users working from an old figure until payment.

What should happen when a box breaks a rule, like a minimum item count?

Explain the rule in text at the point it applies, such as how many more items are needed, and keep the continue control understandable rather than silently disabled. Preserve all selections if validation fails.