The 'Read More' Problem: Why Generic Link Text Breaks Digital Accessibility

I've been reviewing accessibility audits for over a decade, and there's one pattern that shows up in nearly every single report: generic link text. The WCAG repository example (opens in new window) perfectly captures what I see daily—multiple "Read More" links, endless "Click Here" buttons, and "Learn More" text scattered across pages like digital breadcrumbs leading nowhere useful.

This isn't just a minor usability hiccup. For screen reader users navigating with link lists—a common and efficient browsing method—generic link text creates an impossible maze. Imagine tabbing through a page and hearing "Read More, Read More, Read More" with no context about what you're actually reading more about. It's like having a library where every book is titled "Book."

The Real User Impact

When screen reader users pull up a list of all links on a page (a standard navigation technique), they're presented with a menu that might look like this:

• Read More
• Read More
• Click Here
• Click Here
• Learn More
• Learn More

Without the surrounding visual context that sighted users rely on, these links become meaningless. Users are forced to navigate back to each link's context, dramatically slowing down their browsing experience and often leading to frustration and abandonment.

This violates WCAG 2.4.4 (Link Purpose) (opens in new window), which requires that link purpose be determinable from the link text alone or from the link text together with its programmatically determined link context.

Why Development Teams Keep Making This Mistake

Through the CORS framework lens, this is fundamentally an Operational Capacity problem. Most development teams aren't intentionally creating barriers—they're working within systems and processes that don't account for accessibility from the start.

The typical workflow goes like this: designers create mockups with generic "Read More" buttons because it looks clean and consistent. Content management systems get built with template structures that replicate this pattern. Developers implement exactly what's designed. Nobody in the chain is thinking about the screen reader experience because nobody in the chain regularly uses a screen reader.

This connects directly to what we've documented in The Implementation Crisis—teams have access to accessibility knowledge but lack the operational processes to apply it consistently.

The Technical Solutions Are Straightforward

The good news? Fixing duplicate link text doesn't require major architectural changes. Development teams have several practical approaches:

Option 1: Descriptive Link Text

<!-- Instead of: -->
<a href="/article1">Read More</a>

<!-- Use: -->
<a href="/article1">Read More About Keyboard Navigation Best Practices</a>

Option 2: ARIA Labels

<a href="/article1" aria-label="Read More About Keyboard Navigation Best Practices">Read More</a>

Option 3: Visually Hidden Context

<a href="/article1">Read More <span class="sr-only">About Keyboard Navigation Best Practices</span></a>

The WCAG repository example mentions HAL (likely an automated tool) that "detects duplicate or generic link text and enhances with aria-label incorporating surrounding context." This represents exactly the kind of systematic approach that works—building accessibility checks directly into the development workflow.

Building Sustainable Processes

The most effective teams I work with have moved beyond case-by-case fixes to systematic prevention. They've integrated accessibility checks into their component libraries, established design system guidelines that require descriptive link text, and set up automated testing that flags generic links during development.

This aligns with our research on automated testing limitations—while tools can catch duplicate link text, the human judgment about what makes link text truly useful still requires manual oversight.

Community Impact: Screen reader users, users with cognitive disabilities, and anyone navigating by keyboard benefit from descriptive link text. This is especially critical for users who rely on link lists for quick page navigation.

Risk Considerations: Generic link text is easily detected by automated scanning tools and represents clear WCAG violations that frequently appear in accessibility lawsuits. The Department of Justice (opens in new window) has specifically called out unclear navigation as a barrier to equal access.

Strategic Alignment: Unlike some accessibility improvements that require significant investment, fixing link text is typically a content and template issue that can be resolved without major development resources. This makes it an easy win for leadership looking to demonstrate accessibility progress.

The path forward isn't complicated: audit your existing content for generic link text, establish clear guidelines for new content, and build those guidelines into your design systems and content management workflows. Your screen reader users—and your legal team—will thank you.

For teams just starting this work, the Pacific ADA Center (opens in new window) provides excellent resources on web accessibility basics, including detailed guidance on creating meaningful link text that serves all users effectively.