Reviewed November 8, 2026

Icon-Only Buttons With No Name: The Silence Screen Reader Users Hear

Your cart button is a shopping bag icon. Your search button is a magnifying glass. Your menu button is three lines. To a sighted shopper, all three are obvious. To a screen reader, all three are the same word: button.

An icon-only button with no accessible name is silent about what it does, and WCAG 4.1.2 Name, Role, Value requires every user interface component to expose a name that assistive technology can read. The fix is one attribute, and the stores that skip it are usually the stores that never tested with a screen reader.

What the screen reader hears

A button's accessible name comes from its text content first. A button that says Add to Cart has a name. A button that contains only an SVG icon has no text, so the name computation falls through to aria-label, then aria-labelledby, then the title attribute, and if none of those exist, the name is empty. The screen reader announces button, and the user has to guess.

The guessing is not harmless. A storefront has a dozen icon-only buttons: search, cart, menu, close, wishlist, filter, sort, account, and the quantity steppers. A keyboard user tabbing through hears button twelve times, and the only way to learn what each one does is to press it and see what happens. That is not navigation. It is a minefield.

The fix, and the naming rule

Add aria-label with the action, not the icon. The search button gets aria-label Search. The close button gets aria-label Close. The cart button gets aria-label Cart, with the item count if you have it, so the announcement is Cart, 3 items. The menu button gets aria-label Menu. One attribute per button, and the audit is done.

The naming rule is the part teams get wrong: name the action, not the picture. A magnifying glass icon named Magnifying glass tells a blind user nothing about what the button does. A button named Search tells them everything. The same rule applies to the hamburger menu, which is named Menu, and the X, which is named Close. If the label would confuse a sighted user reading it aloud, it is the wrong name.

Where teams still fail

The title attribute is the most common false fix. Teams add title Search to the button and move on, but the title is a last resort in the name computation and is inconsistently announced. Some screen readers announce it, some do not, and no user should depend on maybe. Use aria-label and keep the title as a tooltip if you like it.

The second failure is the SVG itself. An inline SVG with a title element inside it can leak a name into the computation, or a decorative SVG can be announced as an image with no alt text. Mark decorative SVGs aria-hidden true and focusable false, and put the name on the button, not inside the picture. The button is the control. The picture is decoration.

Frequently asked questions

What is an accessible name?

The name a screen reader announces for a control, computed from its text content, aria-label, aria-labelledby, or associated label element. A button with no text and no aria-label has no accessible name, and a screen reader announces it as just button, with no clue what it does.

Is a title attribute enough for an accessible name?

No. The title attribute is a last resort in the accessible name computation and is inconsistently announced across screen readers. Use aria-label for icon-only buttons, or visible text. The title can stay as a tooltip, but it is not the name.

Should the accessible name describe the icon or the action?

The action. A search button should be named Search, not Magnifying glass. A close button should be named Close, not X. The user needs to know what happens when they press it, not what the picture looks like.

Do icon-only buttons fail automated checkers?

Some do, some do not. Checkers that compute accessible names will flag a button with no name, but many will not. The reliable test is a screen reader: tab to the button and listen to what it announces. If it says only button, it fails.