How to Fix Empty Links and Buttons

Your accessibility scan flagged links or buttons that have no accessible name. This means a screen reader user encounters a control announced as "link" or "button" with no indication of what it does or where it goes. It is one of the most common accessibility failures, and it affects every assistive technology user who navigates your site.

What the Scanner Found

The scan uses axe-core rules to detect interactive elements with missing or empty accessible names. Your report may include one or more of these violations:

• link-name — An anchor element (<a>) has no discernible text. The link has no text content, no aria-label, no aria-labelledby, and no image with alt text inside it.
• button-name — A <button> element has no discernible text. The button contains no text content, no aria-label, no aria-labelledby, and no image with alt text.
• empty-heading — A heading element (<h1> through <h6>) contains no text. This is often caused by a heading that wraps an anchor tag with no text content.

Which WCAG Criteria Apply

• 4.1.2 Name, Role, Value (Level A) — All user interface components must have a name that can be programmatically determined. A link or button without accessible text fails this criterion because assistive technology cannot convey the component's purpose.
• 2.4.4 Link Purpose (In Context) (Level A) — The purpose of each link can be determined from the link text alone, or from the link text together with its programmatically determined link context. A link with no text at all cannot meet this requirement.
• 1.1.1 Non-text Content (Level A) — When a link or button contains only an image (including SVG or icon fonts), that image must have a text alternative that describes the link's purpose or the button's action.

Why This Matters

Screen readers announce the control type with no context. When a screen reader encounters an empty link, the user hears "link" — nothing else. Some screen readers fall back to reading the URL, which produces something like "link, https://example.com/app/dashboard/settings/account/edit" — unusable noise. For buttons, they hear "button" with no action description.

Keyboard users who cannot see the screen depend on names. When navigating with the Tab key, screen reader users build a mental model of the page from the names announced for each focusable element. Empty names break that model and force the user to guess.

Voice control users cannot target the element. Users of Dragon NaturallySpeaking or Voice Control say "click" followed by the link or button name. An element with no name cannot be targeted by voice. The user must resort to grid overlays or numbered labels, which is slow and frustrating.

Fix: Link Containing Only an Image

When a link wraps an <img> element, the image's alt attribute becomes the link's accessible name. If the alt is missing or empty, the link has no name.

Before — image link with no alt:

<a href="/home">
  <img src="/logo.png">
</a>

After — alt text describes the link destination:

<a href="/home">
  <img src="/logo.png" alt="Home">
</a>

The alt text should describe the link's purpose, not the image itself. Use "Home" rather than "Company logo" because the purpose of the link is to navigate home.

Fix: Icon-Only Button

Buttons that contain only an icon — whether an icon font character, an SVG, or a background image — have no accessible name. Add aria-label to the button.

Before — icon button with no name:

<button class="icon-btn">
  <i class="fa fa-search"></i>
</button>

After — aria-label provides the name:

<button class="icon-btn" aria-label="Search">
  <i class="fa fa-search" aria-hidden="true"></i>
</button>

Note the addition of aria-hidden="true" on the icon element. This prevents screen readers from attempting to announce the icon font character (which may be read as a Unicode symbol).

Fix: Button With Only an SVG Icon

SVG icons inside buttons are common in modern interfaces. The SVG itself has no text content, so the button needs an explicit name.

Before — SVG button with no name:

<button>
  <svg viewBox="0 0 24 24">
    <path d="M3 18h18v-2H3v2zm0-5h18v-2H3v2zm0-7v2h18V6H3z"/>
  </svg>
</button>

After — aria-label on the button, aria-hidden on the SVG:

<button aria-label="Open menu">
  <svg viewBox="0 0 24 24" aria-hidden="true">
    <path d="M3 18h18v-2H3v2zm0-5h18v-2H3v2zm0-7v2h18V6H3z"/>
  </svg>
</button>

An alternative approach is to add a visually hidden text span inside the button instead of using aria-label:

<button>
  <svg viewBox="0 0 24 24" aria-hidden="true">
    <path d="M3 18h18v-2H3v2zm0-5h18v-2H3v2zm0-7v2h18V6H3z"/>
  </svg>
  <span class="sr-only">Open menu</span>
</button>

Fix: Completely Empty Link

Sometimes links are generated with no content at all — often from CMS templates, dynamic rendering bugs, or placeholder markup left over from development.

Before — empty anchor tag:

<a href="/dashboard"></a>

After — add visible text or visually hidden text:

<a href="/dashboard">Dashboard</a>

If the link is truly decorative or redundant (another visible link on the page goes to the same destination), the best fix is to remove it entirely. Empty links clutter the tab order and confuse assistive technology users.

Fix: Social Media Icon Links

Social media links in footers and headers almost always use icons without text. Each one needs an accessible name.

Before — icon-only social links:

<a href="https://twitter.com/example">
  <i class="fa fa-twitter"></i>
</a>
<a href="https://facebook.com/example">
  <i class="fa fa-facebook"></i>
</a>
<a href="https://linkedin.com/company/example">
  <i class="fa fa-linkedin"></i>
</a>

After — aria-label on each link:

<a href="https://twitter.com/example" aria-label="Twitter">
  <i class="fa fa-twitter" aria-hidden="true"></i>
</a>
<a href="https://facebook.com/example" aria-label="Facebook">
  <i class="fa fa-facebook" aria-hidden="true"></i>
</a>
<a href="https://linkedin.com/company/example" aria-label="LinkedIn">
  <i class="fa fa-linkedin" aria-hidden="true"></i>
</a>

Some implementations prefer to include "opens in new window" in the label when the links open externally, for example aria-label="Twitter (opens in new window)".

Fix: Hamburger Menu Button

The hamburger menu icon is universally recognized visually, but it has no inherent text. A screen reader user needs a name for the button.

Before — three-line icon with no text:

<button id="mobile-menu-toggle">
  <span class="bar"></span>
  <span class="bar"></span>
  <span class="bar"></span>
</button>

After — aria-label and expanded state:

<button id="mobile-menu-toggle" aria-label="Menu" aria-expanded="false">
  <span class="bar" aria-hidden="true"></span>
  <span class="bar" aria-hidden="true"></span>
  <span class="bar" aria-hidden="true"></span>
</button>

The aria-expanded attribute should be toggled between "false" and "true" by JavaScript when the menu opens and closes. This tells screen reader users whether the menu is currently visible.

Fix: Skip Navigation Link

Skip links help keyboard users bypass repeated navigation. They are often visually hidden but must still have text content.

Before — skip link with no text:

<a href="#main-content" class="skip-link"></a>

After — descriptive text added:

<a href="#main-content" class="skip-link">Skip to main content</a>

Skip links should become visible on focus so keyboard users can see them. A common CSS pattern:

.skip-link {
  position: absolute;
  left: -9999px;
  top: auto;
  width: 1px;
  height: 1px;
  overflow: hidden;
}

.skip-link:focus {
  position: fixed;
  top: 10px;
  left: 10px;
  width: auto;
  height: auto;
  padding: 8px 16px;
  background: #000;
  color: #fff;
  z-index: 10000;
  text-decoration: none;
}

Fix: Download Links With Only a File Icon

Download links frequently use a file-type icon with no text, leaving users unable to determine what they would be downloading.

Before — icon-only download link:

<a href="/files/report-2024.pdf">
  <img src="/icons/pdf-icon.png">
</a>

After — descriptive alt text on the image:

<a href="/files/report-2024.pdf">
  <img src="/icons/pdf-icon.png" alt="Download Annual Report 2024 (PDF)">
</a>

Include the file format and a description of the document in the text. This helps all users understand what they are about to download.

Fix: Link Wrapping Block Content

HTML5 allows anchor elements to wrap block-level content like headings, paragraphs, and images. When none of this inner content contributes accessible text, the link is announced without a name.

Before — link wrapping a div with only a background image:

<a href="/products/widget">
  <div class="card">
    <div class="card-image" style="background-image: url(/img/widget.jpg)"></div>
  </div>
</a>

After — add text content inside the link:

<a href="/products/widget">
  <div class="card">
    <div class="card-image" style="background-image: url(/img/widget.jpg)" role="img" aria-label="Widget product photo"></div>
    <h3>Widget</h3>
    <p>Our most popular product</p>
  </div>
</a>

When a link wraps content that already includes a heading or visible text, the link's accessible name is computed from all the text content inside it. Make sure at least some of that content is real text, not just images or decorative elements.

Visually Hidden Text Pattern

When you need to provide accessible text without changing the visual design, use a visually hidden class. This CSS hides text from sighted users while keeping it available to screen readers:

.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
  border: 0;
}

Use it inside any link or button that needs hidden text:

<a href="/cart">
  <svg aria-hidden="true">...</svg>
  <span class="sr-only">Shopping cart (3 items)</span>
</a>

Most CSS frameworks already include this class: .sr-only in Tailwind CSS and Bootstrap, .visually-hidden in Bootstrap 5, and .screen-reader-text in WordPress themes.

CMS-Specific Fixes

WordPress: Empty links often appear when a theme uses post thumbnails as links without alt text. Go to the Media Library, select the image, and fill in the Alt Text field. For icon menus, many themes provide a "Screen Reader Text" or "Accessibility Label" option in the menu item settings. If your theme does not, add a plugin like WP Accessibility which can add labels to icon-only navigation items.

Shopify: Social media icon links are generated by the theme. Edit your theme's sections/footer.liquid or equivalent and ensure each social link includes aria-label="{{ service_name }}". Most modern Shopify themes handle this, but older themes may not.

Squarespace: Icon-only buttons created through the block editor cannot have aria-label added directly. Use the Code Injection feature to add a script that sets aria-label attributes after page load, or restructure the block to include visible text.

Wix: Wix automatically generates accessible names for some built-in icon buttons. For custom icon buttons, use the "Tooltip & SEO" or "Accessibility" panel in the editor to set the label text.

Generic CMS tip: If your CMS generates empty links (often from widgets, modules, or page builder components that output placeholder markup), check whether the component has a setting for alt text, label text, or accessibility text. If not, the fix usually requires editing the component template or contacting the plugin developer.

Choosing Between aria-label and Visible Text

Both approaches create valid accessible names, but they have trade-offs:

• Visible text is the best option. It helps all users, not just screen reader users. It also ensures the accessible name matches what sighted users see, which is important for voice control users.
• Visually hidden text (.sr-only spans) is good when the visual design cannot change. It supports translation and can be picked up by automated testing tools.
• aria-label is the most compact approach for icon-only controls. Its main downside is that it is not automatically included in translation workflows — you must remember to translate it manually for each locale.
• aria-labelledby is useful when the label text already exists somewhere on the page. It references another element's id to avoid duplicating text.

Common Mistakes to Avoid

• Do not use title as the only accessible name. The title attribute creates a tooltip on hover but is not reliably announced by all screen readers and is completely inaccessible to touch screen users.
• Do not put the URL in the aria-label. Write a human-readable label. Use "Visit our Facebook page" instead of "https://facebook.com/example".
• Do not duplicate the role in the label. Screen readers already announce "link" or "button". Writing aria-label="Search button" results in "Search button, button" being announced. Use aria-label="Search" instead.
• Do not add aria-label to non-interactive elements. Adding aria-label to a <div> or <span> that is not interactive or does not have a landmark role has no effect in most screen readers.
• Do not confuse empty links with empty href. An <a href="">Click here</a> has text ("Click here") but an empty destination. That is a different problem. The issue discussed here is links that have a destination but no text.

Testing Your Fix

After applying fixes, verify them with these steps:

• Re-run the Passiro scan. The link-name and button-name violations should be resolved for the elements you fixed.
• Keyboard test: Press Tab through your page. Every link and button that receives focus should have a visible focus indicator and, if you are using a screen reader, should announce a meaningful name.
• Browser DevTools: Right-click the fixed element, select Inspect, then open the Accessibility panel. Check that the "Name" field shows your expected text. In Chrome, this is under the Accessibility tab in the Elements panel. In Firefox, it is under the Accessibility Inspector.
• Screen reader test: Use VoiceOver (macOS: Cmd+F5), NVDA (Windows, free), or JAWS (Windows). Navigate to the fixed link or button and confirm you hear a meaningful name followed by the element role.
• axe DevTools: Install the axe DevTools browser extension and run a page scan. Filter by "link-name" and "button-name" to confirm zero violations.

Empty links and buttons are one of the easiest accessibility issues to fix. Each fix is a single attribute or a few words of text — but for assistive technology users, it is the difference between a usable interface and an incomprehensible one.