Unlabeled Links
An unlabeled link is a link with no text that assistive technology can read, most often an icon-only link whose only content is an SVG. You fix it by giving the link an accessible name, either an aria-label on the anchor itself or visually hidden text inside it.
What we measured
100% of the sites we measured failed the axe-core Link Labels rule. Not most of them. All 191, with zero passes.
Source: State of Small Business Websites 2026, n=191.
Sample framing: Purposive North American B2B prospect list skewing construction, trades and SMB services. 292 domains were scanned; mobile Lighthouse was valid on 193, and the Link Labels column resolved for 191. It represents the businesses small agencies actually pitch, not a random sample of the web.
How to re-derive it: check_link_labels column, 191 fail rows and 0 pass rows. Replicable from the published dataset.
Why it matters
- A screen reader announces an unlabeled link as "link" and nothing else. Someone navigating by links hears a list of identical, meaningless entries.
- Keyboard users who tab through your footer get no indication of where any of those social icons go.
- It is one of the most common findings in accessibility litigation against small businesses, because it ships inside ready-made themes and nobody looks at it.
- Crawlers reading your markup get the same nothing a screen reader gets. An icon-only link passes no anchor text to anything.
The failure
<a
href="https://www.linkedin.com/company/axion-deep-digital"
target="_blank"
rel="noopener noreferrer"
className="p-2 rounded-lg hover:bg-white/[0.06]"
>
<svg className="w-4 h-4" fill="currentColor" viewBox="0 0 24 24">
<path d="M20.45 20.45h-3.56v-5.57c0..." />
</svg>
</a>This is our own footer social link with one attribute removed. The anchor's only child is an SVG, so its accessible name computes to empty. A screen reader announces it as "link."
The fix
<a
href="https://www.linkedin.com/company/axion-deep-digital"
target="_blank"
rel="noopener noreferrer"
aria-label="LinkedIn"
className="p-2 rounded-lg hover:bg-white/[0.06]"
>
<svg
className="w-4 h-4"
fill="currentColor"
viewBox="0 0 24 24"
aria-hidden="true"
focusable="false"
>
<path d="M20.45 20.45h-3.56v-5.57c0..." />
</svg>
</a>The aria-label supplies the accessible name and is what our site ships today. The aria-hidden and focusable attributes on the SVG are the belt-and-braces addition: the label already wins, but hiding the decorative graphic stops any chance of it contributing a stray name.
Verify the fix
Changing the code is not the same as fixing the problem. Confirm it.
- Run axe DevTools or Lighthouse on the page and confirm the "Links do not have a discernible name" violation count is zero. The rule id is link-name.
- Tab to the link and listen with a screen reader, or read the accessibility tree in Chrome DevTools. The computed name must be the label you set, not "link."
- Re-run the page through DeepAudit and confirm the Link Labels check passes. A finding is a lead to investigate, so do not take the first report as proof either way. Confirm it on the rendered page.
- Check the rendered output, not the source. Templates and build steps change what is published.
Exceptions and misconceptions
A title attribute is not a fix
title produces a tooltip on hover and is inconsistently exposed to assistive technology. It does not reliably supply an accessible name, and it is invisible to keyboard and touch users. Use aria-label or visually hidden text.
If the link already has visible text, do not add a label
An aria-label overrides the visible text for screen reader users, which creates a mismatch between what people see and what they hear. Only label links that have no readable text.
Visually hidden text is the more robust option
aria-label is not translated by some machine translation tools and is ignored by a few older assistive technologies. A visually hidden span inside the anchor is real text, so it translates and always computes. Either passes the check; the span is safer.
"Click here" and "Read more" are a different problem
Those links have an accessible name, so they pass link-name. They fail a separate usability standard, because the name is not descriptive out of context. Do not conflate the two findings.
Watch it
Primary sources
- WCAG 2.2, Success Criterion 2.4.4 Link Purpose (In Context)
- WCAG 2.2, Success Criterion 4.1.2 Name, Role, Value
- Deque axe-core rule: link-name
- MDN: aria-label
The measurement above comes from our study, State of Small Business Websites 2026.
Related lessons
Check your own site for this
DeepAudit AI renders your page in a real browser and reports the affected code, so you can see exactly where each finding came from. Free, no signup.
Run a free auditLast reviewed 2026-09-16. Checks covered: Link Labels, Empty Links, Icon-Only Links.