You’ll run into this sooner or later in accessibility work: everything in a pull request looks fine. Layout sits correctly, icons load, hover states behave, keyboard focus moves. And then you turn on a screen reader, and it announces the same thing over and over:
“Button. Button. Button.”
That’s an empty button.
And yes—teams ship them all the time, even experienced ones.
They show up across small sites, large platforms, custom apps, and CMS-driven systems. Large-scale audits have found them on a significant share of homepages year after year, which tells you this isn’t a “carelessness” problem. Things look correct visually, so nobody questions whether the button actually exposes a name.
Once you see how often that gap slips through, it becomes easier to break the issue apart—what an empty button is at the markup level, why teams run into them so frequently, how screen readers respond to them, and the patterns and fixes that prevent them from resurfacing in future work.
What Empty Buttons Are and Why They Matter
An empty button is a control that does not expose an accessible name. It might not be “empty” visually—the UI may show an icon, a custom SVG, or a shape styled entirely through CSS. It might animate and look fully functional. None of that changes the fact that assistive technology can’t understand what the control does. Visually complete or not, a button without a name is effectively invisible to anyone relying on that information.
Common UI Patterns That Produce Empty Buttons
You’ll see empty buttons come from a handful of predictable patterns:
- Icon-only controls such as search, hamburger menus, close icons, and carousel arrows
- Buttons that use CSS background images or pseudo-elements for their visible “content.”
- SVGs inside a button without a usable label or internal text
- Buttons where text was added through CSS instead of being in the DOM
- Submit or action inputs that never received a
value
These patterns all have the same underlying problem: nothing meaningful ends up in the accessibility tree. Even experienced teams get caught by this because none of these cases look broken during normal UI review. The button appears complete, so the missing name goes unnoticed.
Buttons vs Links: Preventing Naming Failures
A fair number of empty buttons start long before anyone looks at labels—they come from using the wrong element altogether. A control can look like a button in the UI, but under the hood, it’s a styled link coming from a CMS. Or a real <button> gets wired up to handle navigation because it was the fastest way to hook into a script. Both choices create avoidable problems.
The semantic rule is not complicated, and it holds up across every framework and CMS:
- Links move the user to a new location.
- Buttons trigger something in the current view.
Assistive technology depends on that distinction. Screen readers keep separate lists for links and buttons. Keyboard users expect different activation behavior. When the markup doesn’t match the intent, the control becomes unpredictable—especially for anyone not relying on visuals to figure out what’s going on.
If you’re working in a design system or component library, this is where discipline pays off. Define two primitives that share the same visual design but render the correct element under the hood:
- A real
<button>component for actions - A
LinkButton(or equivalent) that renders an anchor for navigation
You keep visual consistency, but the markup stays honest. That reduces confusion for assistive tech and cuts down on empty-button issues that come from mismatched roles or controls that never get a proper name.
How Screen Readers Handle Empty Buttons
A screen reader can only announce what a button does if it has a real, programmatic name. When that name is missing, the control becomes indistinguishable from every other unlabeled button in the interface. At that point, the user isn’t navigating—they’re guessing.
Screen readers follow a strict naming order. They don’t pull from styling, layout, or anything “visual.” They rely on one of these sources, in this order:
- Visible text inside the <button> element
aria-labelaria-labelledby- Alt text on images inside the button
- The value on an
<input type="submit">
Anything outside this list won’t create a name.
That includes:
- CSS
content - Pseudo-elements
- Background images
- Any text that isn’t actually in the DOM
If the label isn’t provided through one of the recognized naming mechanisms, assistive technology has nothing to announce. A lot of empty-button issues come from assuming CSS or decorative SVGs can stand in for meaningful text—they can’t.
When you need to confirm what a screen reader will announce, check the source the same way the browser does. In Chrome or Edge DevTools, open the Accessibility panel and look at Computed Name. If that field is empty, the button has no name for any user relying on a screen reader.
How to Find Empty Buttons Before Release
Catching empty buttons early is far easier than chasing them after a release. A reliable workflow keeps these issues visible long before they reach production, and it doesn’t require heavy tooling—just consistent layers of checks.
Automated Checks for Empty Buttons
Start with automated scans. They’re fast, predictable, and empty buttons show up as clear failures in most tools. They’re straightforward to fix and worth addressing immediately, rather than letting them roll into regressions.
Page-Level Spot Checks in Key UI Areas
After automation, move through the areas where empty buttons tend to cluster:
- Header controls such as search, menu, account, and cart
- Modal and drawer close buttons
- Carousel next/previous controls
- Cookie banners with accept or dismiss icons
In the DOM, look for button elements with no text, empty aria-label values, and input buttons missing a value.
Keyboard and Assistive Technology Checks
Keyboard testing surfaces empty buttons quickly. If focus lands on a control and gives you no indication of its purpose, that’s a naming failure. A short screen reader pass will confirm whether the accessible name is missing.
CMS and Plugin Sources of Empty Buttons
Many empty buttons come from CMS templates and plugins where the markup isn’t easily changed. When you run into one, narrow it down to one of three paths:
- Is there a setting that adds or overrides the label?
- Can the template be patched safely?
- Does the component need to be replaced altogether?
This keeps the work focused on concrete fixes instead of guessing where the problem originated.
Fixing Empty Buttons With Accessible Labels
Most empty buttons come from repeatable markup patterns, so the fixes follow equally repeatable shapes.
Adding Visible Text to Name Buttons
<button type="button">Subscribe</button>Providing Labels for Icon-Only Buttons
<button type="button" aria-label="Close dialog">
<svg aria-hidden="true" focusable="false"></svg>
</button>Using Screen-Reader-Only Text for Labels
<button type="button">
<svg aria-hidden="true" focusable="false"></svg>
<span class="sr-only">Search</span>
</button>Fixing Input Buttons Missing Values
<input type="submit" value="Submit" />Using Alt Text Correctly on Image Buttons
<button type="submit">
<img src="email.svg" alt="Subscribe to newsletter">
</button>All of these preserve a stable, accessible name, so the control keeps working even if styles or icons change later.
WCAG Requirements Related to Empty Buttons
When a button has no accessible name, it violates several parts of the Web Content Accessibility Guidelines (WCAG). These requirements ensure that every interactive control can be understood and operated by people using assistive technology. Empty buttons fall short because they provide no text, label, or programmatic name for a screen reader to announce.
Empty buttons map to several WCAG criteria, most commonly:
Tools may categorize them differently, but they’re all pointing at the same failure: the control doesn’t expose a usable name.
How to Prevent Empty Buttons Long-Term
Long-term prevention comes from a few small guardrails.
Setting Standards for Icon and Action Buttons
If your team builds icon-button components, require a label prop. That forces naming decisions into the place where they’re easiest to enforce.
Adding Tests to Catch Unnamed Buttons Early
Add tests that check for unnamed buttons in rendered output. Even a small number of targeted cases can stop regressions before they appear in the UI.
Reviewing CMS Output for Labeling Support
When reviewing new plugins or themes, inspect their output. If controls can’t be labeled cleanly, decide early whether they should be configured, patched, or replaced.
Building Better Accessible Buttons
Empty buttons are simple to overlook but deeply disruptive for users who rely on assistive technology. When a button can’t introduce itself, the interface stops feeling usable and starts feeling unpredictable.
From a development standpoint, addressing this isn’t complicated—it just requires intention. Choose the correct semantic element. Provide a name that lives in the DOM. Confirm the accessible name using your tools. And treat CMS and design system choices as part of your front-end architecture, not an afterthought.
If your team wants support refining button patterns, improving audits, or building accessibility practices that scale, 216digital can help. To map WCAG 2.1 requirements into your actual development workflow, schedule an ADA Strategy Briefing and get guidance tailored to your stack and long-term accessibility plans.