Icon Buttons Without Labels: Fixing Cart, Search and Menu Icons

Updated October 23, 2026 · 6 min read

Cart, search and menu icons are easy for sighted visitors to recognize. For someone using a screen reader, an icon with no text alternative may be announced only as "button" or "link", with no hint of what it does. Automated scanners flag this often, and it is usually quick to fix.

This guide explains why it happens, shows several reliable fixes, and covers how to check the result yourself. It is general information, not legal advice. For legal questions, talk to an attorney.

Why unlabeled icon buttons get flagged

Assistive technology builds an "accessible name" for each interactive element. A screen reader reads that name aloud, and voice-control software uses it so people can say "click search." If the name is empty, the control is effectively anonymous.

Two WCAG 2.1 success criteria are usually involved:

• WCAG 4.1.2 Name, Role, Value requires that user interface components, including buttons, expose a name and role that software can determine.
• WCAG 2.4.4 Link Purpose (In Context) requires that the purpose of a link can be determined from the link text or its context.

Related issues, such as images missing text alternatives, fall under WCAG 1.1.1 Non-text Content.

What a typical failing icon button looks like

Here are three common patterns that produce empty names:

<!-- Button containing only an icon font glyph -->
<button class="icon-search"></button>

<!-- Button containing only an SVG with no title or label -->
<button>
  <svg viewBox="0 0 24 24"><path d="M15.5 14h-.8..."/></svg>
</button>

<!-- Link wrapping an image with empty alt -->
<a href="/cart"><img src="cart.png" alt=""></a>

Each of these looks fine on screen. Each may be announced with no useful name.

Fix 1: Visually hidden text

Adding text that is hidden visually but still available to assistive technology is a dependable approach. The text is part of the page, so it can also be translated and read by voice-control tools.

<button type="button">
  <svg aria-hidden="true" focusable="false" viewBox="0 0 24 24">
    <path d="M15.5 14h-.8..."/>
  </svg>
  <span class="visually-hidden">Search</span>
</button>

A common utility class looks like this:

.visually-hidden {
  position: absolute;
  width: 1px;
  height: 1px;
  margin: -1px;
  padding: 0;
  overflow: hidden;
  clip-path: inset(50%);
  white-space: nowrap;
  border: 0;
}

Avoid display: none or visibility: hidden for this text. Both remove the content from the accessibility tree, so it will not be announced.

Many themes and frameworks already include a similar class, often called sr-only or screen-reader-text. Check yours before adding a new one.

Fix 2: aria-label

When there is no visible text, aria-label provides a name directly on the element:

<button type="button" aria-label="Open menu">
  <svg aria-hidden="true" focusable="false" viewBox="0 0 24 24">
    <path d="M3 6h18M3 12h18M3 18h18"/>
  </svg>
</button>

It is short and easy to apply. There are tradeoffs to keep in mind:

• Some browser translation tools handle aria-label less consistently than visible page text.
• Use it on elements that have a role that supports naming, such as buttons and links. Putting it on a plain div or span is unreliable.
• If the button also has visible text, the accessible name should contain that visible text. This matters for voice-control users, who speak the label they see.

Either hidden text or aria-label is acceptable. Pick one per control rather than stacking several naming methods.

Fix 3: SVG icons

Inline SVGs are a frequent source of confusion. The simplest pattern is to treat the SVG as decoration and let the button supply the name:

• Add aria-hidden="true" to the <svg> so it is not announced separately.
• Add focusable="false" to avoid an extra tab stop in some older browsers.
• Put the name on the <button> or <a>, using hidden text or aria-label.

If you prefer to name the SVG itself, you can use role="img" with <title> and aria-labelledby. That approach is less consistent across screen readers, so naming the parent control is generally the safer choice.

For icon fonts, apply the same idea: hide the glyph from assistive technology with aria-hidden="true" and provide the name on the parent element.

Fix 4: Links that wrap only an image

A linked logo or cart image takes its accessible name from the image's alt text. An empty alt="" tells assistive technology to ignore the image, which leaves the link nameless.

<!-- Better: alt describes the link's destination or action -->
<a href="/cart">
  <img src="cart.png" alt="Cart, 2 items">
</a>

<!-- Logo linking home -->
<a href="/">
  <img src="logo.svg" alt="Example Store home">
</a>

Write the alt text to describe where the link goes or what it does, not what the picture looks like. "Cart" is more useful than "shopping cart icon." For product photos and other informational images, see how to write alt text for product images.

If the same link also contains visible text, the image can often be marked decorative with alt="" because the text supplies the name.

Common icons and sensible names

Where a control toggles something, such as a mobile menu, consider aria-expanded="true" or "false" on the button so its state is conveyed too. Keep the name stable ("Menu") rather than changing it between states, since the state is already announced.

How to check the accessible name in dev tools

You do not need a screen reader to find most of these problems.

1. Open the page in Chrome, Edge or Firefox.
2. Right-click the icon and choose Inspect.
3. Open the Accessibility tab or pane. In Chrome, it sits alongside the Styles and Computed panes.
4. Find the Name field for the selected element. It should show a meaningful label.
5. Check the Role field as well. It should read "button" or "link" as appropriate.

If Name is empty, the control is unlabeled. Many browsers also let you view the full accessibility tree, which makes it easier to scan a whole header.

Automated checkers can catch empty names but cannot judge whether a name is helpful. A label like "icon1" passes an automated check and still fails real users. For a hands-on check, try a screen reader; the screen reader testing basics guide covers VoiceOver and NVDA. A quick keyboard test also helps confirm the icons are reachable and show visible focus.

Common mistakes to avoid

• Using title alone. The title attribute is inconsistently exposed and is not available to touch or keyboard users in the same way. Do not rely on it as the only label.
• Making clickable div or span elements. Use a real <button> or <a> so the role and keyboard behavior come built in.
• Duplicate or vague names. Several controls all named "Button" or "Link" give no way to tell them apart.
• Overly long labels. Keep names short and specific.
• Labeling the icon and the button. If both the SVG and the parent carry names, screen readers may read the label twice.

Where this fits in a wider review

Unlabeled icons are one of several common automated findings. The WCAG 2.1 AA checklist gives a broader view of what to review, and the WCAG fix guides cover individual criteria in more detail. If you use a page builder or theme, the labels may be controlled by template files, so see the WordPress accessibility guide or the Wix and Squarespace guide for platform-specific notes.

For official background, the W3C publishes the WCAG 2.1 specification and the ARIA Authoring Practices Guide, which covers button patterns.

If you want a starting point, you can run a free scan to see which controls are currently flagged, then work through them one by one. Fixing labels does not by itself make a site compliant, and it does not guarantee protection from a claim. If you have received a demand letter, see what to do in the first two weeks and consider speaking with an attorney.

Frequently asked questions

Should I use aria-label or visually hidden text?

Both give a button an accessible name, and either is acceptable. Visually hidden text tends to be handled more consistently by translation tools, while aria-label is shorter to write. Choose one method per control and keep the name consistent across the site.

Do decorative icons need alt text or a label?

A purely decorative icon does not need a name of its own. If it sits inside a button or link that already has a name, mark the icon aria-hidden="true" or use alt="" on an image. The parent control still needs a clear name.

Why does my scanner flag a button that has a title attribute?

The title attribute is not a dependable way to name a control, and some tools do not treat it as a sufficient label. Replace it with visible text, visually hidden text or aria-label. You can keep title as an optional tooltip if you want one.

How do I know the name I chose is a good one?

Describe the action or destination in a word or two, such as "Search," "Cart" or "Open menu." Then listen to it with a screen reader or read it in the browser's Accessibility pane. If it makes sense without seeing the icon, it is probably fine.

Does fixing icon labels protect me from an ADA claim?

No single fix can promise that. Labeling icons addresses specific, commonly flagged issues, but a website can have many other barriers, and courts do not all treat these claims the same way. For legal questions about your situation, consult an attorney.

Related

• WCAG 4.1.2 Name, Role, Value
• WCAG 2.4.4 Link Purpose (In Context)
• Screen Reader Testing for Business Owners: VoiceOver and NVDA Basics
• WCAG 2.1 AA checklist for business websites

Proof of Access provides technical accessibility assessments. We are not a law firm and nothing on this page is legal advice. If you have received a demand letter or a lawsuit, talk to an attorney.