Accessible Button Names: Stop Shipping Mystery Controls

A button with no name is not a button users can trust

Sighted visitors can often guess what an icon button does. A magnifying glass probably opens search. A cart icon probably opens the cart. A hamburger icon probably opens a menu.

Assistive technology cannot rely on visual guessing. It needs a programmatic name. Without that name, the control may be announced as only "button" or "link". The visitor hears that something is interactive but not what it does.

That is why empty button findings show up so often in accessibility reports. The control exists. It may even work perfectly with a mouse. But the name is missing from the accessibility tree.

The fix is usually small. The impact is large because unnamed controls often sit in important places: headers, search bars, menus, account areas, carts, forms, sliders, and social links.

What an accessible name means

An accessible name is the text assistive technology uses to identify a control.

For a normal text button, the visible text is usually enough. A button that says "Get report" has a name. A link that says "Pricing" has a name.

Problems start when the visible content is not meaningful text. Icon-only buttons, SVG-only controls, image buttons, empty links, and repeated "Learn more" links often need extra care.

The name should answer the user's immediate question: what will happen if I activate this?

"Search" is better than "magnifying glass". "Open navigation menu" is better than "menu icon". "Remove item from cart" is better than "trash". "Read ADA audit cost guide" is better than another generic "Read more".

Icon buttons need labels

If a button contains only an icon, give the button a label.

Common patterns include `aria-label` on the button, visually hidden text inside the button, or an associated visible label. The best choice depends on the component, but the outcome is the same: the button has a clear name.

Do not put the label only on the SVG if the button itself remains unnamed. Do not assume the file name, title attribute, placeholder, or CSS class will become a reliable name. Test the rendered result.

Also make sure decorative icons stay decorative. If a text button says "Download report" and also includes a download icon, the icon does not need its own announcement. Marking it decorative avoids noise.

Repeated links need context

Button-name issues are not limited to icons.

Blog indexes, service grids, and product cards often repeat links like "Read more", "Learn more", or "View details". A sighted user sees the card around the link. A screen reader user navigating by links may hear the same phrase repeated ten times with no context.

There are two common repairs.

One is to make the visible link text specific: "Read the ADA audit cost guide". The other is to include visually hidden context, so the visible text stays short while the accessible name becomes specific.

Be careful not to overdo it. The goal is clarity, not a sentence stuffed with keywords.

Bad labels can be as confusing as missing labels

An accessible name should match the action.

If a button visually says "Start free scan" but the accessible name says "submit", the mismatch can confuse users and automated checks. If a close button has `aria-label="X"`, it technically has a name, but not a useful one. If every carousel dot says "button", "button", "button", the user still has to guess.

Good labels are specific and stable.

• "Open main menu"
• "Close signup dialog"
• "Submit scan request"
• "Go to next testimonial"
• "Remove ADA audit report from cart"

Each name tells the visitor what the control does.

Fix the source component

Unnamed controls repeat because components repeat.

If every product card has the same vague link, fix the card component. If every icon button in the design system lacks a label prop, update the component API so a label is required. If the mobile menu button is unnamed on every page, fix the header once.

This is why a good accessibility report should identify patterns, not just pages. A list of fifty unnamed buttons may really mean three components need repair.

Ask the developer to find the source template, component, or widget. Then retest across the pages where that component appears.

The practical test

You do not need a full screen reader setup to catch many naming problems.

Browser developer tools can inspect the accessibility tree. Automated scanners can flag empty buttons and links. Keyboard testing can reveal controls that receive focus but do not explain themselves. Screen reader testing gives the clearest user-level confirmation.

Start with these questions:

• Does every icon-only control have a specific name?
• Does every repeated link identify the thing it opens?
• Does the accessible name match the visible text or action?
• Are decorative icons hidden from assistive technology?
• Are labels set on the interactive element, not only on a child icon?

If the answer is no, the repair is usually direct.

Small names, real consequences

Accessible names are not decorative metadata. They are how many users understand the interface.

When names are missing, people cannot confidently search, open menus, submit forms, or complete purchases. When names are clear, the same interface becomes easier to navigate without changing its visual design.

That is the kind of accessibility work small teams can actually ship: find repeated mystery controls, name them honestly, and retest the path where users need to act.