WCAG 2.4.4: Link Purpose (In Context)

What This Rule Means

WCAG 2.4.4 — Link Purpose (In Context) — is a Level A success criterion under the Operable principle. It states that the purpose of each link must be determinable from the link text alone, or from the link text combined with its programmatically determined link context. If neither is sufficient, the link fails this criterion.

The phrase "programmatically determined link context" is carefully defined by WCAG. It refers to information that can be derived from the same sentence, paragraph, list item, or table cell as the link, or from the heading that precedes a section containing the link. It also includes context exposed through ARIA relationships such as aria-labelledby or aria-describedby. Critically, this context must be programmatically available — meaning that assistive technologies can read it automatically — not merely visually implied for sighted users.

In practical terms, the following HTML elements and attributes are directly affected by this criterion: <a href> anchor elements, <area> elements in image maps, <button> elements that trigger navigation, elements styled or scripted to behave as links using ARIA roles such as role='link', and SVG <a> elements. The accessible name of the link — computed from its inner text, aria-label, aria-labelledby, or an alt attribute on a child image — is the primary vehicle for communicating purpose.

What counts as a pass: A link passes if a user can determine its destination or function without additional context (e.g., "Download the 2024 Annual Report as PDF"), or if the surrounding programmatic context makes the purpose clear (e.g., a "Read more" link inside a <li> that begins with the article title). The link text does not need to be globally unique across the entire page; it only needs to be unambiguous within its context.

What counts as a fail: Generic link text such as "click here", "read more", "here", "more", or "link" fails when the surrounding programmatic context does not disambiguate the destination. An image link with a missing or empty alt attribute also fails because the accessible name is absent entirely.

Official exception: WCAG acknowledges one exception. Where the link purpose is intentionally ambiguous — meaning that making the purpose known in advance would destroy its utility or that of the surrounding content — the criterion does not apply. This exception is extremely narrow and rarely applicable in real-world scenarios.

Why It Matters

Approximately 2.2 billion people worldwide have some form of vision impairment, according to the World Health Organization. Among them, blind users who rely on screen readers are most acutely affected by ambiguous link text. Screen reader software such as NVDA, JAWS, and VoiceOver allows users to navigate a page by generating a list of all links extracted from their context. When that list contains dozens of entries that all read "read more" or "click here", blind users cannot determine which link leads where without navigating back to each one and reading the surrounding content — a time-consuming and disorienting process.

Motor-impaired users who navigate using keyboard-only input, switch controls, or eye-tracking devices also benefit substantially. These users often tab through interactive elements sequentially and rely on the focused element's label to decide whether to activate it. Ambiguous link text forces additional navigation steps that increase fatigue and error rates.

Users with cognitive disabilities — including those with attention deficit disorders, memory impairments, or low literacy — benefit from clear, descriptive link text because it reduces the cognitive load required to understand a page's structure. They do not need to hold contextual information in working memory while scanning links.

A concrete real-world scenario: Consider an e-commerce product listing page that displays ten products, each with a "Buy Now" button and a "Learn More" link rendered identically. A blind user navigating the links list hears ten consecutive instances of "Learn More" with no indication of which product each link refers to. To purchase the correct product, they must read the entire surrounding context for each link — a process that can take minutes rather than seconds. With descriptive link text such as "Learn more about the Sony WH-1000XM5 Headphones", the same task takes a single navigation gesture.

Beyond accessibility, descriptive link text provides measurable SEO benefits. Search engine crawlers use anchor text as a signal to understand the content of the linked page. Descriptive, keyword-rich link text improves the crawlability and indexability of linked resources, contributing positively to search rankings. Additionally, clear link text reduces bounce rates and support requests by setting accurate user expectations before navigation occurs.

Related Axe-core Rules

• link-name: This rule checks that every <a> element with an href attribute, every element with role='link', and every <area> element has a non-empty accessible name. The accessible name is computed via the standard ARIA accessible name calculation: inner text content, aria-label, aria-labelledby, or the alt attribute of a child <img>. Axe flags a violation when the computed accessible name is empty, whitespace-only, or entirely absent. This rule catches the most severe form of 2.4.4 failure — links that are completely unnamed — but it cannot detect links whose names are technically present yet semantically meaningless (e.g., "click here" or "read more"), because automated tools cannot determine intent from generic strings.
• duplicate-id-aria: This rule checks that no two elements on the page share the same id attribute when that id is referenced by an ARIA attribute such as aria-labelledby or aria-describedby. Duplicate IDs used in ARIA relationships cause the browser to resolve the reference unpredictably — typically to the first matching element in DOM order — which can cause a link's accessible name to be computed from the wrong element entirely. For example, if two links each use aria-labelledby='product-title' and two elements share that ID, screen readers may announce the wrong product name for one or both links, directly violating 2.4.4. Axe flags this as a critical issue because the resulting accessible name is unreliable.

It is important to understand the limits of automated testing for this criterion. Tools like axe-core can verify that a link has an accessible name, but they cannot verify that the name is meaningful. A link named "here" passes the link-name rule automatically because the string is non-empty. Human judgment is required to assess whether generic link text fails 2.4.4. This makes manual testing an essential complement to automated scanning for this criterion.

How to Test

1. Automated scan with axe DevTools or Lighthouse: Install the axe DevTools browser extension (Chrome or Firefox) or run a Lighthouse accessibility audit in Chrome DevTools. Trigger a full-page scan and filter results for the rules link-name and duplicate-id-aria. Review each flagged element: confirm that the computed accessible name is absent or empty for link-name violations, and verify that duplicate IDs are breaking ARIA label references for duplicate-id-aria violations. Note that passing these automated checks does not guarantee full 2.4.4 compliance — proceed to manual steps.
2. Manual link list review: In NVDA with Firefox, press the Insert+F7 key combination to open the Elements List dialog and select "Links". Review every entry in the list in isolation, without visual context. Ask: can you determine where each link leads from its text alone? Repeat in JAWS with Chrome using Insert+F7 to open the Links List. In VoiceOver with Safari on macOS, press Control+Option+U to open the Web Item Rotor and select "Links". Any link whose purpose is ambiguous in isolation should be examined against its programmatic context.
3. Keyboard navigation test: Using only the Tab key, navigate through all interactive elements on the page. Each time focus lands on a link, read only the announced text (not the surrounding visual content). If you cannot determine the link's destination from what is announced, the link likely fails 2.4.4. Pay particular attention to icon-only links (social media icons, arrow buttons) and image links.
4. Context verification: For links that rely on surrounding context (e.g., "Read more" inside a list item), inspect the DOM to confirm that the contextual text is in the same sentence, paragraph, list item, or table cell as the link. Context that is only visually adjacent but not programmatically associated does not satisfy the criterion. Use browser DevTools to inspect the computed accessibility tree and confirm the relationship.
5. ARIA label audit: Search the page's source code for all uses of aria-labelledby and aria-describedby on link elements. Verify that each referenced ID exists exactly once in the document and that the referenced element contains the intended descriptive text. Use the browser's accessibility tree panel (available in Chrome DevTools under the Accessibility tab) to confirm the computed name for each link.

How to Fix

Icon-only link with no accessible name — Incorrect

<!-- An icon link with no text and no aria-label -->
<a href='https://twitter.com/accsible'>
  <svg viewBox='0 0 24 24' width='24' height='24'>
    <path d='M23 3a10.9 10.9...' />
  </svg>
</a>

Icon-only link with no accessible name — Correct

<!-- aria-label provides a descriptive accessible name for screen readers -->
<a href='https://twitter.com/accsible' aria-label='Accsible on Twitter'>
  <svg viewBox='0 0 24 24' width='24' height='24' aria-hidden='true' focusable='false'>
    <path d='M23 3a10.9 10.9...' />
  </svg>
</a>

Generic "Read more" links in a card list — Incorrect

<!-- Multiple identical link texts with no distinguishing context -->
<ul>
  <li>
    <h3>Istanbul Accessibility Summit 2024</h3>
    <p>Join us for the annual summit on digital inclusion.</p>
    <a href='/events/istanbul-2024'>Read more</a>
  </li>
  <li>
    <h3>New WCAG 2.2 Guidelines Released</h3>
    <p>W3C has published the updated guidelines.</p>
    <a href='/news/wcag-22'>Read more</a>
  </li>
</ul>

Generic "Read more" links in a card list — Correct

<!-- Option 1: Visually hidden text appended to the link -->
<ul>
  <li>
    <h3>Istanbul Accessibility Summit 2024</h3>
    <p>Join us for the annual summit on digital inclusion.</p>
    <a href='/events/istanbul-2024'>
      Read more
      <span class='sr-only'>about the Istanbul Accessibility Summit 2024</span>
    </a>
  </li>
  <li>
    <h3>New WCAG 2.2 Guidelines Released</h3>
    <p>W3C has published the updated guidelines.</p>
    <a href='/news/wcag-22'>
      Read more
      <span class='sr-only'>about the New WCAG 2.2 Guidelines</span>
    </a>
  </li>
</ul>

<!-- Option 2: Use aria-label to override the visible text entirely -->
<a href='/events/istanbul-2024' aria-label='Read more about the Istanbul Accessibility Summit 2024'>
  Read more
</a>

Image link with empty alt attribute — Incorrect

<!-- The image has an empty alt, making the link completely unnamed -->
<a href='/products/overlay-widget'>
  <img src='widget-logo.png' alt='' />
</a>

Image link with empty alt attribute — Correct

<!-- The alt attribute on the image provides the link's accessible name -->
<a href='/products/overlay-widget'>
  <img src='widget-logo.png' alt='Accsible Overlay Widget — product details' />
</a>

aria-labelledby referencing a duplicate ID — Incorrect

<!-- Two elements share the same ID; the second link resolves to the wrong label -->
<div>
  <span id='card-title'>Accsible SDK Documentation</span>
  <a href='/docs' aria-labelledby='card-title'>View</a>
</div>
<div>
  <span id='card-title'>Accsible Pricing Plans</span>
  <a href='/pricing' aria-labelledby='card-title'>View</a>
</div>

aria-labelledby referencing a duplicate ID — Correct

<!-- Each ID is unique; each link resolves to the correct label -->
<div>
  <span id='card-title-docs'>Accsible SDK Documentation</span>
  <a href='/docs' aria-labelledby='card-title-docs'>View</a>
</div>
<div>
  <span id='card-title-pricing'>Accsible Pricing Plans</span>
  <a href='/pricing' aria-labelledby='card-title-pricing'>View</a>
</div>

Common Mistakes

• Using "click here", "here", "more", or "read more" as link text without any supplementary accessible name via aria-label, aria-labelledby, or visually hidden <span> elements — these strings are meaningless when extracted from visual context by a screen reader.
• Adding an aria-label to a link that contains different visible text without ensuring the label begins with the visible text string — this violates WCAG 2.5.3 (Label in Name) and causes confusion for voice control users who attempt to activate the link by speaking its visible name.
• Setting alt='' on an image that is the sole content of a link, making the link's computed accessible name empty and causing a link-name violation — empty alt is correct for decorative images but not when the image is the only content of an interactive element.
• Applying aria-hidden='true' to the only text node inside a link, which removes the accessible name from the accessibility tree and leaves the link unnamed for screen reader users.
• Reusing the same id value across multiple elements that are referenced by aria-labelledby on different links, causing screen readers to compute the wrong accessible name for one or more links due to unpredictable ID resolution.
• Wrapping an entire card component (heading, image, paragraph, and button) in a single <a> tag, which causes screen readers to read out the entire card content as the link's accessible name — a verbose and disorienting experience — instead of using a brief, descriptive label.
• Relying solely on a CSS title attribute tooltip or a :hover pseudo-class to provide link context — the title attribute is inconsistently exposed by screen readers and is entirely inaccessible to keyboard-only users who cannot trigger hover states.
• Using the URL itself as the link text (e.g., <a href='https://example.com/p?id=12345'>https://example.com/p?id=12345</a>), which is unpronounceable by screen readers and meaningless to users with cognitive disabilities.
• Generating link IDs or ARIA attribute values dynamically with JavaScript frameworks without ensuring uniqueness — React, Vue, and Angular components rendered in lists frequently produce duplicate IDs unless explicit keying strategies are implemented.
• Forgetting to add focusable='false' to inline SVG icons inside links in Internet Explorer and older Edge versions, which causes the SVG to receive its own tab stop and causes screen readers to announce the SVG separately from the link text, splitting the accessible name computation.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular 2025/10, published in the Official Gazette No. 32933 on June 21, 2025, establishes mandatory digital accessibility requirements aligned with WCAG 2.2. WCAG 2.4.4 Link Purpose (In Context) is a Level A criterion, which means it falls within the mandatory baseline that all covered entities must achieve.

The circular applies to a defined set of entity types across both the public and private sectors. Public institutions — including ministries, state agencies, municipalities, and public universities — are required to achieve full Level A conformance within one year of the circular's publication. Private sector entities covered by the circular have a two-year compliance window. The private sector scope is broad and explicitly includes e-commerce platforms, banks and financial institutions, private hospitals and healthcare providers, telecommunications operators with 200,000 or more subscribers, travel agencies, private transportation companies, and private schools authorized by the Ministry of National Education.

For all of these entities, non-compliant link text represents a direct regulatory violation. Consider a Turkish e-commerce platform that displays product listing pages with repeated "Satın Al" (Buy Now) or "Devamını Oku" (Read More) links containing no programmatic context. A blind user relying on TalkBack, NVDA, or VoiceOver would be unable to determine which product each link refers to, constituting a failure of 2.4.4 and a breach of the circular's requirements. Similarly, a public hospital's appointment booking portal that uses icon-only navigation links without accessible names would fail both the link-name axe rule and the circular's mandate.

Compliance with 2.4.4 is not merely a technical checkbox. The circular signals a broader governmental commitment to digital inclusion for Turkey's approximately 8.5 million citizens with disabilities. For entities in scope, addressing link purpose failures proactively — through design system standards, developer training, and automated CI/CD scanning — is both a legal obligation and a sound investment in usability and search performance. Failure to comply within the mandated timeframes may result in regulatory action by the relevant supervisory authorities designated under the circular.