Die Regel html-lang-valid meldet ein lang-Attribut am <html>-Element, dessen Wert kein gültiger Sprachcode ist – zum Beispiel de_DE mit Unterstrich oder das Wort deutsch. Software kann den Wert nicht lesen und behandelt die Seite, als hätte sie gar keine Sprache. Die Lösung ist ein korrekt geschriebener Code wie lang="de-DE".
Was die Regel bedeutet
WCAG 3.1.1 Sprache der Seite verlangt, dass Software die Hauptsprache der Seite ermitteln kann. Ein lang-Wert leistet das nur, wenn er BCP 47 folgt, dem Standard für Sprachcodes: ein Sprachcode aus dem IANA-Register, optional gefolgt von weiteren Teilen, getrennt durch Bindestriche – de, de-DE, de-AT, zh-Hant.
axe-core prüft den ersten Teil – alles vor dem ersten Bindestrich – gegen seine Liste bekannter Sprachcodes. Das heißt:
de_DE,en_US,deutsch,ger: Der erste Teil ist kein bekannter Code, die Regel schlägt an.de-DE,DE-de,de: bestehen. Groß- und Kleinschreibung spielt keine Rolle.- Ein leeres
lang=""prüft diese Regel nicht; ein fehlender oder leerer Wert ist Sache von undefined.
Was die Regel nicht prüft: ob der Code die Sprache nennt, in der die Seite wirklich geschrieben ist (eine deutsche Seite mit lang="en" besteht), und ob der Regionsteil sinnvoll ist (de-EN besteht, obwohl es keine Region „EN“ gibt).
Wen es betrifft
Dieselben Menschen wie bei einer fehlenden Sprache: blinde und sehbehinderte Menschen mit Screenreader, deren Software Stimme und Aussprache nach der Seitensprache wählt. Einen unlesbaren Code übergeht der Screenreader und bleibt bei seiner Standardstimme – der Text wird dann womöglich mit falschen Ausspracheregeln vorgelesen. Auch Übersetzungsfunktion, Silbentrennung und Rechtschreibprüfung in Formularfeldern brauchen einen Code, den sie verstehen.
Warum die Prüfung anschlägt
- CMS-Locales direkt ins Template übernommen. Viele Systeme speichern die Locale als
de_DEoderen_US; unverändert inlangausgegeben, macht der Unterstrich den Wert ungültig. - Sprachnamen statt Codes, etwa
lang="deutsch"oderlang="german". - Nicht ersetzte Platzhalter im Template, etwa
lang="{{ locale }}"oderlang="LANG". - Dreibuchstabige Codes wie
lang="ger"oderlang="deu". Wo es einen zweibuchstabigen Code gibt, verwendet BCP 47 diesen:de,en. - Ländercodes statt Sprachcodes, etwa
lang="dk"für Dänisch (richtig:da) oderlang="jp"für Japanisch (richtig:ja). Heikler istlang="se"für Schwedisch:sesteht für Nordsamisch, die Regel besteht also – und die Seite ist trotzdem mit der falschen Sprache ausgezeichnet.
So beheben Sie es
- Suchen Sie die Stelle, an der das Template
langausgibt, und die Quelle des Werts – eine CMS-Einstellung, eine Locale-Variable, ein Übersetzungs-Plugin. - Wandeln Sie Locale-Bezeichner in BCP 47 um: Unterstrich durch Bindestrich ersetzen (
de_DE→de-DE) oder nur den Sprachteil verwenden (de). - Schlagen Sie ungewöhnliche Codes im IANA-Register nach – ein Sprachcode ist nicht dasselbe wie ein Ländercode.
<!-- Vorher: eine CMS-Locale mit Unterstrich ist kein Sprachcode -->
<!doctype html>
<html lang="de_DE">
<head>
<meta charset="utf-8">
<title>Öffnungszeiten – Stadtbibliothek Beispielstadt</title>
</head>
<body>
<main><h1>Öffnungszeiten</h1></main>
</body>
</html><!-- Nachher: gültiger BCP-47-Code mit Bindestrich -->
<!doctype html>
<html lang="de-DE">
<head>
<meta charset="utf-8">
<title>Öffnungszeiten – Stadtbibliothek Beispielstadt</title>
</head>
<body>
<main><h1>Öffnungszeiten</h1></main>
</body>
</html>In PHP erledigt str_replace('_', '-', $locale) die Umwandlung. Viele Frameworks bieten bereits eine Hilfsfunktion, die den Code in der richtigen Form liefert – nutzen Sie diese statt der rohen Locale.
So prüfen Sie es von Hand
- Öffnen Sie den Seitenquelltext oder geben Sie in der Browserkonsole
document.documentElement.langein. - Prüfen Sie das Format: Buchstaben und Bindestriche, keine Unterstriche, keine Leerzeichen, keine ausgeschriebenen Sprachnamen.
- Schlagen Sie den ersten Teil im IANA-Register nach oder prüfen Sie die Seite mit dem kostenlosen W3C Internationalization Checker, der fehlerhafte Codes meldet.
- Prüfen Sie, ob der Code zum Text der Seite passt –
destattenauf der falschen Seite sieht die Regel nicht. - Auf mehrsprachigen Websites wiederholen Sie das für jede Sprachversion.
Zugehöriges WCAG-Kriterium
3.1.1 Sprache der Seite, Stufe A. Verwandt: 3.1.2 Sprache von Teilen für anderssprachige Passagen, für die dasselbe Format gilt.
So meldet Reviseberg diese Regel
Reviseberg führt html-lang-valid auf jeder gecrawlten Seite bei 1280 px aus. Weil der Wert meist aus einem Template oder einer CMS-Einstellung stammt, erscheint der Befund oft auf allen Seiten einer Sprachversion gleichzeitig. In der Befundliste sehen Sie die Regel mit Schweregrad, WCAG-Kriterium 3.1.1 und Stufe, der Zahl der Seiten und den Punkten, die ein Fix zurückbringt. Im Detail stehen der Selektor, der HTML-Ausschnitt mit dem ungültigen Wert und alle betroffenen Seiten – bei einer mehrsprachigen Website sehen Sie so sofort, welche Sprachversion betroffen ist. Befunde können Sie mit Begründung als „ignorieren“, „nicht behebbar“ oder „Fehlalarm“ markieren; jede Entscheidung wird protokolliert.
Ob der Code die richtige Sprache nennt, kann ein Crawl nicht entscheiden. Das prüfen Sie von Hand, wie oben beschrieben.
Verwandte Regeln
- undefined – das
<html>-Element hat gar keinlang. - undefined – dieselbe Prüfung für
langan Elementen innerhalb der Seite. - undefined – eine weitere Angabe, die im Template gesetzt wird.
Sprachcodes auf Ihrer ganzen Website prüfen – kostenloser Scan