aria-label for Links: How to Fix 'Read More' Accessibility

January 2021: the Biden administration issues an executive order on federal accessibility. March 2022: agencies submit improvement plans. December 2023: GAO reports "limited progress." Meanwhile, across millions of web pages, the same link text appears over and over: "Read more. Read more. Read more."

The pattern is so common it barely registers as a problem — until a screen reader user opens their link list and finds forty identical entries with no context. WCAG Technique ARIA8 (opens in new window) exists specifically to fix this. Understanding it properly — what it does, what it doesn't do, and where it fits in a compliance strategy — matters more than most development teams realize.

The Technique

WCAG Technique ARIA8 (opens in new window) describes a specific, sufficient method for meeting two success criteria: 2.4.4 Link Purpose (In Context) (opens in new window) and 2.4.9 Link Purpose (Link Only) (opens in new window). The technique uses the aria-label attribute to provide a descriptive text label on a link when no visible element on the page already describes it.

The W3C's description is precise on an important point: if descriptive elements are visible on the page, aria-labelledby should be used instead. aria-label is the tool for when there's nothing visible to reference. This distinction matters — teams that reach for aria-label when aria-labelledby would work are adding hidden text where they could be leveraging existing content.

The technique also carries a specific implementation requirement that's easy to miss. Per the Accessible Name and Description Computation (opens in new window), aria-label overrides the visible link text entirely. Assistive technologies read the aria-label value, not the anchor text. The W3C therefore recommends starting the aria-label value with the visible link text — this preserves consistency for users across different interaction modes, and it satisfies Success Criterion 2.5.3 Label in Name (opens in new window), which requires the visible label to be present within the accessible name.

Why This Matters

Screen reader users frequently navigate pages by pulling up a list of all links — a standard feature in JAWS, NVDA, VoiceOver, and TalkBack. When that list shows twenty instances of "Read more," the user has no way to distinguish destinations without returning to each link's surrounding context. That's not a minor inconvenience. It's a fundamental barrier to independent navigation.

Keyboard-only users face a related problem: tabbing through links in sequence, they hear the same label repeatedly with no way to assess whether the next link is relevant before activating it. For users with cognitive disabilities, repetitive identical labels create confusion that can make a page genuinely unusable.

The legal exposure here is real. 2.4.4 Link Purpose (In Context) (opens in new window) is a Level A criterion — the baseline. Failing it isn't a nuanced judgment call; it's a documented, automatable violation. DOJ's web accessibility guidance (opens in new window) under Title II and Title III both treat WCAG 2.1 Level AA as the operative standard, and repeated identical link text is among the most commonly cited issues in demand letters and settlement agreements.

How It Works

The W3C's example from the technique document is worth examining directly. Given a news article summary with a "Read more" link, the correct implementation looks like this:

<h4>Neighborhood News</h4>
<p>Seminole tax hike: Seminole city managers are proposing a 75% increase 
in property taxes for the coming fiscal year. 
  <a href="taxhike.html" aria-label="Read more about Seminole tax hike">
    Read more
  </a>
</p>

Note the structure: the aria-label begins with "Read more" — the visible text — and then extends it with context. The screen reader user hears "Read more about Seminole tax hike." The sighted user sees "Read more." Both users get the information they need. The visible label is preserved within the accessible name, satisfying 2.5.3.

What the technique does not support: using aria-label to describe a link whose visible text is already descriptive, or using it as a workaround for poor content design. If your links said "Seminole tax hike details" and "Baby Mayor election results," you wouldn't need ARIA8 at all. The technique is a bridge, not a substitute for writing clear link text in the first place.

The related success criteria this technique addresses:

Applying This

The practical challenge is that "Read more" links are often generated dynamically by CMS templates — they're not hand-coded in HTML. That changes where the fix lives.

In code review: Flag any <a> element whose text content is a generic phrase ("read more," "click here," "learn more," "details," "here") without an accompanying aria-label or aria-labelledby. This is a straightforward pattern match.

In automated testing: Tools like axe-core will flag links with identical accessible names as a violation of 2.4.4. However, automated tools catch at most 37% of accessibility issues — which means manual review of link lists remains necessary. In NVDA or JAWS, open the links list (Insert+F7 in JAWS) and scan for duplicate entries. That's the actual user experience.

In CMS or template work: The fix often lives in the template, not the content. A WordPress or Drupal "Read more" block can be configured to append the post title to the aria-label programmatically. One template fix covers hundreds of pages.

Quick wins vs. longer fixes: Patching existing pages with aria-label on repeated links is fast. Building the pattern into content templates is the sustainable fix. Do both — patch now, template for the future.

One caution worth flagging: aria-label creates a disconnect between what sighted users see and what assistive technology announces. That gap can cause confusion in mixed-ability environments and complicates quality assurance. The compliance framework research on organizational paralysis is relevant here — teams sometimes over-apply ARIA solutions when the underlying content design is the actual problem. ARIA8 is a valid, sufficient technique; it's not always the best one.

CORS Perspective

Through a Risk/Legal Priority lens, ARIA8 addresses a Level A failure that appears in automated scans, shows up in DOJ demand letters, and affects a broad user population — screen reader users, keyboard navigators, and users with cognitive disabilities. The operational reality is that the fix is often a template change, not a page-by-page remediation effort, which makes it high-ROI relative to its legal exposure. Strategically, teams that fix repeated link text early demonstrate good-faith compliance effort — which matters in litigation contexts where courts and agencies assess whether an organization is making genuine progress toward equal access, not just responding to complaints.