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.

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.

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.

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

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.

Update: December 12, 2019

Just as aria-labeledby 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); }

5 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.

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>

This site uses Akismet to reduce spam. Learn how your comment data is processed.