Accessible Gift Cards: Buying, Sending, and Redeeming
Gift card flows involve codes, balances, and redemption fields where small barriers lock value away. How to make every stage usable.
A gift card is money in a locked box, and the lock is a web flow. Buying one involves recipient forms and delivery choices. Redeeming one involves a long code, a balance check, and an apply button whose result is easy to miss if it is only shown visually.
Each stage fails in familiar ways. This guide covers the buying, sending, balance, and redemption journeys, and the confirmations that make stored value feel safe for every shopper.
Make buying and sending straightforward
Recipient name, email, message, amount, and delivery date fields each need real labels and errors in text. Amount selection offered only as tappable tiles should also work as radio options with announced values, including the custom amount field.
The confirmation should state, in text the buyer can review, the amount, the recipient, and the delivery method and date. Gift purchases are often one off and emotionally loaded. A vague success message produces support calls and duplicated orders.
Codes must be readable and typeable
Redemption codes in emails and on cards should be selectable text in a clear format, grouped so they can be read aloud and typed accurately, not only an image of a card. An image only code excludes screen reader recipients from their own gift.
On the redemption field, accept pasted codes, ignore spaces gracefully, and put errors in text that says what is wrong: code not recognised, already redeemed, or not yet active. An error that only shakes the field tells the shopper nothing except that the store disagrees.
Announce balance and application clearly
When a card is applied, the result must be stated: the amount applied, the remaining total, and any balance left on the card. Those three numbers are the transaction, and they should be readable text, announced to assistive technology, and repeated at order review.
Balance checking needs the same care. The checker should confirm the balance and currency in text, handle partial balances plainly, and never require the full card number to be retyped where a signed in account could list saved cards.
Do not strand value behind expiry surprises
Expiry and dormancy terms should be stated at purchase and on the balance page in plain language, where local rules allow them at all. Value that quietly expires is a complaint and a review waiting to happen, whatever the terms say.
Test the whole loop quarterly with a small real card: buy, send, receive, check balance, redeem partially, check the remaining balance. Gift card systems change with payment and fraud updates, and the full loop is the only test that covers every handoff.
Related reading
If this topic is useful, these earlier guides go deeper on connected questions: Accessible Product Bundles and Gift Sets, Making Delivery Slot Pickers Accessible, and Accessible Star Ratings and Review Widgets.
Frequently asked questions
Why do gift card codes need to be real text?
Because an image only code cannot be read by a screen reader, selected, or copied. The recipient of the gift is locked out of its value by the format, before any question of the code itself.
What should applying a gift card confirm?
Three numbers in readable text: how much was applied, what total remains to pay, and what balance stays on the card. Those should be announced and repeated at review, not only shown as a changed total.
How should code errors be written?
Specifically: not recognised, already redeemed, or not yet active, with a next step for each. A generic invalid code message sends shoppers with valid cards into support queues.
How often should gift card flows be tested?
Quarterly, end to end with a real low value card. Payment, fraud, and email systems around gift cards change often, and only a full loop test crosses every handoff.