Watching Wishlist and Save for Later Controls Drift
Heart icons with no accessible name, wishlist buttons that announce nothing, and save for later controls that vanish for keyboard users. What to watch on product grids and carts.
The wishlist heart is the smallest control on the product grid and the one most likely to have no name at all. To a screen reader it announces as button, or as a string of SVG markup, or as the word image. The shopper cannot tell what it does, whether it is already pressed, or which product it belongs to on a grid of twenty near-identical cards.
Save for later carries the same problems into the cart, with higher stakes. Moving an item out of the cart is a destructive-feeling action. If the control is an unlabelled icon and the result is not announced, a keyboard or screen reader user can lose an item from their order and have no idea which step did it.
A toggle has to say what state it is in
A wishlist button is a toggle, so it needs two things: a name that identifies the product, save trail shoe to wishlist rather than a bare favourite, and a pressed state exposed through aria-pressed or an equivalent pattern. Without the state, every heart on the grid reads identically and the user builds a list they cannot review. With the state, the wishlist becomes a tool a screen reader user can actually manage.
Watch the grid after filtering too. When results reload, some themes rebuild the cards and drop the pressed state from the markup, so an item the shopper saved an hour ago renders as unsaved. The wishlist page has it. The grid does not. That mismatch is a template bug, and it is exactly the kind that only shows up if someone watches the control across sessions rather than testing it once on a clean page.
Save for later must announce its result
When an item moves out of the cart, three things change at once: the item list, the subtotal, and the saved list somewhere below or on another page. A status announcement covering the move, item name and where it went, is what makes that recoverable. WCAG 4.1.3 covers the announcement. The undo path covers the mistakes, and a save for later control without an easy move back is a trap wearing a convenience feature's clothes.
Also watch the focus. Removing the element that has focus drops the user at the top of the page in many browsers. After a save for later action, focus should land on the next logical place, usually the cart heading or the following item, and the announcement should confirm the new subtotal while it is at it.
What to put on the watch list
Once a month, on one grid and one cart: every wishlist toggle has a unique name and a working pressed state, the state survives filtering and a return visit, save for later announces the move and the new subtotal, focus lands somewhere sensible afterwards, and move back to cart works with keyboard alone. Five checks. Wishlist features get rebuilt by app updates and theme changes more often than almost anything else on a store, because half the time an app, not the theme, owns the button.
Related reading
If this topic is useful, these earlier guides go deeper on connected questions: Watching Homepage Carousels: Autoplay, Pause, and Focus Order, Watching Checkout Progress Indicators That Screen Readers Miss, and Watching Loyalty Popups That Appear Right After Login.
Frequently asked questions
What should a wishlist button be called for screen readers?
A name that identifies the product and the action, like save trail shoe to wishlist, plus a pressed state through aria-pressed so users can tell saved items from unsaved ones.
Why does the wishlist state disappear after filtering?
Some themes rebuild product cards when results reload and drop the pressed state from the new markup. The wishlist itself still holds the item, so the grid and the list disagree until the template is fixed.
Does save for later need an announcement?
Yes. Moving an item changes the list and the subtotal, and a status message naming the item, where it went, and the new total is what makes the action understandable and recoverable.
Where should focus go after saving an item for later?
To the next logical place, typically the cart heading or the following cart item. Leaving focus on a removed element dumps the user back at the top of the page.