A Button Without a Name Is Just a Mystery You’re Expected to Click

During a recent audit, we encountered icon-only buttons on a site: a magnifying glass for search, an “X” to close a dialog. Standard stuff. Visually, their purpose feels obvious. Most sighted users wouldn’t think twice.

But when we navigated to these controls with a screen reader, all we got was:

“Button.”

No name. No description. No indication of what the button does. The screen reader knew it was a button. It had no idea what kind.

For a sighted user, an unlabeled icon button is a minor annoyance at worst. For a screen reader user, it’s a guessing game. Do I click this and hope it searches? Do I click this and hope it closes the dialog instead of deleting something? There’s no way to know without trying.

WCAG 4.1.2: Name, Role, Value. Severity: High.

Why Icons Don’t Speak for Themselves

There’s a common assumption in design that certain icons are universally understood. A magnifying glass means search. An “X” means close. A hamburger icon means menu. And visually, that’s mostly true for sighted users who’ve spent years building those associations.

Assistive technology doesn’t work that way. A screen reader doesn’t look at an SVG and interpret its shape. It reads the accessibility tree, which is the programmatic representation of the page. If a button has no accessible name in that tree, the screen reader has nothing to announce beyond the element’s role.

This is the same Name, Role, Value principle from earlier in this series (Post 3). The role is partially there (“button”). The name is missing. Without a name, the control has no meaning.

Where This Gets Especially Problematic

Icon buttons tend to control important actions. Search, close, navigation, settings, account menus, shopping carts. These aren’t decorative elements. They’re primary interaction points.

Consider a close button inside a modal dialog. If it has no accessible name, a screen reader user who’s been properly focused into the modal (see Post 5 in this series) still can’t identify how to exit it. They’re trapped in a dialog with no labeled way out.

Or consider a search icon button. Without a name, a screen reader user navigating the header hears “button” and has to decide whether to activate an unknown control. On a healthcare or financial services site, that kind of ambiguity undermines trust.

The Fix

This is one of the fastest fixes in accessibility. Add an aria-label to the button and mark the icon as decorative:

<button aria-label="Search">  <svg aria-hidden="true">...</svg></button>

<button aria-label="Close dialog">  <svg aria-hidden="true">...</svg></button>

The aria-hidden=”true” on the SVG is important. It tells the screen reader to ignore the icon itself and rely on the button’s accessible name instead. Without it, some screen readers might try to announce the SVG content, which usually produces gibberish or nothing useful.If you prefer not to use aria-label, visually hidden text inside the button works too:

<button>  <span class="visually-hidden">Close dialog</span>  <svg aria-hidden="true">...</svg></button>

A few things to avoid: don’t rely on the title attribute as the primary accessible name, since screen reader support for title is inconsistent. Don’t assume that a tooltip appearing on hover solves the problem, because tooltips are a visual-only feature. And don’t leave the SVG exposed without aria-hidden, since it can interfere with name computation.