Why is "click here" or "read more" bad for accessibility?

Screen reader users often pull up a list of all the links on a page and navigate by it, out of context. A list of ten links that all say "read more" or "click here" tells them nothing about where each one goes. WCAG Success Criterion 2.4.4 (Level A) asks that a link's purpose be clear from its text, or from its immediate context. Descriptive text like "Read the 2026 accessibility report" works in or out of context.

How do I fix an icon-only link, like a search or menu button?

Give it an accessible name without adding visible text. The simplest way is an aria-label on the link (for example aria-label="Search"), and mark the icon itself aria-hidden="true" so it is not announced twice. If the icon is an image, give the image meaningful alt text instead. Then test by listening to the link with a screen reader.

Does a link with no text fail WCAG?

Yes. A link with no accessible name fails Success Criterion 4.1.2 Name, Role, Value at Level A, the most basic conformance level. Ambiguous text like "click here" can also fail 2.4.4 Link Purpose at Level A. An automated scanner reliably catches links with no name at all; whether existing link text is meaningful enough is a judgment a person has to make.

Links Without Discernible Text: What It Means and How to Fix It

By Site Brace Research · Published June 15, 2026

"Links must have discernible text" means a link has no text that a screen reader can announce, so the user hears only "link" and has no idea where it goes. It is the second most common accessibility failure on the web, after low contrast - we found it on 70 of the 299 large US home pages we scanned, nearly a quarter of them. The usual causes are icon-only links, linked images with no alt text, and empty links. WCAG asks two things of a link at Level A: that it has an accessible name at all (Success Criterion 4.1.2), and that the name describes where it goes (Success Criterion 2.4.4). The first is easy to find and fix; an automated scan catches it directly.

A link is a promise: click this and go there. When the link has no readable name, the promise is blank. A sighted user might infer it from a magnifying-glass icon or the shape of a logo. A screen reader user, tabbing through a page or pulling up its list of links, just hears "link, link, link" with nothing to choose between. This page covers what counts as discernible text, who the gap shuts out, how common it is, and how to fix each version of it.

What "discernible text" means

A link's accessible name is the text a browser hands to assistive technology when it reaches the link. It can come from a few places:

the visible text between the <a> tags ("Pricing"),
an aria-label on the link, when there is no visible text (an icon button),
or the alt text of an image, when the image is the link.

WCAG covers this at two levels, both Level A, the most basic tier:

Requirement	What it asks	WCAG criterion
The link has a name	Every link has a non-empty accessible name	4.1.2 Name, Role, Value
The name is meaningful	The link's purpose is clear from its text, or its immediate context	2.4.4 Link Purpose (In Context)

The first is the one a machine can check, and the one this failure is named for: a link with no name at all. The second is the "click here" problem, which needs a person to judge.

Who this shuts out

Screen reader users, most directly. Many navigate by jumping link to link, or by pulling up a generated list of every link on the page. A link with no name is a dead end there, and a page full of "read more" is a guessing game.
Voice-control users, who operate the page by speaking a link's name ("click Pricing"). A link with no name cannot be spoken to.
Everyone, a little. Descriptive link text is just clearer. "Download the 2026 report (PDF)" beats "click here" for a sighted user skimming too.

How common is it?

It is the second most common failure in our data. In the State of Web Accessibility 2026 study we scanned 299 of the largest US home pages; 70 of them (23%) had at least one link with no discernible text. Only low contrast was more common.

It clustered hardest on nonprofit sites (20 of 43, 47%) and law firm sites (17 of 46, 37%), the same sites that lean on icon links for social media, search, and donate or contact actions, and on "read more" cards for articles and case studies. The pattern is almost always the same handful of culprits:

Icon-only links - a magnifying glass for search, a hamburger for the menu, social icons in the footer - marked up with no text and no label.
Linked logos and images with an empty or missing alt, so the link that wraps them has no name.
Empty links - an <a> with no href, or href="#", often left behind by a script-driven menu.
Vague text - "read more", "click here", "learn more" repeated down a page, which has a name but not a useful one.

How to fix it

Most of these are a one-line change. The steps:

Find the unnamed links. Run a scan or use axe DevTools to list every link with no discernible text.
Name icon-only links. Add an aria-label describing the destination, and hide the decorative icon from screen readers:

<!-- Before: a screen reader announces only "link" -->
<a href="/search"><svg>...</svg></a>

<!-- After: announced as "Search, link" -->
<a href="/search" aria-label="Search">
  <svg aria-hidden="true">...</svg>
</a>

Give linked images alt text. When the image is the link, its alt becomes the link's name - so a linked logo gets alt="Acme Bank home", not alt="".
Make visible text describe the destination. Swap vague text for the real target:

<!-- Before -->
<a href="/2026-report">Read more</a>

<!-- After -->
<a href="/2026-report">Read the 2026 accessibility report</a>

Fix empty links. A link to # that goes nowhere is a barrier. Give it a real destination, or use a <button> if it performs an action rather than navigating.
Listen to the link list. Turn on a screen reader, pull up the list of links, and confirm each one tells you where it goes on its own. Re-scan to confirm the failures are cleared.

Skip the "overlay" widgets that claim to relabel your links automatically. They guess, and they guess badly - the Federal Trade Commission fined the overlay vendor accessiBe one million dollars in 2025 over claims that its tool could make any site conform. A real link name is a few characters of HTML, written once. We cover why overlays fall short in detail.

What a scan can and cannot tell you

An automated scan is reliable on the first half of this: it finds every link with no accessible name, because that is a fact about the markup. It cannot judge the second half - whether the name you did write is meaningful. "Read more" has a name, so it passes the automated check, but it still fails 2.4.4 for a screen reader user reading it out of context. That part needs a person who pulls up the link list and asks: would this make sense on its own? We test the automated slice and say so, and the manual read is part of a full audit.

Common questions

What does "links must have discernible text" mean? A link has no text a screen reader can announce, so the user hears only "link". Usually an icon-only link, a linked image with no alt, or an empty link.

Why is "click here" bad? Screen reader users navigate by a list of links out of context; ten links that all say "click here" tell them nothing. Descriptive text works on its own.

How do I fix an icon link? Add an aria-label to the link and aria-hidden="true" to the icon, or give the inner image meaningful alt text.

Does it fail WCAG? A link with no name fails 4.1.2 (Level A). Vague text can fail 2.4.4 (Level A).

Check your own site

Run a free check on your home page and you will see every link with no discernible text, with the markup that needs fixing, in about a minute. For the whole site, see what a full audit covers, and how monitoring catches the unnamed links that slip back in whenever a new icon or card component ships. For the data behind this page, read the State of Web Accessibility 2026; the most common failure of all, low color contrast, is its companion piece.