Links communicate intent. Users rely on link text to decide whether activating a link will take them where they expect. When link names are unclear or misleading, users may activate the wrong link or avoid navigation entirely.
WCAG does not explicitly state that links with the same name must always have the same purpose. However, WCAG does require that each link’s purpose be determinable. When multiple links share the same accessible name, that requirement becomes harder to meet unless the name reliably communicates what will happen.
This guidance explains how identical link names can create accessibility issues in practice, and how to avoid them.
WCAG Success Criteria
WCAG 2.4.4 Link Purpose (In Context) (Level A)
The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context.
This is a Level A requirement and applies to all WCAG conformance levels.
WCAG allows link purpose to be determined from context, not only from the link text itself.
Interpreting the Requirement in Practice
When multiple links share the same accessible name, WCAG 2.4.4 effectively requires that the name still reliably communicates purpose.
In practice, this means:
- Identical link names should not lead to meaningfully different destinations unless
- Additional context is programmatically available to disambiguate them
This is a derived heuristic, not normative WCAG language.
What “Similar Purpose” Means (Clarified)
For the purposes of accessibility evaluation, similar purpose means:
- The links lead to the same destination, or
- The links lead to destinations that users would reasonably expect to behave the same way
(for example, article detail pages within the same list or section)
If links perform different actions or lead to unrelated content, they should not share the same accessible name unless context clearly distinguishes them.
How Users Experience This
Screen Reader Users
Screen readers often provide a list of links, announced only by accessible name. In this mode, the surrounding visual layout is removed.
If a user hears:
- “Read more”
- “Read more”
- “Read more”
With no additional context, the user cannot determine which link to activate.
Context That Does Pass WCAG
WCAG allows identical link text when the programmatic context provides meaning.
<h2>News</h2>
<a href="story1.html">Read more</a>
<h2>Events</h2>
<a href="event1.html">Read more</a>If the headings are properly associated in the accessibility tree, this passes WCAG 2.4.4, because the link purpose can be determined from context.
Sighted and Cognitive Users
Sighted users may rely on nearby headings or grouping, but repeated identical link text can still cause confusion in dense layouts. Clear naming reduces cognitive effort and improves predictability.
Markup Examples That Work
Descriptive Link Text (Preferred)
<a href="routes.html">Current routes at Boulders Climbing Gym</a>This approach is robust and works in and out of context.
Using aria-label to Clarify Purpose (Use Cautiously)
<a href="taxhike.html" aria-label="Read more about Seminole tax hike">Read more</a>
<a href="babymayor.html" aria-label="Read more about Seminole's new baby mayor">Read more</a>This creates distinct accessible names while keeping short visible text.
Caution:
Using aria-label overrides the visible text for screen readers and can create a mismatch between what sighted users see and what assistive technology announces. In many cases, improving the visible link text is the better solution.
Graphical Links
<a href="routes.html">
<img src="topo.gif" alt="Current routes at Boulders Climbing Gym">
</a>The image’s alt text becomes the link’s accessible name.
Why This Matters
Users frequently encounter links out of context, especially when using assistive technologies. When link names are ambiguous or reused inconsistently, users may lack sufficient information to choose the correct link.
Best practice follows a simple principle:
- Same destination or behavior → consistent naming
- Different destination or behaviour → distinguishable naming
This also aligns with WCAG 3.2.4 Consistent Identification, which requires consistency for components with the same functionality.
How to Fix the Problem
- Review links with identical accessible names
- Confirm that either:
- They lead to the same or similar destinations, or
- Programmatic context clearly disambiguates them
- Prefer improving visible link text before adding ARIA
- Use aria-labelledby when referencing an existing visible context is appropriate
Who Is Affected
Screen reader users are most affected due to link-list navigation. Users with cognitive disabilities also benefit from predictable, explicit link naming. Ambiguous links increase cognitive load and reduce navigation confidence.
Rule Description (Derived Guidance)
When multiple links share the same accessible name, authors should ensure that the name reliably communicates purpose. If links serve different purposes, they must be distinguishable either through their accessible names or through programmatically associated context.
Automated Testing Logic (Non-Normative)
The following reflects how some automated testing tools evaluate link naming. This logic is not part of WCAG itself.
- Results may be undefined when a link has no accessible name
- Results may be undefined when the name contains only symbols or emojis
- Links with valid accessible names are evaluated for consistency and clarity
Automated results should always be confirmed with manual review.
Wrapping Up
WCAG 2.4.4 does not require global consistency of link names, but it does require that the link purpose be determinable. When identical link names are used, they must not create ambiguity for users, especially when links are encountered out of context.
Treating “same name, same purpose” as a practical guideline, rather than a strict rule, helps authors meet WCAG requirements without overconstraining design. Clear, context-aware link naming improves usability, predictability, and accessibility for all users.
