Reviewed October 20, 2026

Icon buttons need names: cart, search, and account done right

The header icons every shopper uses are unlabeled buttons to a screen reader unless someone names them. How icon buttons fail, the naming pattern that works, and a quick audit of your header and product cards.

The most used buttons on your store have no text

Your header's search, account, and cart controls, the wishlist hearts and quick add buttons on product cards, and the social icons in the footer are pictures with jobs. A screen reader cannot interpret the picture; it announces whatever name the markup gives the button, and when nobody provided one, it announces simply button, or worse, reads a file name or a string of icon font characters.

Shoppers who cannot see the icons navigate by these names. A header that announces button, button, button with a badge number is a guessing game at the exact controls every visit uses. This is among the most common automated scan findings on storefronts, and among the cheapest to fix permanently, because the buttons live in a handful of shared theme files.

What a good name looks like

The name should say what the button does and include the dynamic facts a sighted shopper sees. Search is search. The cart button should announce cart and the item count, so cart, 3 items, updating as the count changes. Wishlist toggles should announce their state: add to wishlist versus remove from wishlist, not the same wordless heart in both directions.

Visible text, when it exists, should match the accessible name, because voice control users speak the label they see. When the icon stands alone, the name is usually supplied by an aria label or visually hidden text inside the button. Links and buttons are not interchangeable here: an icon that navigates is a link, an icon that acts is a button, and naming the element correctly is part of naming it at all.

Auditing your header and cards

Run an automated accessibility scan on your homepage and one product page and filter for button name and link name violations; the scanner will hand you the list. Then verify with a screen reader on the header alone, listening to what each icon announces in sequence. It takes ninety seconds and the result is usually embarrassing in a productive way.

Check the places themes forget: the mobile menu's close icon, the search overlay's submit and clear buttons, quantity plus and minus steppers, the remove item icon in the cart, and any icon an app injects, like a rewards launcher or chat bubble. App injected buttons are frequent offenders because the app's developer never saw your store's audit.

Fixing once, in the shared places

Because these controls are rendered by shared snippets, one fix repairs every page: name the buttons in the header, card, and cart templates, and set the cart count to update its announcement. Ask your theme vendor or developer for exactly that, with your scan results attached, and it is a small ticket. For app widgets, send the vendor the same evidence; reputable ones fix labels quickly, and the answer tells you something about the vendor.

Add a line to your theme change checklist: any new icon control ships with a name or does not ship. Accessibility debt on storefronts is mostly recurrence, and a one line gate at the point of change is cheaper than a quarterly cleanup of mystery buttons.

Related reading

If this topic is useful, these earlier guides go deeper on connected questions: Accessible Shopify product videos: captions, transcripts, and controls, Keyboard navigation for Shopify mega menus, tested properly, and Color contrast on sale badges and product labels that everyone can read.

Frequently asked questions

How do I check what my cart button announces?

Turn on a screen reader, free ones exist on every platform, navigate to the header by landmarks or by tabbing, and listen to the cart control. It should say cart and the number of items. You can also run an automated scan and look for button name violations, which list the exact elements missing names.

Should the accessible name match any visible label?

Yes, when text is visible, because voice control users activate controls by speaking the visible words, and a mismatch breaks that path. When there is no visible text, as with pure icons, the name should describe the action plainly in the words a shopper would use: search, account, cart with its count.

Do decorative icons need names too?

No. Purely decorative icons should be hidden from assistive technology and carry no name, so they do not add noise. The distinction is function: if clicking it does something or goes somewhere, it needs a name; if it merely accompanies text that already says everything, it should be silent.

An app added an unnamed chat button. Whose problem is it?

Yours to raise, theirs to fix. Send the vendor the scan evidence and the announced result. Most reputable app developers will patch an accessible name promptly. If they will not, that is material information when the app comes up for renewal, and a factor in whether it stays on your store.