Designing a language switcher people can find

Who the switcher is for

The person who needs a language switcher most is someone who cannot read the page in front of them. That sounds obvious, but it changes several design decisions. The control has to be recognisable without reading the surrounding text, its options have to be readable by someone who does not know the current language, and it has to be where people look for it without hunting.

A second group is people who can read the current language but prefer another, such as a French-speaking resident of Biel who landed on the German version from a search. They will use the switcher if it is easy and quietly carry on in German if it is not.

Placement

Put the switcher in the header, in the same position on every page, and keep it visible on small screens rather than burying it at the bottom of a collapsed menu. WCAG 2.2 success criterion 3.2.3 asks that navigation repeated across pages keeps the same relative order ¹; a switcher that moves between templates fails readers who learned where it was. In a left-to-right layout the top right corner of the header is one sensible spot, but consistency across your own site matters more than matching anyone else's.

A footer switcher can supplement the header one, but it should not be the only route: a reader who cannot understand the page will not scroll to the end to find out whether help exists.

Name each language in itself

Label each option with the language's own name for itself, its endonym: Deutsch, Français, Italiano, Rumantsch, English, Español, العربية. A German speaker scanning a French page looks for "Deutsch", not "Allemand". The open reference specification for language switchers states the rule directly, citing W3C guidance: label each option in its own language ².

Two refinements help:

• Do not abbreviate to codes alone. "DE / FR / IT" is compact, but codes are not words and some are ambiguous to readers. If space forces abbreviations, give the full endonym as the accessible name.
• Do not translate the list into the current language. On the Italian page, German is still "Deutsch".

Why flags mislead

Flags represent countries, and languages do not map onto countries. The W3C's guidance on language menus recommends naming each option in its own language and marking the control with a recognisable image such as a globe ³; the open language switcher specification says plainly not to use flags ². Switzerland makes the point well: a Swiss flag cannot tell a reader whether the page will be in German, French, Italian or Romansh. French is spoken in France, Belgium, Canada and Switzerland; English across several continents. Choosing one flag for a language quietly tells readers in every other country that the version is not for them. The switcher specification puts it in five words: flags are countries, not languages ².

Flags have a place when the choice really is about a country, such as a shop that charges different prices and delivery terms in Switzerland and in Germany. Then the choice is a country choice, and it should be presented as one, separate from language.

Keep the reader on the same page

When someone switches from the German product page to French, they should land on the French product page, not the French home page. The Government of Canada's design system, which runs a bilingual site at national scale, frames the purpose of its language toggle as letting people switch languages without losing track of where they were ⁴.

This requires the site to know which pages are translations of each other, which is the same information hreflang needs. When a page has no counterpart in the chosen language, say so and offer the nearest useful page, such as the section index, rather than failing silently or sending the reader to a 404.

Markup that works for everyone

Screen readers pick their voice and pronunciation from the lang attribute. If "Français" sits in a German page with no language marked, a German voice will read it with German pronunciation. Mark each option with its own language, and add hreflang to the link to say what language the target page is in ²:

<nav aria-label="Sprache / Langue / Lingua">
  <ul>
    <li><a href="/de/kontakt/" lang="de" hreflang="de" aria-current="true">Deutsch</a></li>
    <li><a href="/fr/contact/" lang="fr" hreflang="fr">Français</a></li>
    <li><a href="/it/contatto/" lang="it" hreflang="it">Italiano</a></li>
  </ul>
</nav>

Marking a passage in a different language like this is what WCAG 2.2 success criterion 3.1.2, Language of Parts, asks for at Level AA ⁵. The navigation label written in several languages is one way to make the landmark understandable whichever version the reader is on.

Links or a dropdown

For two to four languages, plain visible links are clearer than a dropdown: every option is visible at once and needs one click. With more languages, a disclosure button that opens a list is reasonable, provided the button itself is recognisable. A label such as "Language" in the current language alone fails the reader who cannot read it, so pair it with an icon that suggests language (a speech bubble or a stylised "文A" glyph rather than a flag) and with the current language's endonym.

A native select element that changes page on selection is the option to avoid: keyboard users moving through the options with the arrow keys can trigger navigation they did not intend.

Testing it

1. Open a deep page, not the home page, and switch to each language in turn. Each time you should land on the matching page.
2. Repeat with the keyboard alone. Every option should be reachable with Tab and show a visible focus ring.
3. Turn on a screen reader and listen to the options. Each endonym should be read in its own language.
4. Check a narrow phone screen. The switcher should still be reachable within one or two taps from the top of the page.

The language demo shows how the same short labels change length and direction across six languages, which is useful when sizing the control.