Do ARIA attributes get translated?
Testing whether common ARIA attributes like aria-label are successfully translated by various webpage translation tools.
If we want our content to be understood by the widest possible audience, we must make our websites not just accessible to disabled people — but also translatable. I have conducted extensive research, and I can confirm that disabled people do, in fact, speak different languages.
Automated translation tools seem to work okay for translating the visible text on webpages, but what about ARIA and HTML attributes that are invisible, and are exposed to assistive technologies like screen readers?
TL;DR
The TL;DR is: yes, attributes do translate, kind of. But there are complex cases, like dynamic attribute values, and toggling display: none CSS values, that may cause issues — see 30 July 2025 update. My tests showed, for pages of a single language, with the basic set of use cases on my test page, attributes translated well. Test your own content to determine if you are happy with the levels of translation support.
Translatable attributes
The WAI-ARIA 1.2 specification tells us which ARIA states and properties should be translated:
aria-labelaria-placeholderaria-roledescriptionaria-valuetext.
On top of these ARIA attributes, there are some accessibility-related HTML attributes that ought to be translated too, such as:
alttitleplaceholder.
The HTML Living Standard specifies an exhaustive list of all translatable HTML attributes — however, I’ve trimmed this down to make the tests more manageable — and to keep the focus on accessibility. This article doesn’t claim to cover all possible permutations — just to give a broad sense of how the key accessibility-related attributes perform.
Just for amusement, I will also be testing 3 ARIA attributes in the WAI-ARIA 1.3 specification, which is still in draft:
aria-descriptionaria-braillelabelaria-brailleroledescription.
The two Braille-related attributes are not listed as translatable in WAI-ARIA 1.3, Therefore, we should expect to see them not translated. I disagree with this aspect of the draft specification. This decision could conceivably leave Braille users with no way to localise their web content — it’s taken out of their control. It should be up to the user to decide whether content is translated or not.
I will be testing whether these attributes successfully translate using a Spanish test page.
I developed the Spanish test page from scratch to contain ideal, isolated test cases. This was done to isolate the variables I wanted to test, and to remove confounding factors (like bad HTML, weird CSS and JavaScript).
Methodology
- I ran tests on 21 July 2025
- I used a translation test page that contains examples of each attribute in Spanish.
- I tested using Safari (macOS and iOS), Firefox (macOS and Windows), and Chromium (macOS, Windows, Android).
Testing results
Firefox
Version: Firefox 140.0.4 (macOS, Windows)
| Attribute | Translated? |
|---|---|
aria-label | ✅ Pass |
aria-placeholder | ✅ Pass |
aria-roledescription | ✅ Pass |
aria-valuetext | ✅ Pass |
aria-description | ✅ Pass |
aria-braillelabel | ✅ Pass |
aria-brailleroledescription | ✅ Pass |
alt | ✅ Pass |
title | ✅ Pass |
placeholder | ✅ Pass |
Chromium
Version: Chromium 138.0.7204 (Windows, macOS, Android)
| Attribute | Translated? |
|---|---|
aria-label | ✅ Pass |
aria-placeholder | ✅ Pass |
aria-roledescription | ✅ Pass |
aria-valuetext | ✅ Pass |
aria-description | ❌ Fail |
aria-braillelabel | ❌ Fail |
aria-brailleroledescription | ❌ Fail |
alt | ✅ Pass |
title | ✅ Pass |
placeholder | ✅ Pass |
Safari
I discovered a WebKit bug during testing, where any usage of the code element causes translation to fail. I’ll file a report 😑
Additionally, I found a truly baffling bug in Safari — the HTML placeholder attribute would translate perfectly for VoiceOver, but visually it’d display the placeholder in German instead of English. Maybe I’ll file a report on this too.
Version: Safari 18.5 (macOS, iOS)
| Attribute | Translated? |
|---|---|
aria-label | ✅ Pass |
aria-placeholder | ✅ Pass |
aria-roledescription | ✅ Pass |
aria-valuetext | ✅ Pass |
aria-description | ❌ Fail |
aria-braillelabel | ❌ Fail |
aria-brailleroledescription | ❌ Fail |
alt | ✅ Pass |
title | ✅ Pass |
placeholder | ⚠️ See note |
⚠️ Note: the placeholder attribute is translated in VoiceOver, but visually rendered as German for unknown reasons.
Google Translate (web service)
| Attribute | Translated? |
|---|---|
aria-label | ✅ Pass |
aria-placeholder | ✅ Pass |
aria-roledescription | ✅ Pass |
aria-valuetext | ✅ Pass |
aria-description | ❌ Fail |
aria-braillelabel | ❌ Fail |
aria-brailleroledescription | ❌ Fail |
alt | ✅ Pass |
title | ✅ Pass |
placeholder | ✅ Pass |
Conclusion
The good news: Generally, there’s great support for translating common ARIA and HTML attributes across major browsers (for the specific tests I performed). In my opinion, they’re generally safe to use on the web for products you expect to be auto-translated. Obviously, always test your own content to make sure. What I’ve proven here, is in my specific test case, the tests generally passed… However, the web is freaky and there’s always odd scenarios where things fail unexpectedly.
The unexpected news: Safari has some very frustrating bugs that prevent the translation of any paragraph that contains a code inline element. I’ve reported this on WebKit Bugzilla.
The future news: Firefox is the only browser that broadly supports translation of the upcoming WAI-ARIA 1.3 attributes, even going outside the spec by translating aria-braillelabel and aria-brailleroledescription.
If you want to test translation capabilities for yourself, you can head to the translation test page.
— Callum
30 July 2025 update
Adrian Roselli recently tested more complicated cases around auto-translation of ARIA attributes, like dynamic aria-label values. It was discovered that some of these cases do indeed fail, highlighting the importance that you test your own content. Not all web pages have dynamic aria-label attributes, for instance. So, the rule remains, the web is freaky and breaks in mysterious ways — test your own content to ensure compatibility. Read the new updated section in aria-label Does Not Translate
I think auto-translation and accessibility needs to be balanced on a case-by-case basis. It doesn’t feel correct to me, to blanket discourage particular accessibility features or technology, because they’re incompatible with certain auto-translation systems in browsers.
I agree it’s the correct goal to have — for our web content to be fully translatable by automated systems, including every nook and cranny of ARIA. But I wonder if this bar is too high in some cases. It reminds me of the days where we’d have to make our websites render correctly in Internet Explorer; at what stage do web developers stop compensating for buggy browsers and allow users to feel the pain of how bad their browser really is? Otherwise, pressure isn’t put on browser vendors to improve — they can coast on the goodwill of developers bending over backwards to write compatible web content.
Ideally, if your products must be used in multiple languages, you should provide official translations of your product, rather than relying on automatically-translated content. While AI is getting really good at translation, it still leaves the door open to potentially damaging translation errors. Admittedly, some organisations may lack the resources to achieve this, especially if many languages must be supported. Another risk, is there are simply blatant general bugs in auto-translation systems built into browsers that impact everyone — sometimes browsers refuse to offer translation, or fail to translate certain content.
As a hypothetical, what if alt attributes stopped translating properly in all Chromium-based browsers due to a bug? Does this mean we should discourage alt attributes on that basis? I’d argue no. We should continue using alt and blame the browser vendors for their failure (or, more constructively, file a bug report).
As a non-hypothetical, inline code elements break auto-translation in WebKit. I reported this via WebKit Bugzilla: Paragraphs with <code> elements fail to translate. Do we halt our usage of the code element due to this bug? I’d say, no. As much as I would love to support full auto-translation in WebKit, we have to draw a line somewhere, and blame the browser. However, I do feel web developers have a duty to check a bug is correctly raised with the browser vendor.
It’s a difficult balance for web developers to make. Do we degrade our usage of valid web standards due to bugs that exist in some browsers? Or, do we write theoretically conformant code, with the expectation that browser vendors are the ones to blame if issues occur? My opinion changes on this frequently. I think this is a decision best left to the author, who will know their audience best, and the risks of translation failure.
It is generally best to rely on plain HTML before using ARIA. And it’s best to reach for attributes like aria-labelledby rather than aria-label where possible — as this may avoid duplication of content and maintenance, and it may also avoid some of these translation bugs. aria-labelledby attributes aren’t without risks, though — you have to be careful to ensure the aria-labelledby value points to a valid ID of an element on the page — something I have seen broken many times.