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.
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.
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="תפריט ראשי סגור" …>
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.
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 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.
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:
Native HTML techniques,
aria-labelledby pointing at existing visible text,
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 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 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:
@aardrian Norway is not yet a language supported by Safari’s autotranslation. German is, and aria-labels are properly translated.
Supported languages as of this writing (note that two of them are English and none are Norwegian):
English (United Kingdom)
English (United States)
Mandarin Chinese (China mainland)
Mandarin Chinese (Taiwan)
French (France)
German (Germany)
Italian (Italy)
Japanese
Korean
Spanish (Spain)
Portuguese (Brazil)
Arabic
Russian
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:
Chrome sometimes auto-translates aria-label.
Safari on macOS translates aria-label if it is one of 13 languages.
Edge persists in its regression and does not translate aria-label.
Firefox still does 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.
The core thesis of this post still stands — you cannot rely on aria-label being auto-translated.
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.
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?
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.
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.
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