How to fix: Links with no accessible name
Every link needs an accessible name, usually visible text, an aria-label, or a non-empty alt on an image inside it, so a screen reader can announce where the link goes instead of just saying "link."
What it is
An accessible name is the text a screen reader speaks when it reaches a link. WCAG Success Criterion 2.4.4 Link Purpose (In Context) requires that the purpose of each link be determinable, which starts with the link having any name at all. A link with no name is announced as a bare "link," giving the user nothing to act on.
The most common cause is the icon-only link: a social-media glyph, a hamburger menu, a magnifying-glass search, or a chevron whose entire content is an icon font, an SVG, or an <img> with an empty alt. Visually it reads as a button; programmatically it is empty. The same thing happens when a link wraps only an image whose alt is missing or blank.
You give the link a name in one of a few ways: put visible text inside it, add an aria-label describing the destination, reference visible text with aria-labelledby, add a title, or (if the link contains an image) give that image meaningful, non-empty alt text. Any one of these resolves the failure.
Who it affects & why it matters
Screen reader users are blocked outright: a list of links that all read "link, link, link" is impossible to navigate, and many users pull up an out-of-context links list to scan a page, where unnamed links are useless. Icon-only navigation, which looks clean to sighted users, is one of the most common ways this happens.
Voice-control users are also affected, because they activate links by speaking the link's name; if there is no name, there is nothing to say. And sighted keyboard users benefit when the name matches the visible purpose, keeping focus order understandable.
Links with no accessible name are a Level A failure under SC 2.4.4, and empty links and buttons are repeatedly listed among the top violation types that trigger ADA website lawsuits. Plaintiff firms scan for them because they are easy to find programmatically and easy to demonstrate.
The business impact is just as direct: an unnamed link is often the cart icon, the menu toggle, or the primary social or contact link, so the barrier sits on exactly the elements you most want users to reach. WCAG 2.1 Level AA is the standard courts apply, and naming your links is typically a one-attribute fix.
How to fix it
- Find links that contain no text, such as icon-only links built from an SVG, icon font, or image.
- If the link wraps an image, give that image descriptive, non-empty alt text that names the destination.
- If there is no image (an icon font or inline SVG), add an aria-label that describes where the link goes, for example aria-label="Search".
- Make sure the name describes the destination or action, not the icon shape ("View cart", not "shopping bag").
- Re-scan and confirm each link now reports an accessible name.
<a href="/search"><svg aria-hidden="true">...</svg></a>
<a href="https://twitter.com/accessknight">
<img src="/x-icon.svg" alt="">
</a><a href="/search" aria-label="Search"><svg aria-hidden="true">...</svg></a>
<a href="https://twitter.com/accessknight">
<img src="/x-icon.svg" alt="AccessKnight on X">
</a>How AccessKnight detects this
AccessKnight inspects every <a> element and flags it only when it has no accessible name from any source. Specifically, the link is reported when its trimmed text content is empty AND it has no aria-label, no aria-labelledby, no title attribute, and does not contain an image with a non-empty alt. Because all of those count as a name, an icon link that carries an aria-label, or an image link whose <img> has real alt text, passes. The classic failure it catches is the icon-only link whose only content is a decorative SVG or an image with alt="".