Accessible Wishlist and Saved Items Pages
Wishlist pages collect add, remove, move to basket, and sharing controls in dense grids. How to keep saved items pages clear for keyboard and screen reader shoppers.
A wishlist is where shoppers park decisions. It is also a page of repeating cards, each with the same buttons: remove, add to basket, notify me. Repetition without naming is where screen reader users lose track of which product a button belongs to.
Wishlist pages rarely get audited because they sit behind accounts. This guide covers the patterns that keep them usable: named controls, announced changes, and prices and stock states that exist as text.
Name every control with its product
A dozen buttons labelled remove tell a screen reader user nothing. Each control should carry the product name in its accessible label, remove the wool jumper, add the wool jumper to basket, so the list of controls reads as a list of choices.
The same rule covers image links and product titles. Where a card links from both image and title, make sure the destination and purpose are clear and that duplicate links do not create a maze of identical announcements.
Announce adds, removals, and stock changes
Removing an item, moving it to the basket, or a saved item going out of stock are state changes the shopper must hear about. A confirmation in text, plus focus handled sensibly when a card disappears, prevents the common failure where focus vanishes to the top of the page.
Stock and price changes on saved items should be stated plainly on the card. A wishlist that quietly shows a higher price at basket time than it showed on the saved page erodes trust for every shopper.
Keep sharing and lists manageable
Sharing a wishlist, by link or email, needs labelled fields and a confirmation that can be read. Multiple lists, gifts, later, ideas, need headings and controls that say which list is being edited, renamed, or deleted.
Empty states deserve the same care: a wishlist with nothing saved should say so in a heading or clear text and offer a route back to shopping, not present a blank grid area that looks like a loading failure.
Test signed in pages on the audit list
Put the wishlist on the standard test rotation, signed in, with items saved, including one out of stock item. Test add to basket, remove and undo where offered, and sharing, by keyboard and screen reader.
Account area templates change during redesigns that focus on the public storefront. The wishlist inherits those changes untested unless someone deliberately includes account pages in the release checklist.
Related reading
If this topic is useful, these earlier guides go deeper on connected questions: Making Size Charts and Fit Guides Accessible, Accessible Loyalty Program Pages and Points Displays, and Colour Contrast for Sale Badges and Promo Labels.
Frequently asked questions
Why do wishlist buttons need product names?
Because a page of identical buttons labelled remove or add gives a screen reader user no way to know which product each acts on. Naming the product in each label makes every control self describing.
What should happen when an item is removed?
The removal should be confirmed in text, focus should move somewhere sensible rather than vanishing, and an undo route is good practice. Silent removal leaves shoppers unsure whether the click worked.
Should price changes on saved items be flagged?
Yes. If a saved item costs more or less than when it was saved, or has gone out of stock, that should be stated on the card in text, not discovered at checkout.
Why are wishlist pages often missed in audits?
Because they require an account and saved state, so crawl based audits never see them. They need deliberate signed in testing, by keyboard and screen reader, on the regular rotation.