Accessible Promo Code Fields: The Cart Step Everyone Fails Quietly
The promo code field is the smallest control in the cart and one of the worst built. It hides behind a collapsed link with no accessible name, applies with a button labelled only Apply, and reports success or failure by changing a colour on screen. A keyboard user may never find it. A screen reader user who finds it may never learn whether the code worked.
WCAG 2.1 Level AA does not have a promo code criterion. What it has are the criteria this little field keeps breaking: 4.1.3 Status Messages, 1.3.1 Info and Relationships, 3.3.1 Error Identification, and 2.1.1 Keyboard. The field is small. The obligations are not.
The collapsed link is the first barrier
Hiding the field behind a Have a code? toggle is a visual space decision with an accessibility cost. If the toggle is a link with no expanded state exposed, assistive technology users cannot tell whether it is open or closed, and if activating it moves nothing in the focus order, a keyboard user tabs straight past the field that just appeared above them.
The fix is mechanical: a real button with aria-expanded, the field placed immediately after it in the tab order, and focus left exactly where the user is when the region opens. None of that needs a redesign. It needs someone to test the cart with a keyboard once, start to finish, which is the step that keeps not happening.
Applied, rejected, and silent all look the same
When a code is rejected, many carts shake the field or outline it red. Colour alone fails 1.4.1 Use of Color, and a silent rejection fails 3.3.1: the user must be told in text that the code was not accepted, and the message must be associated with the field so a screen reader announces it rather than leaving it as orphaned text lower down the page.
Success has the same problem in the opposite direction. A discount that appears only as a changed total is a status update, and 4.1.3 requires status messages to be programmatically determinable, typically with an aria-live region, so the saving is announced rather than discovered. The total changing silently is not confirmation. It is a rumour.
Test it the way the complaint will arrive
Run three passes: keyboard only, from cart arrival to applied code; screen reader, listening for the toggle state, the field label, and both outcomes; and a rejected code test, because the error path is where most carts fall apart. Log which criterion each failure maps to. A defect list written in criteria numbers gets fixed. A defect list written as the promo box feels off gets a meeting.
And keep the record. If a Title III filing ever names your checkout, the document that matters is not the scan report from launch day. It is evidence that the cart, including this unglamorous field, was tested by a person, on a schedule, with fixes shipped.
Related reading: Cart Drawer Focus: Where Focus Goes When the Drawer Opens and Closes, Accessible Quantity Pickers: The Cart Control Keyboard Users Hit First, Promo Code Entry in the Cart: Where Accessible Carts Still Fail.
Frequently asked questions
Does WCAG require promo code fields to be accessible?
WCAG has no promo specific criterion, but the field must still meet the general ones: keyboard access under 2.1.1, text error identification under 3.3.1, no colour only signalling under 1.4.1, and announced status updates under 4.1.3.
Why does the discount total changing not count as confirmation?
Because a screen reader user is not watching the total. Status messages need to be exposed programmatically, usually via an aria-live region, so the applied or rejected outcome is announced when it happens.
What is wrong with hiding the code field behind a link?
Nothing, if it is a button exposing its expanded state and the revealed field sits next in the tab order. It fails when the toggle state is invisible to assistive technology or focus never reaches the field that appeared.
How should a rejected promo code be reported?
In text, next to the field, programmatically associated with it, stating the code was not accepted. A red outline or a shake animation alone fails both colour and error identification requirements.