WCAG 3.1.1: Sprache der Seite

WCAG 3.1.1 verlangt, dass die Standardsprache jeder Webseite programmatisch ermittelt werden kann, hauptsächlich durch das Setzen eines gültigen lang-Attributs auf dem HTML-Element. Dies ermöglicht unterstützenden Technologien wie Screenreadern, Inhalte korrekt auszusprechen, und hilft Nutzern mit kognitiven und sprachbezogenen Beeinträchtigungen, die Seite zu verstehen.

Was diese Regel bedeutet

WCAG 3.1.1 — Language of Page ist ein Erfolgskriterium der Stufe A unter dem Prinzip Understandable (Verständlich). Es verlangt, dass die primäre menschliche Sprache jeder Webseite so offengelegt wird, dass unterstützende Technologien sie programmatisch erkennen können. In der Praxis bedeutet dies fast immer, dass ein gültiges lang-Attribut direkt auf dem <html>-Element der Seite gesetzt wird.

Der Wert des lang-Attributs muss ein gültiger BCP-47-Sprachtag sein. BCP-47-Tags bestehen aus einem primären Sprach-Subtag (wie en für Englisch, tr für Türkisch, fr für Französisch) und optional einem Regions-Subtag, getrennt durch einen Bindestrich (wie en-US, tr-TR oder pt-BR). Der Sprachtag muss die dominante Sprache, in der der Seiteninhalt verfasst ist, korrekt widerspiegeln. Eine Seite, die hauptsächlich auf Türkisch geschrieben ist, muss lang='tr' oder lang='tr-TR' deklarieren; eine Seite, die auf Englisch geschrieben ist, muss lang='en' oder eine regionale Variante deklarieren.

Eine Seite besteht dieses Kriterium, wenn das <html>-Element ein lang-Attribut trägt, dessen Wert ein nicht leerer, syntaktisch gültiger BCP-47-Sprachtag ist, der die primäre Sprache der Seite korrekt identifiziert. Eine Seite fällt durch, wenn das lang-Attribut vollständig fehlt, wenn der Wert leer ist (lang='') oder wenn der Wert kein anerkannter BCP-47-Sprachtag ist (zum Beispiel lang='turkish' oder lang='en_US' mit einem Unterstrich statt eines Bindestrichs).

Für XHTML-Seiten, die mit einem XML-MIME-Typ ausgeliefert werden, sollten sowohl das lang-Attribut als auch das XML-Namensraum-Attribut xml:lang vorhanden sein, und ihre Werte müssen übereinstimmen. Eine Abweichung zwischen den beiden — etwa lang='en' zusammen mit xml:lang='tr' — stellt sowohl einen Verstoß gegen dieses Kriterium als auch gegen die zugehörige axe-core-Regel html-xml-lang-mismatch dar.

WCAG nennt ausdrücklich eine Ausnahme: Wenn die Seite rein dekorativ ist, ein CAPTCHA darstellt, das absichtlich keine erkennbare Sprache hat, oder vollständig aus nichtsprachlichen Inhalten besteht (z. B. eine Seite, die nur aus einem Bild ohne Text besteht), kann sie keine bestimmbare Sprache haben. Diese Ausnahme ist jedoch eng gefasst, und die überwiegende Mehrheit realer Seiten enthält genügend Text, um eine Sprachdeklaration zu erfordern.

Warum das wichtig ist

Die Hauptnutznießer einer korrekt deklarierten Seitensprache sind Screenreader-Nutzer, von denen die meisten blind sind oder eine starke Sehbehinderung haben. Screenreader wie NVDA, JAWS und VoiceOver verwenden das lang-Attribut, um die passende Text-to-Speech-(TTS-)Stimme und das richtige Aussprachemodul auszuwählen. Wenn eine türkische Nutzerin eine Seite besucht, die korrekt lang='tr' deklariert, schaltet ihr Screenreader auf eine türkische TTS-Stimme um und wendet korrekte türkische Phonologie, Betonungsmuster und Diakritika an. Ohne diese Deklaration kann ein Screenreader auf die Systemsprache der Nutzerin oder auf eine völlig falsche Sprache zurückfallen, was zu einer unverständlichen, „kauderwelschartigen“ Aussprache führt, die den Inhalt unverständlich macht.

Betrachten wir ein konkretes Szenario: Eine sehbehinderte türkische Bürgerin besucht die Website einer öffentlichen Institution, um ein Behördenformular herunterzuladen. Die Seite lässt das lang-Attribut weg. Die NVDA-Installation der Nutzerin verwendet standardmäßig ein englisches TTS-Profil. Türkische Wörter werden mit englischer Phonologie vorgelesen — Wörter wie „şehir“ (Stadt) oder „başvuru“ (Antrag) werden unkenntlich. Die Nutzerin kann das Formular ohne sehende Unterstützung nicht ausfüllen, womit der gesamte Zweck des digitalen Dienstes verfehlt wird.

Nutzer mit kognitiven und Lernbehinderungen profitieren ebenfalls. Browser verwenden das lang-Attribut, um präzise Übersetzungsvorschläge anzubieten; einige Nutzer mit Legasthenie verlassen sich auf browserbasierte Übersetzungstools, um Inhalte in eine Sprache zu übertragen, die sie leichter verarbeiten können. Ein falsches oder fehlendes lang-Attribut führt dazu, dass diese Tools die Ausgangssprache falsch erkennen und schlechte Übersetzungen liefern oder gar keinen Übersetzungsvorschlag machen.

Nutzer mit motorischen Beeinträchtigungen, die auf Sprachsteuerungssoftware wie Dragon NaturallySpeaking angewiesen sind, sind darauf angewiesen, dass die Software die Sprache einer Seite korrekt interpretiert, um gesprochene Befehle mit dem Text auf dem Bildschirm abzugleichen. Eine falsch erkannte Seitensprache unterbricht diesen Abgleich.

Über die Barrierefreiheit hinaus gibt es handfeste SEO-Vorteile: Suchmaschinen verwenden das lang-Attribut als eines von mehreren Signalen, um die Zielsprache und Region einer Seite zu bestimmen und so die Genauigkeit lokalisierter Suchergebnisse zu verbessern. Korrekte Sprachkennzeichnung verbessert außerdem die Zuverlässigkeit der Rechtschreib- und Grammatikprüfung im Browser für alle Nutzer, nicht nur für diejenigen, die unterstützende Technologien verwenden. Laut der Weltgesundheitsorganisation haben weltweit etwa 2,2 Milliarden Menschen eine Form von Sehbeeinträchtigung, von denen ein erheblicher Teil auf Screenreader angewiesen ist — damit gehört die korrekte Sprachdeklaration zu den wirkungsvollsten und zugleich am wenigsten aufwendigen Verbesserungen der Barrierefreiheit.

Wie man testet

Automatischer Scan mit axe DevTools oder Lighthouse: Öffnen Sie die Seite in Chrome oder Firefox. Öffnen Sie die DevTools (F12), wechseln Sie zum axe-DevTools-Panel oder zum Lighthouse-Tab und führen Sie einen vollständigen Barrierefreiheits-Audit durch. Achten Sie speziell auf Verstöße gegen die Regeln html-has-lang, html-lang-valid und html-xml-lang-mismatch. Axe hebt das <html>-Element hervor und beschreibt den konkreten Fehler. Lighthouse zeigt ähnliche Probleme in der Kategorie Accessibility an. Notieren Sie alle markierten Verstöße und die empfohlenen Korrekturen.
Manuelle Quellcode-Inspektion: Zeigen Sie den Seitenquelltext an (Strg+U in den meisten Browsern) und suchen Sie das öffnende <html>-Tag. Prüfen Sie, ob es ein lang-Attribut enthält, ob der Attributwert ein gültiger BCP-47-Tag ist (Abgleich mit dem IANA Language Subtag Registry) und ob er die Sprache, in der der Seiteninhalt verfasst ist, korrekt widerspiegelt. Für XHTML-Seiten prüfen Sie außerdem, ob ein vorhandenes xml:lang-Attribut dasselbe primäre Sprach-Subtag wie lang trägt.
Screenreader-Tests mit NVDA und Firefox: Installieren Sie NVDA (kostenlos, Windows) und öffnen Sie die Seite in Firefox. Drücken Sie NVDA+T, um den Seitentitel vorzulesen, und achten Sie auf die verwendete TTS-Stimme. Wenn die Seite auf Türkisch ist, sollte die Stimme eine türkische TTS-Stimme sein, und türkische Wörter sollten korrekt ausgesprochen werden. Wenn Sie bei türkischen Inhalten eine englische oder sonst falsche Stimme hören, ist das lang-Attribut fehlend oder falsch. Wiederholen Sie den Test mit JAWS in Chrome und VoiceOver in Safari auf macOS (Cmd+F5, um VoiceOver zu aktivieren, dann zur Seite navigieren und auf die Aussprache des Fließtexts achten).
Prüfung der Spracherkennung im Browser: Öffnen Sie die Seite in Chrome. Achten Sie auf die integrierte Übersetzungsleiste des Browsers — Chrome bietet an, Seiten zu übersetzen, die es als fremdsprachig im Verhältnis zu den Browsereinstellungen erkennt. Wenn Chrome die Seitensprache falsch erkennt oder keine Übersetzung anbietet, obwohl es dies tun sollte, ist dies ein praktischer Hinweis darauf, dass das lang-Attribut falsch oder fehlend ist. Dies ist kein definitiver Barrierefreiheitstest, aber ein nützlicher sekundärer Indikator.
Prüfung der semantischen Genauigkeit (nur manuell): Lesen Sie den Seiteninhalt durch und bestätigen Sie, dass der deklarierte lang-Wert mit der tatsächlichen primären Sprache der Seite übereinstimmt. Automatisierte Tools können diese Prüfung nicht durchführen. Achten Sie besonders auf mehrsprachige Websites, die verschiedene Sprachversionen unter unterschiedlichen URLs bereitstellen — jede URL-Seite sollte ihre eigene korrekte Sprache deklarieren und nicht einen einzigen globalen Standardwert erben.

Wie man es behebt

Fehlendes lang-Attribut — Falsch

<!DOCTYPE html>
<html>
  <head>
    <meta charset='UTF-8'>
    <title>Başvuru Formu</title>
  </head>
  <body>
    <h1>Hoş Geldiniz</h1>
  </body>
</html>

Fehlendes lang-Attribut — Richtig

<!DOCTYPE html>
<html lang='tr'>
  <!-- lang='tr' weist Screenreader an, eine türkische TTS-Stimme zu verwenden -->
  <head>
    <meta charset='UTF-8'>
    <title>Başvuru Formu</title>
  </head>
  <body>
    <h1>Hoş Geldiniz</h1>
  </body>
</html>

Ungültiger lang-Attributwert — Falsch

<!DOCTYPE html>
<html lang='turkish'>
  <!-- 'turkish' ist kein gültiger BCP-47-Tag; axe markiert html-lang-valid -->
  <head>
    <title>Kurumsal Site</title>
  </head>
  <body>
    <p>Şirketimiz hakkında bilgi edinmek için buraya tıklayın.</p>
  </body>
</html>

Ungültiger lang-Attributwert — Richtig

<!DOCTYPE html>
<html lang='tr'>
  <!-- Verwenden Sie den zweibuchstabigen ISO-639-1-Code 'tr', nicht das englische Wort 'turkish' -->
  <head>
    <title>Kurumsal Site</title>
  </head>
  <body>
    <p>Şirketimiz hakkında bilgi edinmek için buraya tıklayın.</p>
  </body>
</html>

XHTML xml:lang-Missmatch — Falsch

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Strict//EN'
  'http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd'>
<html xmlns='http://www.w3.org/1999/xhtml' lang='en' xml:lang='tr'>
  <!-- lang und xml:lang stimmen nicht überein — Verstoß gegen html-xml-lang-mismatch -->
  <head><title>XHTML Sayfası</title></head>
  <body><p>İçerik burada.</p></body>
</html>

XHTML xml:lang-Missmatch — Richtig

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Strict//EN'
  'http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd'>
<html xmlns='http://www.w3.org/1999/xhtml' lang='tr' xml:lang='tr'>
  <!-- Sowohl lang als auch xml:lang sind 'tr' — konsistent und gültig -->
  <head><title>XHTML Sayfası</title></head>
  <body><p>İçerik burada.</p></body>
</html>

Falsche Sprache auf einer mehrsprachigen Website deklariert — Falsch

<!-- Englischsprachige Version der Website, aber lang ist global auf 'tr' gesetzt -->
<html lang='tr'>
  <head><title>About Us</title></head>
  <body>
    <p>Welcome to our company. We specialize in accessible web solutions.</p>
  </body>
</html>

Falsche Sprache auf einer mehrsprachigen Website deklariert — Richtig

<!-- Jede Sprachversion deklariert ihr eigenes korrektes lang-Attribut -->
<html lang='en'>
  <!-- Dies ist die englische Seite; die türkische Seite unter /tr/ deklariert lang='tr' -->
  <head><title>About Us</title></head>
  <body>
    <p>Welcome to our company. We specialize in accessible web solutions.</p>
  </body>
</html>

Häufige Fehler

Verwendung des vollständigen englischen Namens der Sprache statt ihres BCP-47-Codes — etwa lang='turkish', lang='english' oder lang='arabic' statt der korrekten Codes tr, en und ar. Diese Werte werden von unterstützenden Technologien nicht erkannt.
Verwendung eines Unterstrichs als Regions-Trenner — etwa lang='en_US' oder lang='tr_TR' statt der mit Bindestrich getrennten Formen lang='en-US' und lang='tr-TR'. BCP 47 verlangt Bindestriche, keine Unterstriche.
Setzen des lang-Attributs auf <body> statt auf <html> — das lang-Attribut muss auf dem Wurzel-<html>-Element stehen, um die axe-core-Regel html-has-lang zu erfüllen und unterstützenden Technologien den benötigten Sprachkontext auf Seitenebene zu geben, bevor irgendein Inhalt geparst wird.
Belassen von lang als leere Zeichenkette — lang='' wird von den meisten unterstützenden Technologien wie ein fehlendes Attribut behandelt und von html-has-lang markiert, da eine leere Zeichenkette kein gültiger Sprachtag ist.
Kopieren einer Vorlage aus einem anderssprachigen Projekt, ohne das lang-Attribut zu aktualisieren — ein sehr häufiges Problem in türkischen Entwicklungs-Workflows, bei denen ein englischsprachiges Boilerplate wiederverwendet wird und das lang='en' im <html>-Tag nie in lang='tr' geändert wird.
Deklaration des korrekten lang-Attributs, aber keine Aktualisierung beim Start einer neuen Sprachversion der Website — mehrsprachige Sites, die serverseitiges Rendering verwenden, müssen sicherstellen, dass das lang-Attribut pro Locale dynamisch gesetzt wird und nicht mit einem einzigen Wert in einem gemeinsamen Layout-Template fest verdrahtet ist.
Annahme, dass ein CMS oder Framework das lang-Attribut automatisch korrekt setzt — viele CMS-Plattformen (einschließlich einiger Konfigurationen von WordPress, Joomla und benutzerdefinierten Frameworks) setzen standardmäßig kein gültiges lang-Attribut. Entwickler müssen dies auf Template-Ebene überprüfen und dürfen nicht davon ausgehen, dass es automatisch erledigt wird.
Verwechslung des lang-Attributs (für HTML) mit dem Content-Language-HTTP-Header — der HTTP-Header beeinflusst Caching und Content Negotiation, wird aber von Screenreadern nicht verwendet. Das im Dokument gesetzte lang-Attribut auf <html> ist der richtige Mechanismus für die Einhaltung von WCAG 3.1.1.
Verwendung eines gültigen, aber falschen Regions-Subtags, das einen anderen Dialekt impliziert — zum Beispiel die Deklaration von lang='zh-TW' (Traditionelles Chinesisch, Taiwan) auf einer Seite, die in vereinfachtem Chinesisch (zh-CN) geschrieben ist, kann dazu führen, dass ein Screenreader das falsche Stimmprofil und falsche Ausspracheregeln auswählt.
Vergessen, lang bei dynamisch eingefügten Vollseiteninhalten in Single-Page-Applications (SPAs) zu setzen — wenn eine SPA Inhalte in mehreren Sprachen innerhalb derselben Dokumenthülle lädt, ohne das lang-Attribut zu aktualisieren, erhalten Nutzer, die zwischen Sprachabschnitten navigieren, keine korrekte TTS-Aussprache für neue Inhaltsbereiche.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

WCAG 3.1.1 Language of Page hat in der Türkei unmittelbare rechtliche Relevanz im Rahmen des Präsidialerlasses 2025/10, der am 21. Juni 2025 im Amtsblatt Nr. 32933 veröffentlicht wurde. Dieser Erlass legt verbindliche Anforderungen an die Web-Barrierefreiheit fest, die sich an WCAG 2.2 orientieren, und bestimmt Konformität der Stufe A als Mindeststandard für alle erfassten Stellen.

Der Erlass umfasst ein breites Spektrum von Organisationen des öffentlichen und privaten Sektors. Öffentliche Institutionen — darunter Ministerien, Kommunen, staatliche Universitäten, öffentliche Krankenhäuser sowie alle zentralen und lokalen Regierungsstellen — müssen innerhalb von einem Jahr nach Veröffentlichung des Erlasses vollständige Konformität der Stufe A erreichen. Private Sektorunternehmen, die von der Regelung erfasst sind, haben ein zweijähriges Umsetzungsfenster; dazu gehören E‑Commerce-Plattformen, Banken und Finanzinstitute, private Krankenhäuser und Gesundheitsdienstleister, Telekommunikationsanbieter mit 200.000 oder mehr Abonnenten, Reisebüros, private Transportunternehmen und Privatschulen, die mit Genehmigung des Bildungsministeriums (MoNE) betrieben werden.

Da WCAG 3.1.1 ein Kriterium der Stufe A ist, fällt es in den verbindlichen Mindeststandard für jede vom Erlass erfasste Stelle. Die Website einer türkischen öffentlichen Institution, die lang='tr' in ihrem <html>-Element weglässt — oder einen falschen oder ungültigen Sprachtag deklariert — steht in direktem Widerspruch zu einem gesetzlich vorgeschriebenen Standard. Für private Organisationen wie Banken und E‑Commerce-Plattformen stellt derselbe Fehler innerhalb ihres Umsetzungsfensters einen Verstoß gegen die Regulierung dar.

Die praktische Konsequenz für türkische Webteams ist erheblich: Jedes Seitentemplate, jedes CMS-Layout, jede SPA-Hülle und jede dynamisch generierte Seite muss geprüft werden, um das Vorhandensein eines gültigen lang='tr' (oder einer passenden Variante) auf dem Wurzel-HTML-Element zu bestätigen. Dies ist nicht nur eine Best-Practice-Empfehlung — es ist nach Erlass 2025/10 eine gesetzliche Verpflichtung. Da die axe-core-Regeln html-has-lang und html-lang-valid den Großteil dieser Fehler automatisch erkennen können, gibt es keine technische Hürde, dieses Problem vor Ablauf der Umsetzungsfristen zu identifizieren und zu beheben.

Organisationen, die dem Erlass unterliegen, sollten die Einhaltung von WCAG 3.1.1 als vorrangige Maßnahme behandeln: Es gehört zu den am einfachsten zu behebenden Kriterien (ein einziges Attribut auf einem einzigen Element), hat aber einen überproportional großen Einfluss auf die Barrierefreiheit jeder Seite für Screenreader-Nutzer — jene Gruppe, deren Rechte die Regulierung am unmittelbarsten zu schützen versucht.