# The Checkout Discount Code Field: The Label Screen Readers Skip

Source: https://cartcomply.com/blog/2026-11-15-checkout-discount-code-field-screen-reader-label.html

*Ask a screen reader user to find the discount code box at checkout and watch what happens. They tab through the form, hear the email field, the shipping fields, the card fields, and then the payment button. The discount code field never announces itself, because it has no label, only a placeholder that says "Promo code" in grey text. The sighted shopper sees it. The screen reader user never knew it existed, and the store just charged them full price for a discount they had in their pocket.*

## A placeholder is not a label

This is the most common labeling failure in checkout, and it is also the most avoidable. A placeholder looks like a label to a sighted designer, because the grey text sits inside the box where a label would sit. To a screen reader, the placeholder is nothing: it is not exposed as the accessible name, and when the user starts typing, the placeholder disappears, taking the only hint with it. WCAG 2.2 Success Criterion 3.3.2, Labels or Instructions, requires that labels or instructions are provided when content requires user input. A discount code field with only a placeholder fails it, plainly, and the fix is one line of markup: a real label element, associated with the input by its id.

The WebAIM Million 2025 report keeps finding the same pattern at scale: missing form labels are among the most common detectable failures on the home pages it scans, and checkout forms are worse than home pages, because the discount field is usually added late, by a different team, as a collapsible section that never went through the same review as the rest of the form. The field that saves the shopper money is the field that gets the least accessibility attention, and the shopper who needs the label most is the one who loses the discount.

## The collapsible section makes it worse

Most discount fields hide behind a link that says "Have a promo code?" Clicking it reveals the input. For a keyboard user, the reveal has to move focus into the input, or the user has to tab forward and guess where the field appeared. For a screen reader user, the reveal has to announce that the field is now present, or the user tabs past the link and never finds what it opened. The pattern fails in three places at once: the link is often a div with a click handler instead of a button, the revealed input has no label, and the focus never moves. Each failure is a one-line fix. Together they are a checkout that charges full price to the people who can least afford to lose a discount.

[The country selector fails the same way](https://cartcomply.com/blog/2026-11-14-checkout-country-selector-keyboard-trap.md): a dropdown keyboard users cannot escape, built the same way, by the same shortcut, for the same reason. [The error summary has the same focus problem](https://cartcomply.com/blog/2026-11-12-checkout-error-summary-focus-keyboard.md): the focus move that decides whether keyboard users ever hear the error. Checkout accessibility is not one big fix. It is a dozen one-line fixes, and the discount field is the one most stores have never done.

## Test it the way the user does

Open your checkout, turn on a screen reader, and tab to the discount field. If it announces "edit text, blank" with no name, it fails. If it announces "promo code, edit text," it passes. The test takes thirty seconds and it is the test the shopper runs every time they check out with a code in their pocket. Run it before the next deploy, not after the complaint, because the complaint arrives as a lost sale and a customer who does not come back, not as a bug report.

The fix, for the record: a visible label, associated with the input, that stays visible when the field has a value. The placeholder can stay as a hint. It cannot stay as the label.

## Frequently asked questions

### Why does a placeholder not count as a label?

Because a screen reader does not expose placeholder text as the accessible name of the input, and the placeholder disappears as soon as the user types. WCAG 2.2 Success Criterion 3.3.2 requires a label or instructions for user input, and a placeholder alone does not meet it. Use a real label element tied to the input by id.

### My discount field is inside a collapsible section. Is that a problem?

Only if the reveal is not announced and focus does not move. Use a real button for the toggle, move focus into the revealed input, and make sure the input has a label. If the section opens silently and the user has to guess where the field went, keyboard and screen reader users will miss it.

### Does the label have to be visible?

A visible label is the safest choice, because it helps everyone, including sighted users who forget what the field was for. A visually hidden label that is still exposed to assistive technology passes the criterion, but the visible label is the one that survives every audit and every user test.

### How do I test the discount field myself?

Turn on a screen reader, tab through checkout, and listen for the field's name. If it announces only "edit text, blank," it has no accessible name and it fails. If it announces the label, it passes. The whole test takes under a minute.