Accessible Wishlists and 'Save for Later' Buttons: The Little Heart Icon That Locks People Out

Almost every online store now has some version of it: a little heart icon on each product, a “Save for later” link under an item in the cart, or a “My Favorites” list a shopper can come back to. These features are quietly powerful. People use wishlists to plan purchases, compare options, wait for a payday, or share ideas with a partner. For a lot of stores, saved items turn into sales days or weeks later.

But that same tiny heart button is one of the most common places where a store accidentally locks people out. It is small, it is often icon-only, and its whole job is to change state — from “not saved” to “saved” and back again. State changes are exactly the kind of thing that assistive technology needs to be told about clearly. When they are not, a shopper using a screen reader taps the heart, hears nothing meaningful, and has no idea whether the item was saved, removed, or nothing happened at all.

This guide walks through what usually goes wrong with wishlists and “save for later” features, and how to check and fix them — in plain language, no coding background needed. If you can use your keyboard and turn on a screen reader for five minutes, you can find most of these problems yourself.

Why wishlists trip up accessibility so often

Three things make save features unusually risky compared to, say, a block of text or a normal link.

They are usually icon-only. A heart, a bookmark, a star. There is no visible word like “Save” next to it, so the button’s meaning lives entirely in a picture. A screen reader cannot interpret a picture. If nobody has given that button a text label behind the scenes, a screen reader may announce it as “button” with no other information, or read out a filename, or say nothing useful at all.

They toggle between two states. The heart means “save this” when the item is not saved, and “remove this” when it already is. Sighted users see the heart fill in with color to show the change. But color and a filled-in shape are visual signals. If the button does not also tell assistive technology that it is now “pressed” or “saved,” a blind shopper has no way to know the click worked.

The confirmation is often a fleeting visual toast. Many stores pop up a little message — “Added to your wishlist” — in the corner for two seconds and then fade it away. If that message is not announced to a screen reader, and it disappears before anyone can find it, the confirmation effectively does not exist for a big group of your customers.

None of these are exotic edge cases. They are the default behavior of a lot of themes, apps, and plugins. Which means most stores have at least one of these problems right now.

The four places to check

1. The save button itself needs a real, descriptive name

Every heart, star, or bookmark button needs a text label that a screen reader can read, even if no text is visible on screen. The label should describe the action, not just the icon. “Add to wishlist” is good. “Heart” is not.

The label should also reflect the current state. When an item is already saved, the button’s job flips to “remove,” so its name should too — for example, “Remove from wishlist.” A shopper navigating by screen reader should be able to land on that button and immediately understand both what it does and whether the item is currently saved.

How to test it yourself: Turn on your device’s built-in screen reader (VoiceOver on Mac and iPhone, TalkBack on Android, Narrator on Windows). Move focus to the heart button without clicking. Listen to what it says. If you hear something like “Add to wishlist, button,” you are in good shape. If you hear “button,” “unlabeled,” a filename, or dead silence, the button has no accessible name and needs one.

2. The button must work with a keyboard

Plenty of people never touch a mouse — because of a motor disability, a tremor, low vision, or simply preference. They navigate with the Tab key to move between controls and Enter or Space to activate them.

A save button has to be a real, focusable button for this to work. A common failure is a heart that is really just a picture with a click handler stuck on it. A mouse can click it, but the Tab key skips right past it, so keyboard users can never reach it.

How to test it yourself: Put your mouse away. Press Tab repeatedly and watch where the highlight goes. Can you land on the save button? When you do, is there a clear, visible outline showing it has focus? And when you press Enter or Space, does it actually save the item? If Tab never reaches the heart, or you cannot tell where the focus is, that is a barrier — and it is one of the most common ones we see.

3. Saving something must be announced

This is the big one. When a shopper saves or removes an item, three groups of people need to know it worked: people who can see the color change, people who rely on a screen reader, and people who navigated there by keyboard and are not looking at the corner of the screen.

There are two solid ways to communicate a save, and the best stores use both:

  • Update the button itself. The moment an item is saved, the button’s name changes to reflect the new state (“Remove from wishlist”) and its “pressed” or “saved” status is exposed to assistive technology. A screen reader user who re-checks the button hears the change.
  • Announce a short confirmation politely. A brief message like “Saved to your wishlist” is placed in a region that screen readers watch and read aloud automatically, without stealing focus. That way the confirmation is spoken, not just flashed.

How to test it yourself: With the screen reader on, activate the save button and listen. Did you hear a confirmation, or did the button’s label change from “Add” to “Remove”? Silence means the action is invisible to the very people who most need feedback that their tap did something.

Also check the flip side: if a store shows a count — “Wishlist (3)” in the header — make sure that number is not the only signal. A screen reader user is not staring at your header waiting for a badge to tick up.

4. The wishlist page has to be usable, not just the button

Getting an item onto the list is only half the job. The saved-items page itself needs the same care as any product listing.

Look for these on your wishlist or “saved items” page:

  • Every item is clearly identified. Product name, price, and key details are readable text, not just an image. If a saved item is only a photo, a screen reader shopper cannot tell one saved item from another.
  • “Remove” buttons say what they remove. A row of identical “Remove” buttons is confusing out of context. Each should communicate which product it removes, for example “Remove blue running shoes from wishlist.” When an item is removed, that change should be announced too, and focus should not get dumped somewhere random.
  • The empty state makes sense. When the list is empty, the page should say so in plain words — “Your wishlist is empty” — not just show a blank area with a faint graphic.
  • “Move to cart” actually works by keyboard. Many wishlists include a quick “Add to cart” on each saved item. Confirm it is reachable by Tab and that adding to the cart is announced, just like on a product page.

It is tempting to treat wishlists as a nice-to-have and skip the accessibility work. Two reasons not to.

First, saved items are high-intent. Someone who bothered to save a product is telling you they are seriously considering it. If a chunk of those shoppers — and roughly one in four adults has a disability — cannot reliably save, find, or check out their saved items, you are losing sales from the warmest part of your audience.

Second, accessibility is not optional in the way it used to be. In the United States, the Americans with Disabilities Act has been the basis for thousands of lawsuits over inaccessible online stores, and broken interactive controls — buttons that a screen reader cannot identify or a keyboard cannot reach — are a frequent complaint. Across the European Union, the European Accessibility Act now requires many e-commerce services to meet accessibility standards, and “interactive elements have no accessible name” is precisely the kind of finding that shows up in an audit. A heart button that fails silently is a small piece of interface with a surprisingly large amount of exposure. (This is general information, not legal advice — talk to a qualified professional about your specific situation.)

The good news is that these are among the easiest accessibility issues to fix. A save button needs a clear text label, needs to be a real button you can reach with Tab, and needs to announce when it toggles. None of that requires rebuilding your store. It is usually a matter of adding the right labels and a small confirmation message — work most theme developers or app support teams can do quickly once you point to the exact button.

A five-minute self-check

Before you close this tab, try this on your own store:

  1. Turn on your device’s screen reader.
  2. Tab to a product’s save button. Does it announce a clear name like “Add to wishlist”?
  3. Activate it with Enter or Space. Did you hear a confirmation, or did the button’s label change?
  4. Go to your wishlist page. Can you tell the saved items apart, and do the “Remove” buttons say what they remove?
  5. Empty the list. Does the page clearly say it is empty?

If any step leaves you unsure, you have found a real barrier — and now you know exactly what to send to whoever maintains your site.

We’re building a simple accessibility checker for non-developers — no DevTools, no jargon. Join our waitlist to get early access.