WCAG & BFSG · WCAG-Referenz: Verständlich
WCAG 3.1.1: Sprache der Seite
WCAG 3.1.1 verlangt, dass die Standardsprache jeder Seite programmatisch bestimmbar ist – im Web heißt das: ein gültiges lang-Attribut am <html>-Element. Von dieser einen Angabe hängen Aussprache der Sprachausgabe, Braille-Kurzschrift, Silbentrennung und das Übersetzungsangebot des Browsers ab.
(Englisch: Language of Page.)
| Stufe | Prinzip | Teil der WCAG seit | Rechtlich verbindlich? |
|---|---|---|---|
| A | Verständlich | 2.0 (2008) | Ja – über EN 301 549 in BFSG & BITV |
Das Wichtigste in Kürze
- Eine unscheinbare Angabe mit großer Wirkung:
<html lang="de">entscheidet über die Aussprache jeder Ansage. - Die Angabe muss gültig sein. Erlaubt sind Sprachkennungen nach BCP 47 –
de,de-AT,de-CH. Nicht erlaubt:deutsch,de_DEmit Unterstrich, ein leereslang="". -
dereicht meistens. Ein Regionalzusatz ist nur sinnvoll, wenn er wirklich etwas ändert; Screenreader-Stimmen fürde-DEundde-ATunterscheiden sich in der Praxis kaum. -
Der häufigste Fehler ist geerbtes
lang="en"aus einer Vorlage – einmal im Starterprojekt falsch, danach auf jeder Unterseite falsch. - Nicht nur Sprachausgabe hängt daran: Braille-Kurzschrift,
hyphens: auto, typografische Anführungszeichen und Rechtschreibprüfung nutzen dieselbe Angabe. -
Eine englischsprachige Unterseite braucht
lang="en"– die Angabe gilt pro Seite, nicht pro Website. - Stufe A, automatisch prüfbar. axe meldet fehlende und ungültige Werte über die Regeln
html-has-langundhtml-lang-valid; im BIK-BITV-Test heißt der Prüfschritt „3.1.1 Hauptsprache angegeben“.
Wofür ist das lang-Attribut?
Die Anforderung selbst ist in einem Satz erzählt: Die vorgegebene menschliche Sprache jeder Webseite muss programmatisch bestimmt werden können. Interessant ist, was alles an dieser Angabe hängt.
Screenreader wählen darüber ihre Aussprache-Engine. Fehlt das Attribut oder steht dort en, liest eine englische Stimme deutschen Text – und zwar nach englischen Ausspracheregeln. Aus „Sie können sich hier anmelden“ wird dann etwas in Richtung „Sigh kernen sick hear anmelden“. Einzelne Wörter errät man noch, eine ganze Seite nicht mehr. Wer das einmal gehört hat, macht diesen Fehler nie wieder.
Braillezeilen übersetzen sprachabhängig. Die deutsche Kurzschrift kürzt Silben nach eigenen Regeln; mit englischer Sprachkennung kommt Buchstabensalat auf der Zeile an.
Der Browser hängt weitere Funktionen daran: die Silbentrennung über hyphens: auto – ohne korrekte Sprachangabe passiert schlicht nichts –, die typografischen Anführungszeichen des <q>-Elements, die Auswahl passender Schriftschnitte und das Angebot „Diese Seite übersetzen“. Auch der CSS-Selektor :lang() funktioniert erst mit gesetzter Sprache.
Gültige Werte richten sich nach BCP 47. Für den Alltag heißt das: der zweibuchstabige Sprachcode, optional mit Regions- oder Schriftzusatz. Zwei Sonderfälle, die in deutschen Projekten immer wieder auftauchen: Eine Seite in Leichter Sprache bleibt lang="de" – Leichte Sprache ist eine Varietät des Deutschen, keine eigene Sprache. Und ein Gebärdensprachvideo bekommt keine HTML-Sprachumschaltung; die Deutsche Gebärdensprache hat zwar die Kennung gsg, das Video selbst ist aber Nicht-Text-Inhalt und wird über 1.1.1 beschrieben.
Der Normtext steht im Understanding-Dokument des W3C zu 3.1.1, das deutsche Prüfvorgehen im Prüfschritt „3.1.1 Hauptsprache angegeben“ des BIK-BITV-Tests.
lang="en" liest die englische Stimme deutschen Text – Silbentrennung und Braille-Kurzschrift fallen gleich mit aus.Wen betrifft es besonders?
Screenreader-Nutzerinnen und -Nutzer trifft es am härtesten und sofort. Für sie ist eine Seite mit falscher Sprachkennung nicht „etwas unschön“, sondern über weite Strecken unverständlich. Besonders bitter ist der Fall, in dem die Sprachausgabe englisch startet und die Nutzerin annimmt, die Seite sei tatsächlich auf Englisch – sie sucht dann nach einem Sprachumschalter, den es gar nicht braucht.
Braille-Leser bekommen bei falscher Kennung eine falsche Kürzungslogik. Wer die deutsche Kurzschrift gewohnt ist, liest dann plötzlich Vollschrift oder englische Kürzel.
Menschen mit Leseeinschränkungen nutzen häufig Vorlesefunktionen des Browsers oder Erweiterungen wie Immersive Reader. Auch die richten sich nach lang. Und alle, die eine Seite in einer Fremdsprache besuchen, verlieren ohne korrekte Angabe das automatische Übersetzungsangebot.
Richtig & falsch im Code
<!-- Falsch: Attribut fehlt komplett -->
<html>
<!-- Falsch: Boilerplate-Englisch auf einer deutschen Seite -->
<html lang="en">
<!-- Falsch: ausgeschriebene Sprache, kein gültiger Code -->
<html lang="deutsch">
<!-- Falsch: Unterstrich statt Bindestrich (Java-/PHP-Locale-Schreibweise) -->
<html lang="de_DE">
<!-- Richtig -->
<html lang="de">
<!-- Auch richtig: regionale Variante, wenn sie einen Zweck erfüllt -->
<html lang="de-AT">Der Wert gehört genau einmal gepflegt. In dieser Website kommt er aus der zentralen Konfiguration und landet über das Layout auf jeder Seite – so entsteht gar nicht erst die Situation, in der eine einzelne Vorlage aus der Reihe fällt.
<!-- Richtig: englischsprachige Unterseite trägt ihre eigene Sprache -->
<html lang="en">
<head><title>Accessibility statement</title></head>
Zwei verwandte Angaben werden gern verwechselt: lang beschreibt die Sprache dieses Dokuments, hreflang beschreibt die Sprache eines verlinkten
Dokuments. Beide zusammen ergeben erst ein sauberes mehrsprachiges Angebot – Details unter
Canonical, hreflang & Duplicate Content.
Fremdsprachige Passagen innerhalb einer Seite regelt das Schwesterkriterium 3.1.2 Sprache von Teilen.
So testest du es
- Quelltext ansehen (Strg + U) und die erste Zeile prüfen: Trägt
<html>einlang, und passt der Wert zur tatsächlichen Inhaltssprache? - Schreibweise kontrollieren: Bindestrich statt Unterstrich, Kleinschreibung beim Sprachcode, keine ausgeschriebenen Sprachnamen.
- axe DevTools laufen lassen. Die Regeln
html-has-lang,html-lang-validundvalid-langdecken den formalen Teil vollständig ab – das ist einer der wenigen Prüfpunkte, die Werkzeuge zuverlässig erledigen. - Alle Sprachversionen stichprobenartig öffnen. Bei mehrsprachigen Auftritten trägt gern nur die Hauptsprache die richtige Kennung, die Übersetzungen erben sie unverändert.
- Hörprobe mit NVDA: Klingt die Seite nach ihrer Sprache? Die automatische Sprachumschaltung muss dafür in den Stimmeneinstellungen aktiv sein.
- Silbentrennung als Gegenprobe: Ist
hyphens: autogesetzt und trennt der Browser trotzdem nicht, fehlt fast immer die Sprachangabe.
Ob lang gesetzt und der Sprachcode gültig ist, prüft der Struktur-Check automatisch mit.
Häufiger Fehler in der Praxis
Der Klassiker ist das geerbte lang="en". Fast jedes Starterprojekt, jedes CSS-Framework-Beispiel und jede Theme-Vorlage liefert englisches Boilerplate aus. Wer das beim Aufsetzen übersieht, hat den Fehler danach auf jeder einzelnen Seite – und weil optisch nichts kaputt ist, fällt er jahrelang nicht auf. Genau deshalb steht die Prüfung bei mir ganz vorn im Audit: Sie dauert zehn Sekunden und betrifft die komplette Website.
Der zweite ist der Sprachumschalter, der die Kennung vergisst. Das Redaktionssystem liefert die englische Fassung aus, das Layout setzt aber weiter lang="de", weil der Wert fest im Template steht. Ergebnis: Die deutsche Stimme liest englischen Text. Das ist genauso schlimm wie andersherum, wird aber seltener gemeldet, weil deutsche Muttersprachler die englische Seite selten mit Screenreader lesen.
Der dritte betrifft Single-Page-Anwendungen: Beim Sprachwechsel wird der Inhalt neu gerendert, das lang-Attribut am <html>-Element bleibt jedoch stehen, weil es außerhalb der React- oder Vue-Wurzel liegt. Hier muss die Anwendung document.documentElement.lang beim Sprachwechsel selbst setzen.
Häufige Fragen
Reicht lang="de" oder muss es de-DE sein?
de reicht und ist meistens die bessere Wahl. Der Regionalzusatz ist nur dann sinnvoll, wenn er eine Konsequenz hat – etwa bei de-CH, wo das ß nicht verwendet wird. Screenreader-Stimmen für de-DE und de-AT unterscheiden sich kaum, und ein zu spezifischer Wert kann dazu führen, dass keine passende Stimme gefunden wird.
Was passiert, wenn das lang-Attribut fehlt?
Der Screenreader nutzt seine Standardstimme – bei deutschen Nutzern also oft zufällig die richtige, bei Nutzern mit englischsprachigem System die falsche. Genau darin liegt die Tücke: Der Fehler zeigt sich beim Testen mit der eigenen Einrichtung häufig nicht. Formal ist 3.1.1 in jedem Fall nicht erfüllt.
Braucht eine Seite in Leichter Sprache eine eigene Sprachkennung?
Nein. Leichte Sprache ist eine Varietät des Deutschen und behält lang="de". Sinnvoll ist stattdessen, die Fassung im Link und in der Überschrift klar zu benennen und über die
Barrierefreiheitserklärung
auffindbar zu machen – bei öffentlichen Stellen ist sie dort ohnehin gefordert.
Gilt 3.1.1 auch für PDF-Dokumente?
Ja. Auch ein PDF muss seine Dokumentsprache angeben; in Acrobat steht der Wert in den Dokumenteigenschaften unter „Erweitert“. Wird das PDF aus Word erzeugt, wandert die Word-Spracheinstellung mit – Details unter PDF-Barrierefreiheit.
Was ist der Unterschied zwischen lang und hreflang?
lang gibt die Sprache des aktuellen Dokuments an und wird von assistiver Technik ausgewertet. hreflang steht an einem Link oder im <head> und beschreibt die Sprache des verlinkten Dokuments – es ist ein Signal für Suchmaschinen, nicht für Screenreader. Beide sind nötig, ersetzen sich aber nicht.
Verwandte Themen
- 3.1.2 Sprache von Teilen – fremdsprachige Abschnitte auszeichnen
- Dokument-Metadaten – der head als Fundament
- Screenreader-Grundlagen – wie Sprachausgabe tatsächlich funktioniert
- 1.4.10 Reflow – warum die Silbentrennung an derselben Angabe hängt
- Canonical & hreflang – Sprache aus SEO-Sicht