Accessible Loyalty Points and Rewards Dashboards

Points balances shown as graphics, tiers shown as progress bars, rewards that need a mouse to redeem. Making a loyalty dashboard readable, operable, and honest for everyone.

A loyalty dashboard compresses a shopper's whole relationship with a store into numbers: points earned, points expiring, a tier, a distance to the next reward. Those numbers are often delivered as an image, a circular progress graphic, or a bar with no text equivalent. A screen reader user opening the same page may hear the word rewards and then very little that tells them what they actually have.

The information is not decorative, which is the test that matters. A points balance decides whether a shopper places an order today or waits. Points expiring at the end of the month decide it faster. Information that changes a purchase has to be available as text, in the reading order, announced the same way for everyone.

Give every graphic its number in text

Start with the progress visual, because it is the worst offender. A ring showing 70 percent of the way to a reward needs a text version next to it: 700 of 1,000 points, 300 points to your next reward. That sentence does everything the ring does and it works with every technology, including a small screen with images off. If the text exists and the graphic is marked decorative, the page passes and reads better for sighted shoppers too.

Expiry is the second item and it is the one stores most often soften. Points expire in 12 days buried in a tooltip that opens on hover is not information a keyboard user can reach, and it is not good service for anyone. Put the expiry date in the main balance text. It is the single most actionable fact on the page, and hiding it behind an interaction is a choice with an obvious beneficiary.

Redeeming should not require precision pointing

Reward selection is often built as a row of cards or a slider: drag to choose how many points to spend. Sliders are a known weak point. A slider needs to be keyboard operable with arrow keys, its current value and limits need to be announced, and there should be a plain alternative, an input where the shopper types the amount, or buttons for the set reward values.

Check the confirmation step as carefully as the selection. Redeeming points is an irreversible action in many programmes, so the review text, you are spending 500 points for 5 dollars off, should appear before the commitment and be reachable in the reading order, not only as a visual change to a total that a screen reader may never revisit.

Tables, history, and the tier rules

Points history is tabular data and should be marked up as a table with headers: date, activity, points. A history built as styled divs reads as an undifferentiated stream of numbers where a shopper cannot tell an earning entry from an expiring one. The fix is semantic and unglamorous, and it is what makes the history usable rather than merely present on the page.

Tier rules deserve the same plain treatment. How points are earned, what makes them expire, and what each tier adds should be in ordinary text on the page, not only in a downloadable PDF or an expandable section whose button has no name. A shopper deciding whether a programme is worth joining is making that decision from exactly that text.

Related reading: Accessible Gift Wrapping, Gift Messages, and Receipt Options, Accessible Pre-Order Deposits and Balance Payment Pages, Accessible Preorder and Deposit Flows: Dates, Balances, and Honest Timers.

Frequently asked questions

How should a points progress bar be made accessible?

Give it a complete text equivalent in the reading order, such as 700 of 1,000 points earned and 300 points remaining to the next reward, and mark the visual bar itself as decorative or give it an appropriate role and value.

Where should a points expiry date appear?

In the main balance text on the dashboard, in plain view. Burying expiry in a hover tooltip makes it unreachable for keyboard users and easy for everyone else to miss until the points are gone.

What makes a points slider accessible?

It must work with arrow keys, announce its current value along with its minimum and maximum, and ideally be paired with a direct input or set value buttons. A drag only slider excludes a wide range of users.

Should points history be a real table?

Yes. Date, activity, and points are columnar data with relationships a shopper needs to follow. Proper table headers let assistive technology announce each value with its column, instead of a stream of disconnected numbers.