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

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)

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.

Firefox, Safari, etc.

Nope.

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.

Bing Translator

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.

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: December 12, 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: November 19, 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.