Multilingual Websites and Accessibility: The Language Switcher Mistakes That Lock People Out

If you sell across borders, you probably have a little globe icon or a “EN / FR / DE” menu somewhere in your header. It feels like a finished feature. You picked the languages, someone translated the pages, and the switcher works when you click it. Done.

Except there is a whole layer of this that you cannot see by looking at the screen. Screen readers — the software blind and low-vision people use to hear a web page read aloud — depend on hidden signals in your page to know which language they are reading. When those signals are missing or wrong, a French page gets read out in an American accent that mangles every word, a language menu becomes a row of mystery links, and a user who switches languages has no idea whether anything happened. None of this shows up in a screenshot, so it is one of the most common accessibility gaps on otherwise polished multilingual sites.

This matters more than it used to. The European Accessibility Act started applying in June 2025, and by definition the businesses it affects most are the ones selling into multiple EU countries — which usually means multiple languages. If you have built a multilingual site specifically to reach those customers, the multilingual parts are exactly where you are most exposed. The good news: almost every fix here is something you can check and request without writing a line of code. Let’s walk through it.

Why language matters to a screen reader (and not to your eyes)

When you read a page, you instantly know what language it is in. You see the words and your brain switches. A screen reader cannot do that. It has a set of pronunciation rules for each language, and it needs to be told which set to use. That instruction lives in the page’s code as a “language attribute” — a small tag that says, in effect, “read this in German” or “this sentence is in French.”

Get it right, and a German page is read with correct German pronunciation, pacing, and emphasis. Get it wrong — or leave it blank — and the screen reader falls back to its default language and tries to pronounce German words using English rules. The result is not a minor accent. It is often genuinely incomprehensible, the way a text-to-speech voice sounds if you feed it a language it does not know. For a blind user, that can make a page unusable even though the translation itself is perfect.

There are two places this comes up. The first is the overall page language — the single setting that says “this whole page is in Spanish.” The second is inline language changes — when a mostly-English page contains a phrase, a quote, a product name, or a menu item in another language. Both have their own WCAG requirements, and both are routinely missed.

Mistake 1: The page never declares its language

This is the foundational one. Every page should declare its primary language in its code. In WCAG terms this is success criterion 3.1.1 Language of Page, and it is a Level A requirement — the most basic tier. Despite that, automated scans find missing or empty language declarations on a huge share of sites, and it is even more common on translated pages, because the translated version is often copied from the original and the language setting is left pointing at the wrong language.

Here is the trap that catches multilingual sites specifically: you set up your English site correctly, then add French and German versions, and every one of those pages still announces itself as English. To a screen reader, your beautifully translated French page is “an English page that happens to contain French-looking words,” and it reads accordingly.

How to check it without code: Most accessibility scanners will flag a missing or incorrect page language. Run a free tool like WAVE or Lighthouse on each language version of a sample page — not just the English one. If the French page does not declare French, you have found the problem. Then ask whoever manages your site (your platform’s settings, your developer, or your translation plugin) to make sure each language version sets its own correct language. On most website builders and translation plugins this is a setting, not custom work; it is just one that frequently gets skipped.

Mistake 2: Foreign phrases inside a page aren’t marked

Even a site that is “all in English” usually is not, quite. You have a French restaurant’s name, a German product line, a Latin motto, a customer testimonial in Italian, a tagline you left in the original language because it sounds better. WCAG 3.1.2 Language of Parts (also a requirement at Level AA) says these inline switches should be marked so the screen reader pronounces them correctly too.

This one is genuinely hard to do perfectly and easy to overdo, so keep it proportionate. You do not need to tag every borrowed word that has entered everyday English (“café,” “rendezvous,” “et cetera”) — those are treated as part of the surrounding language. What matters is meaningful chunks of real foreign-language content: a quoted sentence, a paragraph, a heading, a block of text in another language. Those should carry their own language marking so they are read properly.

How to handle it without code: You usually cannot fix this through a settings toggle, but you can flag it clearly. When you hand content to whoever builds your pages, point out the sections that are in a different language from the rest of the page and ask that they be marked accordingly. It is a small instruction that costs nothing if you say it up front and is annoying to retrofit later. If you use a CMS where you write the content yourself, ask your developer to show you the one button or field that sets the language on a selected block — it is typically a 30-second action once you know where it is.

Now the part you can actually see — and still probably get wrong. Look at your language menu. Does it say “EN,” “FR,” “DE”? Or just show flags? Both are problems for different reasons.

The first issue is labels. A blind user navigating your switcher hears whatever text is there. “EN” read aloud is “ee en,” which is not obviously “English.” Worse, a switcher built only from flag images with no text gives a screen reader nothing meaningful to announce at all — the user hears “link, link, link” or a filename. The fix is to make sure each option has clear text, and — this is the elegant part — the name of each language should be written in that language. The link to the German site should say “Deutsch,” not “German.” The link to the French site should say “Français.” That way a German speaker recognizes their own option no matter what language the current page is in, and the screen reader, if the markup is right, can even read each option in its own language.

The second issue is flags. Flags represent countries, not languages, and the mismatch causes real exclusion and occasional offense: Spanish is spoken across dozens of countries, not just Spain; using a single flag to mean “Spanish” erases all of them. For accessibility specifically, a flag alone is a visual symbol with no text, so it fails the same way an unlabeled image does. Use language names as text; if you want a flag as decoration alongside the text, fine, but the text is what carries the meaning.

The third issue is whether the switcher is operable and findable. It needs to be reachable and usable with a keyboard alone — you can test this yourself in two minutes, covered below — and it should be in a predictable place, usually the header, so users do not have to hunt for it.

Mistake 4: Switching languages happens silently

Say a user does find and activate your switcher. What happens next is its own accessibility question. On many sites, changing language reloads the whole page in the new language, which is fine — the new page declares its language and the screen reader adapts. But some modern sites swap the content in place without a full reload, and that is where things go quiet. If the text changes but nothing announces the change, a screen reader user may not realize anything happened, or may be left in a strange state where the announced language and the visible language disagree.

There is also a subtler courtesy issue: after switching, where does the user land? Ideally on the same page they were on, in the new language — not dumped back on the homepage. Being thrown to the homepage is mildly annoying for a sighted user and genuinely disorienting for someone rebuilding their mental map of the page by ear. You can experience both problems yourself: switch languages on your own site and notice whether you stay on the equivalent page, and whether the change is obvious.

A five-minute self-test you can run today

You do not need to understand the code to catch most of these. Try this on your own multilingual site:

  1. Run a scanner on each language version. Open a sample page in your non-English language and run WAVE or Chrome’s built-in Lighthouse accessibility audit. Look specifically for any flag about the document language or missing language attributes. Repeat for each language. This catches Mistake 1.

  2. Read your language switcher out loud, as text. Does each option say the language’s name in its own language (“Deutsch,” “Français,” “Italiano”), or is it cryptic codes and flags? If it is flags or “DE/FR/IT” codes only, that is Mistake 3.

  3. Put your mouse away and use Tab. Press the Tab key repeatedly from the top of the page. Can you reach the language switcher? When it is highlighted, can you see clearly that it is highlighted? Can you open it and choose a language using only the keyboard and Enter? If not, the switcher is not operable for keyboard and screen reader users.

  4. Switch languages and watch where you land. Do you end up on the same content in the new language, or back on the homepage? Did anything tell you the switch happened?

  5. Turn on a screen reader for one page. On a Mac, VoiceOver is built in (Command + F5). Listen to one translated page for thirty seconds. If a French page is being read in a flat, wrong-sounding English voice that garbles the words, your page language is not set correctly — a live demonstration of Mistake 1 that no visual check would ever reveal.

None of these require a developer to run. They do sometimes require a developer to fix, but walking in with “the German page is being read in English and our switcher is flag-only” is a precise, cheap request, not a vague “make us accessible.”

Why this is worth your attention now

It is tempting to treat the language layer as a nice-to-have on top of “real” accessibility. It is not. For the businesses most affected by the EAA — the ones deliberately serving customers across multiple EU countries — the multilingual experience is a core part of the service, and it is the part competitors most often neglect. A blind customer in France who cannot use your French site does not file a bug report; they buy from someone whose site works. Getting this right is both a compliance question and a straightforward way to stop quietly losing customers you spent money to reach.

The themes here echo through the rest of your site, too. Clear text labels instead of cryptic icons, keyboard operability, and telling users when something changes are the same principles behind accessible navigation and menus everywhere. The language switcher is just where multilingual businesses most often forget to apply them.

We’re building a simple accessibility checker for non-developers — no DevTools, no jargon. Join our waitlist to get early access.