Links are supposed to be the easy part. You write a few words, wrap them in an , and move on.

But ARIA links have a way of turning “easy” into “why is this broken in Safari” surprisingly fast. Not because ARIA is bad, and not because links are fragile. It usually happens when we start doing clever things to link text. We hide it. We replace it. We split it into tiny pieces for styling. Then we assume every tool people use will still understand the link the same way.

That assumption is where the trouble starts.

The focus here is understanding why ARIA links break across browsers, what the testing uncovered, and how small markup choices can ripple out into very real barriers for users.

How ARIA Links Get Their Accessible Name

A link needs a name. That name is what tools use to announce it, list it, or make it usable.

In the best case, the name is just the visible text inside the link. Simple, reliable, and supported everywhere.

When we start building ARIA links, we often change that name in one of two ways. We override it with aria-label, or we hide the visible text (often with aria-hidden) and hope ARIA will fill the gap.

Here’s the catch. Screen readers look at the accessibility tree, where ARIA is meant to live. But many browser-native features do not behave like screen readers. Some look at rendered text instead. Some use a simplified “reading view” model. Some apply their own rules to decide what counts as readable content.

So an ARIA label can be “correct” in the accessibility tree, yet still get ignored by other tools that your users rely on.

ARIA Link Patterns That Break Across Browsers

In the original write-up, the author tried a bunch of versions of the same link, including multilingual cases. Three patterns kept causing breakage.

ARIA Links and aria-label on Visible Text

This is a common move. It can happen on purpose, like when someone wants a “cleaner” name, or by accident, like when a component always injects an aria-label.

In the tests, browser speech tools did not treat that aria-label as the link’s name. Edge Read Aloud did not announce the aria-label value for any link. Chrome reader mode text-to-speech did not announce the aria-label value for any link. Safari’s Speech feature did not announce the aria-label value for any link.

So you end up with ARIA links that may sound fine in a screen reader, but feel unlabeled in browser read-aloud tools. That’s a big deal because a lot of people use read-aloud features without ever touching a screen reader.

There’s another issue too. In the tests, the aria-label values were intentionally different from the visible label so it was easy to spot. That mismatch causes a known WCAG barrier (SC 2.5.3 Label in Name), but the practical problem is even simpler. Users hear one thing and see another. That erodes trust fast.

ARIA Links and aria-hidden Inside Links

This one looks harmless until it isn’t.

aria-hidden="true" removes content from the accessibility tree. If the text inside your link is hidden, then for many tools, the label is effectively gone.

In the tests, Chrome Reader Mode visually hid every link with aria-hidden. Firefox Reader Mode visually hid every link with aria-hidden. Edge Read Aloud did not announce links with aria-hidden, regardless of other attributes. Chrome reader mode text-to-speech did not announce links with aria-hidden, regardless of other attributes.

So now your ARIA links can disappear from reader views, or get skipped by speech features, even though they still look clickable on the standard page.

There was also a more subtle interaction issue. When the tester highlighted aria-hidden links, Chrome and Edge wouldn’t let them link to the highlighted text, though that behavior shifted once more content was added. Either way, it’s a reminder that hiding text changes more than announcements. It changes how pages behave.

ARIA Links With Split Text Spans

This is the “design made me do it” pattern. It’s often used for animations, hover effects, or custom typography.

The tests showed it can create a surprising amount of fallout. Text split into letter spans did not auto-translate. Firefox Reader Mode styled span-split links as white instead of blue or purple. Safari Speech jumped past most of the page when it hit span-split text. After that jump, Safari announced subsequent links with the wrong link text, including pulling Korean text for English links. Safari Speech did not announce the span-separated letters and also did not announce the visible word those letters formed.

So you can end up with a link that looks fine, but breaks translation, looks unclickable in reader view, and causes speech tools to lose their place.

That last part is especially rough. When a speech feature starts skipping content or mislabeling later links, the whole page becomes harder to trust. Users can’t just “work around” that.

Cross-Browser Results for ARIA Links

One of the best takeaways from the cross-browser checks is this: these are not edge-case bugs in one browser. Each browser failed in its own way.

Chrome and Edge

• Reader mode and text-to-speech ignored aria-label on links.
• Reader mode hid links when aria-hidden was involved.
• Some selection and “link to highlight” behavior broke around aria-hidden content.

Firefox

• Reader view hid aria-hidden links.
• Span-split links lost normal link styling and showed up as white text.

Safari

• Speech skipped content after span-split links.
• It then announced later links with the wrong label, sometimes in the wrong language.
• It ignored aria-label values for link naming.

If your testing only includes one browser and one screen reader, it’s easy to miss all of this. The links will “work” in the sense that you can click them. But they won’t work the same way for people who browse differently.

Why ARIA Links Break in Reader Mode and Speech

ARIA labels live in the accessibility tree. Many browser reading tools do not rely on that tree the way screen readers do. Instead, they often prioritize what they can extract from rendered text or from a simplified reading model.

On top of that, aria-hidden removes content from the tree, and some tools treat that as “remove from reading,” not merely “ignore for screen readers.” When the visible label is hidden, those tools are left with less content to work with, and the link can become empty or disappear.

Per-letter spans create a different kind of problem. They turn a word into fragments, and many tools don’t rebuild those fragments into a single word reliably. Translation and reading modes are especially sensitive here because they’re trying to extract coherent content, not just replay the DOM.

So the link is still a link, but its label becomes unstable. It might be visible but not readable to speech. It might be readable in one mode but missing in another. It might translate in one browser but not another.

That inconsistency is the barrier.

What Broken ARIA Links Feel Like for Users

When ARIA links fail this way, users don’t experience it as “ARIA isn’t supported.” They experience it as missing information, broken reading flow, or a page that feels unreliable.

Reader Mode can show a page that looks mostly right, but key links are missing. Read-aloud can skip links or move through them without saying their names. Translation can work for paragraphs while navigation or call-to-action links remain untranslated. Links can lose their visual cues in reading view and look like plain text, which makes people hesitate to click.

Speech tools can be the most disruptive. When they jump around, skip content, or start announcing the wrong link text, users lose confidence in the whole page. Even basic tasks like highlighting and sharing text can become awkward when the words inside the link aren’t treated as real text.

None of this requires a screen reader. These are everyday tools. Plenty of users lean on them for fatigue, focus, dyslexia support, language support, low vision support, or just convenience.

Safer Patterns for ARIA Links

You don’t have to give up design. You just need to be careful about what you do to the actual link label.

Keep a real text label in the link. If your link has visible text, keep it as real text inside the <a>. That’s the most stable way to get a consistent accessible name across tools.

Use aria-label only when there is no visible text. Icon-only links are the right case for this. If text exists, it should usually carry the name.

Avoid aria-hidden on link labels. If an icon is decorative, hide the icon. Do not hide the words people need.

Avoid splitting words into separate spans. If you want animation, animate the container, an underline, a background, or a pseudo-element. Keep the word intact.

If you inherit a design system that already does this, treat it like a compatibility issue and add guardrails. Make sure there’s still a readable text node somewhere that tools can use. Keep the visible label aligned with the computed name. Test in Reader Mode and speech features, not only in screen readers.

Quick Tests for ARIA Links

A few fast checks can reveal the same problems that showed up in the browser experiments. These don’t take long, but they make it clear whether your link text holds up beyond a screen reader.

• Open Chrome Reader Mode and confirm the links still appear, still look like links, and keep the right text.
• Use Edge Read Aloud and listen for link names. Watch for links that go silent.
• Try Firefox Reader View and make sure the links keep normal styling instead of turning into plain text.
• Use Safari Speech and watch for skipped sections or incorrect labels on later links.
• Translate the page and see whether link text is translated as a full word instead of letter fragments.
• Highlight link text and check that selection behaves normally across the whole label.
• Inspect the accessibility tree to confirm the computed name matches what’s visible.
• Finish with a screen reader pass as a second layer instead of the only one.

If a link pattern fails any of these, it’s a sign your ARIA links are doing too much.

Sanity-Check Your ARIA Links

If your links have been “mostly fine” in screen reader checks but still feel weird in Reader Mode or read-aloud, you’re not alone. That’s exactly why these patterns are sneaky. They don’t break the click. They break the label, the reading flow, and the trust people build as they move through a page.

The upside is you don’t need a big rebuild to clean this up. Start with one or two link components that get used everywhere. Keep the visible text intact. Be careful with aria-label when text is already on screen. Don’t hide the label with aria-hidden. Avoid splitting words into lots of spans. Then run the quick checks again. When it’s fixed, you’ll hear it right away.

At 216digital, we help teams pressure-test link patterns in the same places users feel these failures. Reader modes, speech tools, translation, selection, and yes, screen readers too. If your components rely on ARIA links or stylized link labels, schedule an ADA Strategy Briefing. We’ll help you tighten the markup so links stay predictable across the tools and browsers your users actually use.