When "Cleaner" Link Text Creates Barriers

Designers often make accessibility decisions based on how an experience performs with a screen reader. That lens makes sense: if semantics and naming work for screen reader users, they should work for other assistive technologies too. But this framing subtly assumes that blindness is the primary disability experience — and it isn’t. Screen reader users are not all blind, and the majority disability experience is actually depression, which can significantly impact cognition and comprehension.

The trap is overcorrecting for one disability and inadvertently harming another. Partially visually hidden link names are a prime example. They can help screen reader users understand a link's destination, but they create real problems for people using voice control software. Good design needs to flex across the full range of interaction methods, not just the ones most commonly discussed in accessibility tutorials.

Why Hidden Text Is Used

Unique accessible link names matter because screen readers can pull all links from a page and present them as a list, stripped of surrounding context. Eleven links reading "learn more" become meaningless. Giving each link a descriptive accessible name solves that.

Many CSS frameworks, including Bootstrap and Tailwind, ship utility classes for visually hidden content — text that screen readers can read but that doesn't render on screen. These are commonly used for heading structure and other way-finding aids.

A related pattern partially hides a link's text so only part of its accessible name is visible. This is common in card components with CTA links, where designers decide the truncated label looks more polished. The same effect is often achieved with an aria-label instead of a visually hidden class. ARIA, though, should only be used when no alternatives exist. Improper use of aria-label can violate WCAG Success Criterion 2.5.3 Label in Name, may not survive translation, and makes the accessible name impossible to see — meaning users can't know what phrase they'd need to utter to activate the control.

The Voice Control Problem

A truncated CTA like "Learn more" paired with visually hidden text such as "about our return policy" is inaccessible in ways that go beyond screen readers. People affected include those:

  • Using screen magnification or enlarged default fonts, where the CTA appears without the card context around it;
  • With cognitive or digital literacy challenges, where the visible fragment doesn't describe the destination;
  • Who aren't fluent in the page's language and can't infer meaning from surrounding content;
  • Using voice control software, which requires the full accessible name to target a link by voice.

Apple's Voice Control on macOS and iOS does not accept "Click learn more" when the link's accessible name is longer. It listens for the full name, including the visually hidden portion. Since that portion isn't visible, users have no way to know what to say — unless they've inspected the code or use a screen reader alongside their voice control.

The Voice Control Landscape

Voice control covers a broad range of software. Every major operating system offers something:

  • Windows: Voice Recognition;
  • macOS and iOS: Voice Control;
  • Android: Voice Access.

Voice assistants like Siri, Cortana, and Alexa are a lighter-weight category; they can handle some but not all of the functionality dedicated voice control provides. More specialized third-party tools include Dragon, which supports dictation and web browsing, and Talon Voice, which emphasizes scripting and customization.

Voice control users are more common than many assume. If you've asked Siri to set a timer, you're a voice control user. But persistent, long-form use of Voice Control, Dragon, or Talon is typically tied to conditions that may be temporary or permanent, circumstantial or biological: full or partial paralysis, inability to use hands, fine motor limitations, repetitive strain, or lowered cognition. And disability isn't binary — multiple conditions often co-occur.

Workarounds Exist, But Why Require Them?

Some voice control software compensates. Dragon, for instance, detects links containing the phrase "learn more" and assigns each a number — users say a number instead of the link name. Most other voice control tools let users display numbered overlays across interactive controls, or use an on-screen grid to zoom into specific areas.

But on macOS and iOS, activating a partially hidden link by name is only possible if you already know these alternate commands. That constraint turns the issue into a measure of digital literacy — how well someone knows specialized software, not just how well they can see.

For tools with numbered overlays or heuristics, the question shifts: why force a disabled user to do extra work per link when an abled user just clicks? That extra effort compounds across sessions and across the web, becoming exhausting rather than merely inconvenient.

That leads to the real choice: keep the truncated aesthetic and build barriers, or show the full link name to everyone. As accessibility advocate Billy Gregory put it well: when UX doesn't consider all users, it becomes "SOME User Experience" — or SUX.

Truncation and Icon-Only Controls

Ellipsized links deserve the same skepticism. A link with part of its name cut off visually is similarly hard to activate by voice without pulling up number overlays. As content strategist Karen McGrane says, "Truncation is not a content strategy."

Icon-only buttons create the same issue in another form. If an icon button has no visible label at all — and the icon is abstract, obscure, or jargon-encoded — users may not know what it does. Voice control workarounds exist here too, but again, they force an unnecessary burden on the user.

Reconsidering Pixel-Perfect Layouts

Revealing full link names may mean link text wraps to multiple lines within a card. In a grid of cards, heights will become uneven. That's something design should already accommodate through considerations like:

  • Content of variable length;
  • Grid placement and negative space with changing content height;
  • Structural changes like added badges or removed descriptions;
  • Translation and localization;
  • Failure states where images don't load.

Adjusting existing work may involve content writers, developers, and project managers. Sometimes small tweaks are enough; sometimes entirely new content is called for. This kind of collaborative adjustment is most effective when accessibility thinking shifts left into the early conception phase, so these decisions aren't retrofits but part of the foundation.

Practical Steps for Voice-Compatible Controls

For links, buttons, and other interactive elements, the following checks help ensure compatibility with voice control:

  • Display the full, visible text of the control’s name.
  • Assign each control a unique, accessible name within the current view.
  • Do not override visible names with aria-label, which can mask the label users see and say.
  • Avoid relying solely on a cryptic or abstract icon, particularly when the action is uncommon.

These measures substantially improve the usability of voice-driven navigation and reduce friction for users relying on such tools.

Broader Lessons Beyond Voice Input

This problem isn’t isolated to voice control. The underlying principles extend to general accessibility work:

  1. Testing across a spectrum of assistive technologies is the only way to understand true support.
  2. Giving users agency means relinquishing some control over how they interact with your interface.
  3. Design decisions carry outsized impact, often in ways that aren’t immediately visible.

Interfaces must remain flexible and adaptable to accommodate the many methods people use to interact, from voice to switch devices to screen readers. Designing for that diversity is not a separate exercise, but part of building robust, user-centered experiences.