Barriers from Links with ARIA
Today Temani Afif asked a question:
Are the below codes equivalent if we consider all the aspects? (a11y, semantic, something else maybe?)
If not, what is missing (or should be changed) in the second code
![]()
I have my canned response that aria-label auto-translation is inconsistent.
But the something else maybe
question is what reminded me that this construct has caused issues outside of WCAG concerns. In particular, the only assistive technologies (AT) that consume ARIA are screen readers and, to a far lesser extent, voice control. That latter part only because browsers assemble the accessible names, not AT. There’s plenty more AT that never touches ARIA.
I knew there were issues, but couldn’t rattle them off from the top of my head. So I built some examples and poked them with other accessibility features of browsers.
Results
I am not testing screen readers nor voice control.
- The text with each letter in its own span does not auto-translate..
- Edge’s Read Aloud feature (Ctrl + Shift + U) does not announce the
aria-labelvalue of any link. - Edge’s Read Aloud feature does not announce the links with
aria-hidden, regardless of other attributes. - Chrome’s reader mode text-to-speech does not announce the
aria-labelvalue of any link. - Chrome’s reader mode text-to-speech does not announce the links with
aria-hidden, regardless of other attributes. - Chrome’s reader mode visually hides every link with
aria-hidden. - Firefox’s reader mode visually hides every link with
aria-hidden. - Firefox’s reader mode visually styled every link that spanned its letters as white instead of blue or purple.
- Safari’s Speech feature jumps past most of the page when it gets to the first instance of letters split across spans, and announces subsequent links with the wrong link text (using the Korean text for English links).
- Safari’s Speech feature does not announce the
aria-labelvalue of any link. - Safari’s Speech feature does not announce the span-separated letters nor visible word they make up.
- Chrome and Edge would not let me link to the highlighted text when I highlighted the
aria-hiddenlinks, though that changed when I got more content on the page.
As Amelia Bellamy-Royds points out, the text-to-speech features seem to respect the aria-hidden but ignore the aria-label — and by extension the accessible name the browser provides in the accessibility tree.
Takeaways
Three key takeaways here (yes, I know your use case is special):
- Don’t use
aria-labelon links; - Don’t use
aria-hiddenwithin links; - Don’t split the letters of a word across elements.
I look forward to you, dear reader, trying other approaches and letting me know where these fall down (or what I got wrong). I don’t need to know where they are supported. Just the gaps.
Tests
These are the tests I used to generate the results you just read (originally as a Codepen). You can ignore this part unless you want to run your own tests. If you want to find other ways these approaches might break for users, then please do so.
I used the Korean words 샌드위치 for “sandwich” and 망치 for “hammer” (the values of aria-label).
The links with aria-label all fail WCAG SC 2.5.3 Label in Name, but it’s intentional so I can quickly tell if the aria-label is exposed. Similarly, the links with aria-hidden and no aria-label fail 4.1.2 Name, Role, Value, but again I wanted to see how they performed.
- Standard link: Sandwich
<a href="https://en.wikipedia.org/wiki/Sandwich"> Sandwich </a>- Standard link in another language: 샌드위치
<a href="https://ko.wikipedia.org/wiki/%EC%83%8C%EB%93%9C%EC%9C%84%EC%B9%98" hreflang="ko" lang="ko"> 샌드위치 </a>-
Link with
aria-label: Sandwich <a href="https://en.wikipedia.org/wiki/Sandwich" aria-label="hammer"> Sandwich </a>-
Link in another language with
aria-label: 샌드위치 <a href="https://ko.wikipedia.org/wiki/%EC%83%8C%EB%93%9C%EC%9C%84%EC%B9%98" hreflang="ko" lang="ko" aria-label="망치"> 샌드위치 </a>-
Link with each letter of visible text in its own
<span>: Sandwich <a href="https://en.wikipedia.org/wiki/Sandwich"> <span> <span>S</span><span>a</span><span>n</span><span>d</span><span>w</span><span>i</span><span>c</span><span>h</span> </span> </a>-
Link in another language with each letter of visible text in its own
<span>: 샌드위치 <a href="https://ko.wikipedia.org/wiki/%EC%83%8C%EB%93%9C%EC%9C%84%EC%B9%98" hreflang="ko" lang="ko"> <span> <span>샌</span><span>드</span><span>위</span><span>치</span> </span> </a>-
Link with
aria-labeland each letter of visible text in its own<span>: Sandwich <a href="https://en.wikipedia.org/wiki/Sandwich" aria-label="hammer"> <span> <span>S</span><span>a</span><span>n</span><span>d</span><span>w</span><span>i</span><span>c</span><span>h</span> </span> </a>-
Link in another language with
aria-labeland each letter of visible text in its own<span>: 샌드위치 <a href="https://ko.wikipedia.org/wiki/%EC%83%8C%EB%93%9C%EC%9C%84%EC%B9%98" hreflang="ko" lang="ko" aria-label="망치"> <span> <span>샌</span><span>드</span><span>위</span><span>치</span> </span> </a>-
Link with
aria-hiddenon visible text with each letter of visible text in its own<span>: <a href="https://en.wikipedia.org/wiki/Sandwich"> <span aria-hidden="true"> <span>S</span><span>a</span><span>n</span><span>d</span><span>w</span><span>i</span><span>c</span><span>h</span> </span> </a>-
Link in another language with
aria-hiddenon visible text with each letter of visible text in its own<span>: <a href="https://ko.wikipedia.org/wiki/%EC%83%8C%EB%93%9C%EC%9C%84%EC%B9%98" hreflang="ko" lang="ko"> <span aria-hidden="true"> <span>샌</span><span>드</span><span>위</span><span>치</span> </span> </a>-
Link with
aria-labelandaria-hiddenon visible text with each letter of visible text in its own<span>: <a href="https://en.wikipedia.org/wiki/Sandwich" aria-label="hammer"> <span aria-hidden="true"> <span>S</span><span>a</span><span>n</span><span>d</span><span>w</span><span>i</span><span>c</span><span>h</span> </span> </a>-
Link in another language with
aria-labelandaria-hiddenon visible text with each letter of visible text in its own<span>: <a href="https://ko.wikipedia.org/wiki/%EC%83%8C%EB%93%9C%EC%9C%84%EC%B9%98" hreflang="ko" lang="ko" aria-label="망치"> <span aria-hidden="true"> <span>샌</span><span>드</span><span>위</span><span>치</span> </span> </a>
Don’t be shy about making your own variations and leaving your results in the comments.
Update: 5 February 2026
You know what? Just don’t split words into letters. It’s not just a problem with links, even if it’s more excitingly wrong with links.
6 Comments
You’ve advised against using ARIA labels in links, but you’ve neglected to suggest what we should do. Do you have an article about it?
I’ve used ARIA labels on all of my website’s SVG icon links (e.g. RSS feed, share links, etc.) thinking that I was doing the right thing. Although I’m only an amateur who therefore only needs to work on one site, I’ve always been very keen on accessibility and best practices generally.
But for this particular usage, what is the best practice?
By the way, I want to say thank you for your generally very informative writing. I’ve followed your articles for a long time. It’s unfortunately still quite hard to find good information about this topic, especially as I’m not part of the web industry.
In response to . For a text link, the standard link I show in the first example. For a link with an image, which is outside the scope of this post, use the
altattribute to provide the link text. If the SVG is inline (versus in an<img>) then explore using the SVG’s<title>element.
In response to . Ah, so the title element is picked up? I’ve seen it in a few ready-made SVG icons but I didn’t know whether it had any real benefit.
Thanks for replying, Adrian.
In response to . I said explore using it. Look at existing articles, like Léonie Watson’s Tips for Creating Accessible SVG from 2014, Heather Migliorisi’s 2016 piece Accessible SVGs, or Carie Fisher’s Accessible SVGs: Perfect Patterns For Screen Reader Users from 2021. My post Cistercian SVG has a video demonstrating an implementation with the ARIA suggested in those articles.
So, read those, understand how it should be exposed, and then test them. Because regressions happen and sometimes novel bugs are found this way.
Hi Adrian, is this applicable to buttons too?
In response to . Great question! You can take the variations above and convert them to buttons and apply the same tests. Then share back here what you find.
Leave a Comment or Response