Accessible Language Switcher: WCAG Requirements

An accessible language switcher is operable by keyboard, has a clear accessible name, identifies the page language with lang on the <html> element (WCAG 3.1.1), marks each language label with its own lang (3.1.2), and does not change the page unexpectedly when a control receives focus or changes value. Plain links in a labelled <nav> meet most of these needs with little code.

Which WCAG criteria apply to a language switcher?

The wording below is taken from the W3C "Understanding WCAG 2.2" pages. Levels are A or AA; conformance to AA is the common target in laws and procurement, though which standard applies to you depends on your jurisdiction.

Target size is part of WCAG 2.2, so it will not appear in checklists built only on 2.1.

How do you set the page language correctly?

Put the language of the page on the root element, not on <body>. W3C's guidance is to always use a lang attribute on the html tag; descendants inherit it. Use valid BCP 47 tags (see language and region codes):

<!doctype html>
<html lang="de" dir="ltr">

Rules of thumb:

• One lang per page version, matching the language of the main content, and the same language you declare in hreflang annotations.
• For right-to-left languages also set dir="rtl". lang alone does not set direction; the RTL guide covers this.
• Do not rely on <meta http-equiv="Content-Language">; W3C advises against it, and the in-page declaration takes precedence over HTTP-supplied language information.
• Update lang when the translated page is generated. A German page that still says lang="en" makes screen readers use the wrong pronunciation rules, which is a real failure of 3.1.1.

A note on SEO: Google states it does not use hreflang or the HTML lang attribute to detect the language of a page. lang is still necessary for accessibility, so do it for users, not for rankings.

How do you mark up the language labels?

In an English page, the label "Deutsch" is a passage in German. WCAG 3.1.2 asks for it to be programmatically identifiable, so use lang on the element holding the label. W3C's own example is <span lang="es">Español</span>.

<nav aria-label="Language">
  <ul>
    <li><a href="/en/" lang="en" hreflang="en" aria-current="true">English</a></li>
    <li><a href="/de/" lang="de" hreflang="de">Deutsch</a></li>
    <li><a href="/es/" lang="es" hreflang="es">Español</a></li>
  </ul>
</nav>

Two details:

• Put lang on the link itself or on a <span> inside it. If you add a title or visually hidden text written in the current page's language, keep it on the <a>, not inside an element carrying the target lang, so it is not read in the wrong voice (this follows W3C's guidance on language links).
• The hreflang attribute on an <a> element is part of HTML and describes the linked resource's language. Treat it as informational metadata: it is not the same as the hreflang annotations in <head> that search engines use, and it does not make a link accessible by itself. We could not find a WCAG requirement for it, so the value is mostly consistency.

Links or a select element?

On <select>: the WCAG 3.2.2 Understanding page says changing the selected option counts as changing the setting of a component, so it should not automatically cause a change of context such as navigating to a new page unless users are advised beforehand. Sufficient techniques include a separate button to perform the action (H84). A language switch navigates to a new page, so a select that does this on change is a classic 3.2.2 problem.

For a custom dropdown, the WAI-ARIA Authoring Practices "disclosure" pattern is a good basis: a <button> with aria-expanded true or false toggles a list of links, and both Enter and Space activate the button. aria-controls is optional. Avoid inventing role="menu" or listbox for what is really a short list of links; those roles bring extra keyboard expectations you then have to implement.

What should keyboard and screen-reader behaviour be?

• Tab order follows visual order, and the switcher is reachable in a reasonable number of tab stops. Consider whether a "skip to content" link helps users get past it.
• Name: give the <nav> a label such as aria-label="Language", written in the page language. The visible button text should be contained in its accessible name (2.5.3), so do not set an aria-label that omits the visible word.
• State: expose the current language with aria-current="true" and, for collapsible lists, aria-expanded.
• Focus: visible focus indicator with sufficient contrast; when a disclosure closes with Escape, return focus to its button (common practice; not a stated WCAG requirement).
• Announcements: after navigation the screen reader announces the new page title, so translate <title> as well.

What else should you test?

Test with a keyboard only, then with at least one screen reader on each major platform you support. Check that the new page loads with the right lang, that the label pronounces correctly, and that the 24 by 24 pixel target-size rule is met or that a listed exception applies. Our UX best-practices article covers placement and labelling, which also affect accessibility.

Key takeaways

• Set a correct lang on <html> for every language version (WCAG 3.1.1, Level A), and add dir for right-to-left languages.
• Mark each language label with its own lang (3.1.2, Level AA); proper names and words absorbed into the surrounding language are exceptions.
• Prefer a <nav> with real links; if you use a <select>, add a button so a change does not navigate unexpectedly (3.2.2).
• Ensure keyboard operation, visible focus, matching visible and accessible names, and adequate target size.
• lang is for accessibility, not a Google ranking signal: Google says it does not use it to detect page language.

Sources

• W3C: Understanding SC 3.1.1 Language of Page – wording and level of 3.1.1
• W3C: Understanding SC 3.1.2 Language of Parts – wording, level and exceptions of 3.1.2
• W3C: Understanding SC 3.2.2 On Input – select elements and changes of context
• W3C: Understanding SC 2.5.8 Target Size (Minimum) – 24 by 24 CSS pixel rule
• W3C Internationalization: Declaring language in HTML – lang on html, language links, Content-Language
• Google Search Central: Localized versions of your pages – Google does not use hreflang or lang to detect language