Same Link Text Should Go to the Same Place: How to Fix It

This check flags pages where two or more links share the exact same visible text but point at different URLs — three "Read more" links going to three different articles, four "Download" links hitting four different files. For a sighted user scanning in context it is fine. For a screen-reader user pulling up a list of every link on the page, it is a wall of identical labels leading who-knows-where.

Why identical link text is a real problem

Screen-reader users navigate by links. They press a key, get a flat list — "Read more, Read more, Read more, Learn more, Learn more" — stripped of the surrounding paragraph that gave each one meaning. If those labels resolve to different destinations, the user has no way to tell them apart without opening each one. That is WCAG 2.4.4 (Link Purpose in Context) and 2.4.9 territory, and it is a genuinely miserable experience.

The inverse is fine and even encouraged: the same text pointing to the same URL is not a violation — it is consistency. The failure is specifically same text, different target.

Real failing example

<article>
  <h3>Q3 Revenue Report</h3>
  <a href="/reports/q3-revenue.pdf">Download</a>
</article>

<article>
  <h3>Q3 Headcount Report</h3>
  <a href="/reports/q3-headcount.pdf">Download</a>
</article>

<article>
  <h3>Q3 Marketing Report</h3>
  <a href="/reports/q3-marketing.pdf">Download</a>
</article>

Three links, one label: "Download." In the links list they are indistinguishable. The user hears "Download, Download, Download" and has no clue which is revenue and which is headcount.

The fix

<!-- Option A: make the visible text distinct -->
<a href="/reports/q3-revenue.pdf">Download Q3 revenue report (PDF)</a>
<a href="/reports/q3-headcount.pdf">Download Q3 headcount report (PDF)</a>

<!-- Option B: keep short visible text, add an accessible-name override -->
<a href="/reports/q3-revenue.pdf" aria-label="Download Q3 revenue report">Download</a>
<a href="/reports/q3-headcount.pdf" aria-label="Download Q3 headcount report">Download</a>

Option A is the honest fix — the label everyone sees is unique. Option B keeps a tidy visual "Download" button while giving the screen reader the full story via aria-label. Both pass. Do not pad with title; it is unreliable as an accessible name.

Distinguishing the patterns

How to detect it

1. axe DevTools. The identical-links-same-purpose rule surfaces links that share text but differ in destination.
2. Lighthouse. The Accessibility category flags link-name and ambiguous-link issues with selectors.
3. Screen-reader links list. In NVDA press Insert+F7, or in VoiceOver open the rotor (VO+U) and choose Links. Scan for repeated labels going to different places.
4. Console diff. Collect [...document.links].map(a => [a.textContent.trim(), a.href]), group by text, and flag any group with more than one distinct href.

How to fix it

1. Pull the list of duplicate-text links and their targets.
2. For each cluster, confirm the destinations really differ (same-text/same-URL is fine).
3. Rewrite the visible text so each link states its own destination — append the item name, file type, or context.
4. Where design demands a short button, keep the visible text and add a distinct aria-label.
5. Kill generic "click here" / "read more" / "here" labels while you are in there; they are weak for users and crawlers alike.
6. Re-run the links-list check to confirm every label is now self-explanatory.

Frequently asked questions

Is "Contact us" in both my header and footer a violation?

No. Same text pointing to the same URL is consistency, not ambiguity. The rule only cares about identical text leading to different destinations.

Can I fix it with aria-label and leave the visible "Read more"?

Yes. aria-label overrides the accessible name, so a screen reader hears "Read more about the Q3 revenue report" while sighted users see the compact "Read more." Just make sure the label starts with or contains the visible text so speech-input users can still say the on-screen word.

How is this different from empty or icon-only links?

That is a separate failure — a link with no accessible name at all. Same-place links have a name; it is just not unique. For the no-name case see Links Must Have Discernible Text.

Does this hurt SEO?

Descriptive anchor text helps both users and crawlers understand where a link goes, so fixing it is a modest win for internal linking clarity. The deeper mechanics are in Internal Linking: The Complete Guide, and the broader overlap is in Accessibility and SEO.

What priority should I give this?

It is flagged low priority because it rarely blocks a task outright — users can still activate the links, they just work harder to choose. Fix it after the hard blockers like unreachable frames or unnamed controls, but do not skip it; it compounds on link-heavy templates like blog indexes and resource lists.