Accessibility Wiki

Links with the same name should go to the same place

Rule identical-links-same-purpose · Links & buttons · impact minor · Static + live

↩ Back to the rules index · WCAG cross-reference

Why it matters

When links in the same context share an accessible name but point to different URLs, a screen-reader user choosing from the links list can’t tell them apart. Same-name links that are each disambiguated by their own programmatic context (their list item, table cell, or paragraph) conform to 2.4.4. URL differences that don’t change the destination — spelling variants of the same path, fragments, and common tracking params (utm_*, gclid, fbclid, mc_cid/mc_eid, ref) — are ignored when comparing.

How to fix

Differentiate the names (e.g. "Read more about pricing" vs "Read more about security"), or point them at the same place.

Example

✕ Fails
<a href="/a">Read more</a><a href="/b">Read more</a>
✓ Passes
<a href="/a">Read more about pricing</a><a href="/b">Read more about security</a>

Example

✕ Fails
<p><a href="/a">Read more</a> and <a href="/b">Read more</a></p>
✓ Passes
<ul><li><h3>Basic</h3><a href="/buy/basic">Buy now</a></li><li><h3>Pro</h3><a href="/buy/pro">Buy now</a></li></ul>

Each "Buy now" sits in its own list item, whose heading disambiguates it.

Example

✕ Fails
<a href="/sale">Deals</a><a href="/clearance">Deals</a>
✓ Passes
<a href="/sale?utm_source=mail">Deals</a><a href="/sale?utm_source=footer">Deals</a>

Tracking-param and fragment-only differences are the same destination, as are relative spelling variants ("a.html" vs "./a.html").

WCAG success criteria

The purpose of each link should be clear from its text (or its programmatically-associated context).

Understanding 2.4.4

Standards

This rule contributes to the following standards:

WCAG A EN 301 549

Standard Criteria
EN 301 549 9.2.4.4

References