aria-label Does Not Translate

It does, actually. Sometimes.

One of the big risks of using ARIA to define text content is that it often gets overlooked in translation. Automated translation services often do not capture it. Those who pay for localization services all too often miss content in ARIA attributes when sending text strings to localization vendors.

That means content buried in aria-label, aria-placeholder, aria-roledescription, or aria-valuetext can end up being read to users in a language different than their own. The very thing we are adding to help screen reader users can be excluding them instead.

That makes constructs like the following particularly dangerous (from my post Uncanny A11y):

<a href="http://example.com/" target="_blank" aria-label="Opens in a new window">Visit their site</a>
<button aria-label="Cancel">Close</button>
<span class="status-meta">Only those with <a href="https://help.github.com/articles/what-are-the-different-access-permissions" class="tooltipped tooltipped-s" aria-label="Learn more about permission levels">write access</a> to this repository can merge pull requests.</span>

Browsers

Browsers may or may not help users.

Chrome

Updated 4 March 2023: Chrome may have regressed or my prior tests were not detailed enough. Either way, below I demonstrate Chrome failing to auto-translate aria-label.

No Longer True

November 2019: In May plenty of users who live in the overlap of accessibility and internationalization were thrilled to hear Google Chrome would translate aria-label. The promise of ARIA 1.2 for translatable ARIA attributes had arrived early. Messaging from Chrome, however, was unclear and many took it to mean Google Translate itself was updated.

Chrome calls out to the Google Translate API on a page and, per Issue 933519: Translate aria-label attributes, translates the four ARIA attributes I listed above. This is great for Chrome users. Not so great for Firefox, (legacy) Edge, Internet Explorer, Safari, Vivaldi, Brave, Opera, etc. users.

Edge (Chromiedge)

Updated 4 March 2023: Chrome may have regressed or my prior tests were not detailed enough. Either way, below I demonstrate Chrome failing to auto-translate aria-label.

No Longer True

November 2019: There is some good and unexpected news for Edge (Chromiedge) users. While I have not seen this promoted anywhere, Edge will translate at least aria-label. Note that if you are still using legacy Edge you will not get this benefit. More reason to upgrade.

Screen shots comparing a pre- and post-translated page in Edge.
A Norwegian government page with Norwegian-language text in the aria-label. When the page has been translated to English in the browser (Edge Dev 80.0.320.4), the aria-label is also translated to English.

Seemingly Still Accurate

4 August 2022: Testing again with Edge shows what may be a regression. I visited https://www.gov.il/he/ and let Edge auto-translate the page to English. I visually confirmed all the text changed to English. Then I popped open the dev tools and searched for all instances of aria-label (using XPath of //*[@aria-label]).

Both aria-label instances were still in Hebrew. I confirmed that the other content in the dev tools reflected the English translation, but the ARIA text persisted in its Hebrewness: <input … aria-label="חיפוש באתר gov.il" …> and <a … aria-label="תפריט ראשי סגור" …>

Firefox, Safari, etc.

Not yet.

Safari

See the 6 March 2023 update.

Firefox

See the 28 January 2024 update.

Auto-Translators

If you are a user of any other browser, you can always hop over to an online translation service.

Google Translate

Assuming you can find how to submit a URL for a full-page translation, you will find that Google Translate will not translate those ARIA attributes. As an example, I took one of my posts about emoji, which leans on aria-label and turns those values into visible tool-tips. The version of that page from Google Translate does not translate them.

Two examples from Google Translate.
Google Translate will happily grab the rest of the content on the page, but falls down when it gets to aria-label. In these screen shots I am translating the page to Spanish but the aria-label remains in English.

Bing Translator

Updated 4 March 2023: Bing Translate no longer seems to translate web pages.

No Longer True

Bing Translator is hit-and-miss, catching some but not all. Which means it performed better than Google Translate. If you visit the translated version of the same page from above, you will see some aria-labels translate and some do not.

Two examples from Bing Translator.
Bing Translator fared about fifty-fifty when it encountered aria-label. In these screen shots I am translating the page to Spanish and showing one aria-label gets translated to Spanish, another does not.

For Developers

With the spotty accuracy of automated translation for ARIA attributes, avoid forcing your users to rely on machine translation services. If you already have a process (and budget) to translate (localize) text strings with humans, then you will need to ensure you capture all the strings that may not be visible on the page.

A more sustainable approach (which applies if you have no localization budget) might come earlier in the process — avoid using aria-label. The other three translatable ARIA attributes seem to have little traction so far so I am deferring on those.

Instead, lean on traditional ways of assigning an accessible name, such as visible text in a control (such as a <button>) or its related <label>. This has the benefit of immediately supporting WCAG 2.1 Success Crition 2.5.3 Label in Name (A).

If your control does not have visible text (buttons with icons, for example), look for existing text on the page that you can reference via aria-labelledby. I give an example in my post Uniquely Labeling Fields in a Table.

If you can count on CSS working and still need to hide text (or cannot find the text you want already in the larger control), then you can use a hidden text technique. The caution here is that it may still be missed by people who pull text strings from a page for translation.

/* Proven method to visually hide something but */
/* still make it available to assistive technology */
.visually-hidden {
  position: absolute;
  top: auto;
  overflow: hidden;
  clip: rect(1px 1px 1px 1px); /* IE 6/7 */
  clip: rect(1px, 1px, 1px, 1px);
  width: 1px;
  height: 1px;
  white-space: nowrap;
}

This CSS may look familiar to you. I use it often in my posts. These styles are sometimes classed as .sr-only, but I avoid that name since it is implies a function it does not have (targeting screen readers).

Recap

Even with support in Chrome and (new) Edge for translating ARIA attributes, it is a risky approach to rely on machines to translate content.

To help users, avoid using ARIA to hold content. In particular, instead of aria-label, lean on:

  1. Native HTML techniques,
  2. aria-labelledby pointing at existing visible text,
  3. Visibly-hidden content that is still in the page.

For more detail on each of these, see my January 2020 post My Priority of Methods for Labeling a Control.

Update: 12 December 2019

Just as aria-labelledby has aria-describedby as its cousin, aria-label is getting aria-description (issue, pull request).

The caveats to using aria-label that I outline above will easily apply to aria-description until it gets traction in browsers and assistive technologies and translation services. So be very careful relying on it.

Separately, please do not do this (at least not without testing it in the screen readers and browsers your audience actually uses): [aria-description]::after { content: attr(aria-description); }

Update: 19 November 2020

In quick test with Safari 14 on macOS 11 (what the kids call Big Sur) using its built-in translation feature, for the few languages it supports and on sites it correctly recognizes as being in a foreign language, Safari translates aria-label.

Too many caveats.

Update: 4 August 2022

Edge may have regressed. See the Edge Update above.

I also confirmed that Safari (though TP 149) offers no auto-translation for the sample page in that update.

All this means is that the title of this post is still accurate.

Update: 4 March 2023

Support for auto-translating aria-label values is apparently worse than when I wrote this post in late 2019 and may have regressed since improvements I recorded after that date. You should of course test your own work.

I visited the Norwegian government home page and looked for instances of aria-label that are exposed to users. I started off by searching for any node not hidden (//*[not(@aria-hidden)]//*[@aria-label][not(@aria-hidden)]) and found a download button in a video player:

<div
 class="gobrain-controller
  gobrain-fn-download-video
  gobrain-hoverable
  gobrain-focusable
  gobrain-translate-aria-label"
 tabindex="0"
 data-internal-gobrain-translation-key="downloadButton"
 aria-label="Last ned video, åpner et nytt vindu"
 role="button">

Using a Chrome 110 Incognito window and InPrivate window for Edge 110, both for Windows, I confirmed neither browser auto-translates the text. I confirmed it with a screen reader and by comparing with other nodes that were auto-translated to make sure the DOM and speech buffer had been updated.

Clearly I did not do an exhaustive test of every possible variation. I did, however, identify a common pattern in the wild that does not auto-translate.

Chrome dev tools confirming the button has an accessible name from its aria-label. Chrome dev tools confirming the page has been translated but the button aria-label has not changed, nor has its accessible name. The Chrome auto-translate option showing English as an option. Dev tools showing other nodes in the DOM have been auto-translated.
Chrome 110 dev tools confirms the button is in Norwegian both before and after the rest of the content has auto-translated. Included in the screen shots is the browser prompt to translate the page and a confirmation other nodes were auto-translated.
Edge dev tools confirming the button has an accessible name from its aria-label. Edge dev tools confirming the page has been translated but the button aria-label has not changed, nor has its accessible name. The Edge auto-translate option showing English as an option. Dev tools showing other nodes in the DOM have been auto-translated.
Edge 110 dev tools confirms the button is in Norwegian both before and after the rest of the content has auto-translated. Included in the screen shots is the browser prompt to translate the page and a confirmation other nodes were auto-translated.

Firefox 110 and Safari 16.3 still do not offer an option to auto-translate.

Bing Translator seems to no longer accept URLs for translation.

Google Translate still misses the same examples as before.

Update: 6 March 2023

Eric Eggert noted my example hits a language not supported by Apple’s translation service:

Supported languages as of this writing (note that two of them are English and none are Norwegian):

When I re-tested using the German page Eric provided using Chrome, I found that most instances of aria-label translated. For example, //*[@aria-label="Menü öffnen"] was translated while //*[@aria-label="Nach oben"] (the hidden one) was not. My guess is the browser makes some decisions based on element visibility.

Edge ignored the aria-labels.

To recap:

The core thesis of this post still stands — you cannot rely on aria-label being auto-translated.

Update: 28 January 2024

Firefox 118 added auto-translation support, but it got some updates in Firefox 122. I visited gov.il/he (Hebrew, but with lang="en"), regjeringen.no/no/id4/ (Norwegian, but with lang="nb" for Bokmål), and bundesregierung.de/breg-de (German, with lang="de"). Firefox only offered to auto-translate the German page.

Only German was listed in my Firefox settings as an option for offline automated translation, but I had not installed it and I was not offline. I am making no assertions about how the language codes of the pages may or may not have factored into Firefox’s auto-translation prompts.

Inspecting the German page for non-hidden ARIA labels, I found none had been translated. For example, //*[@aria-label="Menü öffnen"] was not translated.

There is a bug filed to translate ARIA attributes, 1871419 [meta] Translate Relevant Attributes in Full Page Translations, shared with me on Masto.

The core thesis of this post still stands — you cannot rely on aria-label being auto-translated.

6 Comments

Reply

I’ve tried to get my head round this but it’s just hard. I have read different examples and they all give different code, so I don’t know who’s right!

The use case is this:

I want a Font Awesome icon font Twitter icon to be linked to my Twitter profile. The meaning of the icon should be “Visit my Twitter profile”. There won’t be any visible text on the page saying this.

If I start with this basic code, what do you think would be the most accessible syntax to use?

<a href="https://twitter.com/abrightclearweb">
 <span class="fa fa-twitter"></span>
</a>
In response to Claire Brotherton. Reply

Try this:

<a href="https://twitter.com/abrightclearweb">
 <span class="fa fa-twitter"></span>
 <span class="visually-hidden">Visit my Twitter profile.</span>
</a>

Use the visually-hidden class from my post above.

That text will translate. If the CSS completely fails to load, then those users will not see the icon at all but will see the text, so double win.

It is similar to what FontAwesome suggests as the ideal approach for non-interactive content, but also leaves out the unnecessary title attribute. So you are right to ignore the FontAwesome advice overall.

In response to Adrian Roselli. Reply

Thanks for that, and for such an informative post! It adds something to a post I’m working on.

Reply

I wrote an article related to this that folks might find interesting: levelaccess.com/accessibility-considerations-localization/

In response to Jonathan Avila. Reply

Jonathan, while I appreciate the self-promotion, you missed an opportunity tell readers why they might find it interesting. The bookmarklets, for example (I have my own), is one. The list of types of content that is often overlooked in translation is another.

Reply

I was here to refresh my memory on which browsers offer translations now, and tested a few while I was at it.

I’m not getting aria-labels translated in Edge version 94.0.992.50, but I am getting them in Google’s URL translation now. (Still boggling over putting a URL into a textarea for copy-pasted phrases to get a link to a translated version of a site). I used gov.pl because I knew it had an aria-label on it, but haven’t checked any of the other ARIA attributes which take strings of text.

Leave a Comment or Response

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>