Link text that makes sense: fixing 'click here', 'read more' and empty links
Short answer: Every link should make sense on its own or with its surrounding sentence. Replace 'click here' and repeated 'Read more' links with descriptive text, give icon links an accessible name, and warn people when a link opens a new window.
Links are the main way people move around a website. When the words inside a link say nothing about where it goes, people who rely on assistive technology lose a shortcut that sighted visitors take for granted.
This guide covers the common ways links fail, how to fix them, and how to make the fixes once in your theme instead of page by page. It is general information, not legal advice. For legal questions, talk to an attorney.
What WCAG 2.4.4 actually requires
WCAG 2.4.4 Link Purpose (In Context) is a Level A success criterion in WCAG 2.1. It says the purpose of each link should be clear from the link text alone, or from the link text together with its programmatically determined link context.
"Programmatically determined link context" is a defined term in WCAG. In practice it means the sentence, paragraph, list item, table cell or heading the link sits in, or its table header cells. Assistive technology can read that context, so a link that depends on it can still pass.
Two points often get misread:
- The criterion allows context, but it does not allow ambiguity. If the same words lead to different places and nothing around them tells the user apart, the link fails.
- There is a stricter, separate criterion at Level AAA (2.4.9, Link Purpose (Link Only)) that requires link text alone to make sense. Your target is probably Level AA, so 2.4.4 is the one that applies, but writing link text that stands alone is still the safest habit.
You can read the official wording in Understanding Success Criterion 2.4.4 on w3.org.
Why screen reader users read a list of links
Screen readers such as NVDA, JAWS and VoiceOver can pull up a list of every link on a page, often sorted alphabetically or in page order. Many users scan that list the way sighted visitors scan a page, to find what they need quickly.
In that list, the surrounding sentence is gone. Only the link text remains. A page with twelve links that all say "Read more" turns into twelve identical entries with no way to tell them apart.
Users also tab from link to link, hearing only the link text each time. The same problem applies.
You can hear this yourself. The screen reader testing basics guide walks through VoiceOver and NVDA, and the 5-minute keyboard test is a quick way to tab through a page and notice which links are unclear.
The common failures
"Click here" and "learn more"
Before
<p>Our returns policy is available <a href="/returns">here</a>.</p>
<p><a href="/sizing">Click here</a> for the sizing chart.</p>"Here" says nothing in a links list. It also describes the mouse action rather than the destination, which does not fit touch screens or keyboards.
After
<p>Read our <a href="/returns">returns policy</a>.</p>
<p>See the <a href="/sizing">sizing chart</a>.</p>The fix is almost always a rewrite so the destination is the link text. Avoid wrapping a whole sentence in a link, since long link text is tedious to hear repeatedly.
Repeated "Read more" and "Shop now"
Product grids and blog lists often repeat the same label on every card.
Before
<article class="card">
<h3>Trail Running Jacket</h3>
<p>Lightweight and water resistant.</p>
<a href="/products/trail-jacket">Shop now</a>
</article>
<article class="card">
<h3>Insulated Vest</h3>
<p>Warm without the bulk.</p>
<a href="/products/insulated-vest">Shop now</a>
</article>Each link goes to a different place, yet the text is identical. In context, the heading above each link does help, but only if the markup makes that relationship determinable by software. Separate, unconnected elements often do not.
You have three reliable options.
Option 1: put the name in the link text (best when the design allows).
<a href="/products/trail-jacket">Shop the Trail Running Jacket</a>Option 2: keep the visual label, add visually hidden text.
<a href="/products/trail-jacket">
Shop now<span class="visually-hidden"> – Trail Running Jacket</span>
</a>.visually-hidden {
position: absolute;
width: 1px;
height: 1px;
margin: -1px;
padding: 0;
overflow: hidden;
clip: rect(0, 0, 0, 0);
white-space: nowrap;
border: 0;
}Option 3: use aria-labelledby to combine the link's own text with the product heading.
<h3 id="p1-title">Trail Running Jacket</h3>
<a href="/products/trail-jacket" id="p1-link" aria-labelledby="p1-link p1-title">Shop now</a>Whichever you choose, keep the visible words at the start of the accessible name. Voice-control users say what they see on screen, such as "click Shop now", and that only works if the accessible name contains the visible text. This is the idea behind WCAG 2.5.3 Label in Name.
Make the whole card one link
Another common pattern is a card with an image link, a title link and a "Read more" link, all pointing to the same page. A screen reader user hears three links to one destination.
A cleaner approach is a single link on the heading, extended to cover the card with CSS.
<article class="card">
<img src="jacket.jpg" alt="">
<h3><a href="/products/trail-jacket">Trail Running Jacket</a></h3>
<p>Lightweight and water resistant.</p>
</article>.card { position: relative; }
.card h3 a::after {
content: "";
position: absolute;
inset: 0;
}The image gets empty alt text because the adjacent link already names the product. See how to write alt text for product images for when that is and is not appropriate.
Empty links
An empty link has no text at all, so a screen reader may announce only "link" or read out the raw URL. This usually happens with icon links and image links.
Before
<a href="https://facebook.com/examplestore"><i class="icon-facebook"></i></a>
<a href="/cart"><img src="cart.svg"></a>After
<a href="https://facebook.com/examplestore" aria-label="Example Store on Facebook">
<i class="icon-facebook" aria-hidden="true"></i>
</a>
<a href="/cart"><img src="cart.svg" alt="Cart"></a>For an image inside a link, the image's alt text becomes the link's name, so it should describe the destination or action, not the picture. For icon fonts and inline SVG, hide the icon from assistive technology and put the name on the link. Related fixes for buttons are in icon buttons without labels, and the underlying rules are WCAG 4.1.2 Name, Role, Value and WCAG 1.1.1 Non-text Content.
Empty links are easy for automated tools to detect, which is one reason they show up often in scan reports.
Links that open a new window
Opening a new tab without warning can disorient users, particularly when the browser's back button no longer works as expected. WCAG 2.4.4 does not strictly ban target="_blank", but it is good practice to say so in the link.
<a href="https://www.ada.gov" target="_blank" rel="noopener">
ADA.gov (opens in a new tab)
</a>If the design cannot show the extra words, use visually hidden text. Only open new windows when there is a good reason, such as keeping a user's half-completed checkout intact.
Same text, different destinations
Two links labeled "Contact" that go to different pages, or a "Download" link next to each of five PDFs, confuse the links list too. Add the document name and, where helpful, the format and size, for example "Download the 2026 catalog (PDF)". The accessible PDF documents guide covers the file itself.
Quick reference
| Problem | Typical cause | Fix |
|---|---|---|
| "Click here" | Copywriting habit | Rewrite so the destination is the link text |
| Repeated "Read more" | Card template | Name in link text, hidden text, or aria-labelledby |
| Three links per card | Image + title + button | One link on the heading, stretched with CSS |
| Empty icon link | Icon font or SVG with no text | aria-label or hidden text; hide the icon |
| Image link, no alt | Missing alt attribute | Alt text describing the destination |
| Unannounced new tab | target="_blank" | Add "(opens in a new tab)" |
Fixing it once, at theme level
Rewriting every page is slow. Most vague links come from a few templates.
- Find the templates. Product grid card, blog index card, "featured" blocks, footer, and social icon rows account for most of the problem.
- Pass the title into the link. In a theme template, the product or post title is already available. For example, in a WordPress loop you can use
the_title()inside visually hidden text or anaria-label. In Shopify Liquid,{{ product.title | escape }}does the same job. Change the template once and every card updates. - Prefer fewer links per card. Collapsing three links into one makes the page quicker to navigate for everyone using a keyboard.
- Check page builders and plugins. Some "Read more" labels are generated by plugins. Look for a setting that adds the post title, or override the output.
- Re-test after theme updates. Updates can overwrite template edits. Use a child theme or keep your changes documented. See the WordPress accessibility guide for what to check.
Be cautious with overlay widgets that promise to repair link text automatically. They do not replace correcting the underlying markup, as explained in Do accessibility overlay widgets prevent ADA lawsuits?.
How to check your work
- Use your screen reader's links list and read it top to bottom. Every entry should make sense without the page around it.
- Tab through the page and listen to each link as focus lands on it.
- Run an automated scan to catch empty links and missing alt text, then review vague wording by hand, because tools cannot judge whether "Learn more" is meaningful in context.
- Record what you fixed and when. A dated record helps if you later need to show what you did; see why a dated accessibility audit record matters.
Link text is one item on the WCAG 2.1 AA checklist. If you want a baseline across your whole site, you can run a free scan to see which links are empty or repeated before you start editing.
Frequently asked questions
Is "Read more" ever acceptable under WCAG 2.4.4?
It can pass if the link context makes the purpose clear, for example when the link sits in a paragraph or under a heading that software can associate with it. It fails when many identical links appear with nothing programmatic to tell them apart. Adding the title through visible or hidden text is safer and easier to verify.
Do I have to remove target="_blank"?
No. WCAG 2.4.4 does not prohibit opening links in a new window. It is still good practice to tell users that a link opens in a new tab, and to use new windows sparingly.
How do I fix an icon-only link?
Give the link an accessible name that describes where it goes, such as "Example Store on Instagram". Use aria-label, visually hidden text, or alt text on an image inside the link, and hide decorative icon fonts or SVGs from assistive technology. Then test with a screen reader to confirm the name is announced.
Will fixing link text prevent an ADA lawsuit?
No single fix can promise that, and nothing here is legal advice. Link purpose is one of many criteria often cited in accessibility complaints, so fixing it reduces known problems. If you have received a demand letter or complaint, speak with an attorney; our guide on what to do after a demand letter covers practical first steps.
Can I fix this without a developer?
Often yes, for body copy and simple pages. Rewriting "click here" links in your editor needs no code. Product grids, blog cards and icon links usually live in theme templates, so you may need a developer or a theme setting. If you are choosing someone, what to ask when hiring an accessibility developer can help.
Related
- WCAG 2.4.4 Link Purpose (In Context)
- Icon Buttons Without Labels: Fixing Cart, Search and Menu Icons
- Screen Reader Testing for Business Owners: VoiceOver and NVDA Basics
- WordPress Accessibility: Themes, Plugins and What to Check
Proof of Access provides technical accessibility assessments. We are not a law firm and nothing on this page is legal advice. If you have received a demand letter or a lawsuit, talk to an attorney.