Promo Code Entry in the Cart: Where Accessible Carts Still Fail

2026-10-29

Ask a screen reader user to apply a discount code in a typical cart and watch where the flow breaks. It rarely breaks at checkout payment. It breaks at a small collapsed line that says something like have a code, with no indication of what happens when you activate it.

Promo entry is treated as a decorative extra by design teams. For the shopper holding a code from a birthday email, it is the whole reason they are in the cart today.

The collapsed toggle is the first failure

Under WCAG 2.1, a control needs an accessible name that matches its visible label, success criterion 4.1.2 and the label in name principle in 2.5.3. A promo toggle coded as an icon, an empty button, or a link whose name is just click here gives voice control users nothing to say and screen reader users nothing to find.

The fix is unglamorous: a real button, labelled add a promo code or similar, with aria-expanded reflecting whether the field is open. If your platform collapses the field by default, that button is the door. Doors need handles.

Placeholders are not labels

Once open, many carts show a field whose only text is a placeholder that vanishes as you type. A placeholder is not a label under any reading of 3.3.2, labels or instructions. When the code fails, the shopper can no longer see what the field was even for.

Give the field a persistent visible label, promo code, and keep the apply button's name specific. Apply is fine next to a labelled field. Apply floating alone in a list of controls is not.

Errors that only turn red

The common failure: the code is rejected, the field border turns red, a small line of text appears above the cart, focus stays exactly where it was, and nothing is announced. A screen reader user hears silence and reasonably concludes the button did nothing.

A proper error is text, programmatically tied to the field with aria-describedby, announced via a live region or by moving focus to it, and written in plain words: that code has expired, not an error has occurred. Expiry, minimum spend, and wrong code are different problems and deserve different sentences.

Test it the way it will be used

Run the test with a keyboard alone first: can you open the toggle, type, apply, and reach the error without a mouse, in a logical order? Then run it with a screen reader, NVDA or VoiceOver, and listen for the name, the label, and the announcement in that order.

Time it. If applying a valid code takes a voice or screen reader user three times as long as a mouse user, the cart is technically operable and practically hostile, and the metric that matters, completed orders, will show it.

Frequently asked questions

Does WCAG require a label on a promo code field?

Yes. WCAG 2.1 criterion 3.3.2 requires labels or instructions for user input, and 4.1.2 requires the control to have an accessible name. A placeholder that disappears while typing does not satisfy either on its own.

Should the promo field be collapsed at all?

Collapsing is a design choice, not a violation, provided the toggle is a properly named button that exposes its expanded state. An always open field is simpler and removes a whole class of failures, which is why many accessible carts leave it open.

How should a rejected code be announced?

In plain text tied to the field, stating the specific reason, and announced to assistive technology through a live region or focus movement. Colour alone, or a message that only says invalid code with no reason, leaves the shopper guessing.

What is the quickest promo entry fix?

Rename the toggle to say what it opens, give the field a real visible label, and make the error text specific and announced. Those three changes need no redesign and fix the failures most audits find in this flow.