Skip to main content

Accessibility issue guide · link purpose

Make every link explain where it goes.

Clear link text helps people decide what to open, especially when they navigate by keyboard, magnification or a screen-reader links list. Automation can find links with no accessible name; a person must still judge whether the words are useful.

Scan a page for link issues No signup. Then review wording in context.

Purpose in context

A name is necessary. A useful destination is the real test.

WCAG 2.2 Link Purpose (In Context) requires each link's purpose to be determinable from the link text alone or from the link text together with programmatically determined context, except where the purpose would be ambiguous to users generally.

The stricter Link Purpose (Link Only) criterion asks for the purpose from the link text alone, with the same general-ambiguity exception. That distinction matters: “Read more” may have enough associated context to avoid one failure, yet a descriptive link is usually easier to scan and understand.

Primary guidance: W3C's explanations of Link Purpose (In Context) and Link Purpose (Link Only).

Controlled fixture · axe-core 4.11

The empty link failed. “Read more” passed automation.

We ran axe-core's link-name rule against three links. An icon-only link hidden from assistive technology returned one serious finding. Both “Read more” and “Compare ClearSite monitoring plans” returned zero violations, showing why a clean scan cannot judge whether link wording is sufficiently descriptive.

Unnamed · serious finding

The icon exposes no link name

<a href="/plans">
  <svg aria-hidden="true">…</svg>
</a>

Named · automation clear

Generic text still needs judgement

<a href="/plans">Read more</a>

Descriptive · automation clear

The destination is predictable

<a href="/plans">Compare ClearSite monitoring plans</a>

This is a controlled fixture, not customer evidence or a conformance claim. It demonstrates the automation boundary; W3C's F84 failure example documents a link with no discernible text.

Four repair patterns

Write for people choosing among links, not for the layout around them.

Name the destination or action

Replace generic text with words that still make sense when read on their own.

<a href="/plans">Compare monitoring plans</a>

Give icon-only links an accessible name

Keep the visible icon, but expose a concise name to assistive technology.

<a href="/account" aria-label="Open account settings">
  <svg aria-hidden="true">…</svg>
</a>

Use context deliberately

A short link can rely on its sentence or list item at WCAG Level A, but the relationship must be programmatically determinable and clear.

<p>Starter includes weekly checks. <a href="/plans">View Starter details</a></p>

Keep repeated links distinguishable

Cards and article lists should identify their destination instead of repeating an unexplained “Read more”.

<a href="/guides/form-labels">Read the form-label guide</a>

From finding to verified fix

Check the rendered name, then review the wording.

  1. 01

    Locate the reported link

    Open the rendered page and identify the exact anchor and destination. Check whether the visible text, image alternative or accessible name is missing.

  2. 02

    Read it away from the layout

    Inspect the link text alone and with its programmatically associated context. Ask whether the destination or result is predictable before activation.

  3. 03

    Repair the shared source

    Change the card, navigation, icon-button or content template that creates the weak link rather than patching one rendered page.

  4. 04

    Re-scan the same URL

    Confirm any machine-detectable link-name finding clears and that the destination still resolves correctly.

  5. 05

    Review the page as a person

    Use the links list in a screen reader or scan the repeated anchors visually. Check that duplicate wording does not hide different destinations.

What ClearSite can detect

Links that axe-core can determine have no accessible name, with the affected rendered element and rule attached to the finding.

What a re-scan can prove

Whether that machine-detectable link-name finding clears after the repaired component is rendered.

What still needs a person

Whether each destination is predictable, repeated links remain distinguishable and the wording makes sense in its programmatic context.

Browse the website accessibility issue library, compare the form-label repair guide and keyboard-focus guide, or read the automated testing workflow and limits.

Find the empty links. Then make every destination clear.

Use automation to narrow the queue, repair the shared source and finish with a human review of wording and context.

Run the free scan