Accessible Gift Card Flows: Buying, Sending, and Redeeming Without a Trap

November 4, 2026

Gift cards touch three separate flows and each one has its own accessibility failure: buying the card, delivering it by email, and redeeming a code at checkout. A walk through all three.

A gift card looks like the simplest product a store sells. No size, no shipping, no returns. Then a shopper tries to send one to a named recipient, types a message, and finds the delivery date field is a calendar widget they cannot operate with a keyboard. Or the buyer is the recipient, in December, pasting a long code into checkout and getting a single error: invalid. No hint which character is wrong, and the field clears itself on reload.

Gift cards fail at the seams between flows. Buying is a product page, delivery is an email and a web page the recipient opens weeks later, and redemption is a payment step under time pressure. Audit them as three journeys, because a fix in one does nothing for the other two.

Buying: amounts, recipients, and the date picker

Preset amounts as radio buttons work well. A custom amount field next to them is where labels go missing, where a dollar sign inside the field is read as part of the value, and where minimum and maximum limits are stated only in a tooltip. Put the limits in text beside the field. If the card runs from 10 to 500 dollars, say so there, not after a failed submit.

Recipient name, recipient email, sender name, and a message box each need their own persistent label, not a placeholder. Email delivery also needs a plain warning that the card goes to the address typed, because a typo sends store credit to a stranger and support cannot claw an email back. A confirmation step showing the address before payment is cheap and prevents the worst version of that mistake.

Redeeming: the code field is a payment field

Treat the code like a card number. Accept it with spaces and hyphens stripped in code rather than punishing the shopper for copying it exactly as printed. Do not clear the field after a failed attempt. Do not limit paste, and do not add autocomplete attributes that invite a browser to fill the discount box with the gift card code, or the reverse.

Error text has to say something usable. Code not recognised, code already fully spent, and code not yet active are three different problems with three different next steps, including showing the remaining balance when a code worked but did not cover the order. WCAG 3.3.1 Error Identification and 3.3.3 Error Suggestion both point the same way: name the field, name the problem, suggest the fix.

Balance checking without an account wall

Many stores hide balance checking behind account creation. That is a business choice, but if a balance checker exists it should work without a mouse, announce the balance as text rather than rendering it as an image, and never ask for the full code plus an email plus a phone number to show a number the holder is entitled to see.

Watch session timeouts on this page in particular. WCAG 2.2.1 Timing Adjustable is easy to break with a silent timeout that logs the holder out mid check and discards the code they typed. Warn before expiry, and keep entered data when a session is extended. A gift card balance is small money, but it is the holder's money, and losing it to a timeout reads as theft to the person it happens to.

Related reading: Accessible Address Autocomplete and Lookup Fields at Checkout, Accessible Subscription Pause, Skip, and Cancel Controls, Accessible Password Creation: Where Signup Forms Lock People Out.

Frequently asked questions

Does a gift card code field need a visible label?

Yes. Gift card or promo code as placeholder text disappears on typing and is not a label. Use a real label tied to the input, and if two code types share checkout, label each field separately so a screen reader user can tell the discount box from the gift card box.

Should gift card emails be accessible too?

Yes. The delivery email is the product for an emailed card. The code should be selectable text, not baked into an image, the amount and expiry should be in the email body, and the redeem link needs descriptive text rather than a bare click here.

Do gift cards need an expiry warning?

If the card expires, state the date at purchase, in the delivery email, and on the balance page. Burying expiry in terms text is a common complaint, and in several jurisdictions expiry and fees on gift cards are regulated, so legal and accessibility advice should be checked together.

Can I require an account to redeem a gift card?

You can, but test that journey hard. Account creation at checkout, with a card already in hand, is where abandonment and support tickets concentrate. If redemption needs sign in, say so on the balance page before the shopper reaches payment.

Find out where your store stands

Get a free accessibility audit

Frequently asked questions

What is the main takeaway from What should an agency check in a Shopify theme before promising accessibility??

The main takeaway is to work through the basics in order, check each step as a real user would experience it, and fix patterns at their source rather than patching a single example. A short written record of what you checked makes the next review faster and more reliable.

How should I apply this guide in practice?

Pick one page, product, or routine and apply the steps there first. Note what changes, keep the change if the result improves, and only then roll the same pattern wider. Small verified changes beat a large unverified overhaul every time.

What should I check again later?

Recheck after any template, product, app, or routine change, and on a regular monthly rhythm in between. Conditions drift over time, so a dated check is what tells you whether a fix held or quietly broke again.