3.1.1 Sprache der Seite

1. Was ist das Ziel dieses Kriteriums?

Das Internet verbindet Menschen aus aller Welt – und mit ihnen viele Sprachen. Aber was passiert, wenn ein Screenreader einen deutschen Text mit englischen Ausspracheregeln vorliest? Das Ergebnis klingt, als würde jemand Goethe mit starkem amerikanischem Akzent vortragen – verständlich wird es jedenfalls nicht.

Das Ziel von Erfolgskriterium 3.1.1 der WCAG ist daher klar: Jede Seite kennzeichnet ihre Hauptsprache im Code. So können Screenreader, Browser und andere Hilfsmittel die richtigen Ausspracheregeln laden, Schriftzeichen korrekt darstellen und Inhalte verständlich wiedergeben.

Kurz gesagt: Wenn deine Website auf Deutsch ist, muss das auch für Computer erkennbar sein.

2. Was fordert das Erfolgskriterium genau?

Die Standardsprache jeder Seite muss programmatisch ermittelbar sein. Das bedeutet ganz konkret:

Eindeutige Sprachkennzeichnung: Die Hauptsprache einer Seite ist im HTML-Code hinterlegt – in der Regel über das lang-Attribut am <html>-Element.

Bestimmung der Hauptsprache: Verwendet eine Seite mehrere Sprachen, ist die Standardsprache die, die am meisten vorkommt. Kommen mehrere Sprachen gleich häufig vor, wählst du die, die zuerst verwendet wird.

Technische Umsetzung: Die Sprache muss so angegeben sein, dass Browser und Assistenztechnologien sie automatisch erkennen.

Ausnahmen: Es gibt keine – jede Seite braucht eine Sprachkennzeichnung.

Ein einfaches Beispiel: Eine deutsche Seite verwendet <html lang="de">, eine englische <html lang="en">, eine französische <html lang="fr">.

Wechselt die Sprache innerhalb der Seite, etwa bei einem englischen Zitat, regelt das Sprache von Teilen.

3. Warum ist das wichtig für Barrierefreiheit?

Stell dir vor, du bist blind und besuchst mit einem Screenreader eine englische Website – aber die Seite gibt fälschlich Deutsch als Sprache an. Der Screenreader liest englische Wörter mit deutschen Ausspracheregeln vor. Aus „Hello World“ wird unverständliches Kauderwelsch.

Die Sprachkennzeichnung schafft Barrierefreiheit, weil sie:

• Screenreader unterstützt: Sie laden die passenden Ausspracheregeln und lesen Texte verständlich vor.
• Browsern hilft: Zeichen und Schriften werden korrekt dargestellt – besonders wichtig bei anderen Alphabeten oder Schreibrichtungen.
• Medienwiedergabe verbessert: Mediaplayer können Untertitel korrekt anzeigen.
• beim Lesen unterstützt: Menschen mit Lese- oder Lernschwierigkeiten profitieren von Vorlese-Software, die richtig ausspricht.
• Hilfsfunktionen ermöglicht: Rechtschreibprüfung, automatische Silbentrennung per CSS und Übersetzungsangebote des Browsers greifen auf die Sprachangabe zurück.

4. So setzt du das Kriterium erfolgreich um

Die gute Nachricht: Sprachkennzeichnung ist technisch einfach – meist reicht eine Zeile Code. Hier die bewährten Praxis-Tipps:

HTML-Grundlagen:

• Setze das lang-Attribut am <html>-Element: <html lang="de"> für deutsche Seiten.
• Verwende Sprachcodes nach BCP 47 in der kürzesten Form: de für Deutsch, en für Englisch, fr für Französisch.
• Regionale Varianten kannst du ergänzen: en-US (amerikanisches Englisch), en-GB (britisches Englisch), de-AT (österreichisches Deutsch).

Für verschiedene Dokumenttypen:

• HTML: <html lang="de">
• XHTML, als XML ausgeliefert: <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de">, bei Auslieferung als HTML zusätzlich lang="de"
• PDF-Dokumente: Lege die Dokumentsprache in den Dokumenteigenschaften fest; technisch landet sie im /Lang-Eintrag des Dokumentkatalogs.

Mehrsprachige Websites:

• Jede Sprachversion bekommt ihre eigene Sprachangabe – bei einer zweisprachigen Website also de auf den deutschen und en auf den englischen Seiten.
• Achte darauf, dass dein CMS oder Framework das Attribut je Sprache korrekt setzt und nicht überall den Standardwert ausgibt.
• Kennzeichne Sprachwechsel innerhalb der Seite zusätzlich (siehe 3.1.2).

Qualitätskontrolle:

• Teste mit einem Screenreader, zum Beispiel NVDA oder VoiceOver.
• Prüfe den Quelltext oder die Entwicklerwerkzeuge des Browsers.
• Verwende automatisierte Werkzeuge wie axe oder WAVE – fehlende lang-Attribute erkennen sie zuverlässig, eine falsche Sprache aber nicht.

Häufige Fehler vermeiden:

• Das lang-Attribut nie weglassen.
• Keine falsche Sprache angeben, etwa lang="en" aus einer englischen Vorlage auf deutschen Seiten.
• Keine ungültigen Codes verwenden – de statt german oder ger.

5. Warum dieses Erfolgskriterium für Unternehmen relevant ist

3.1.1 ist Teil von WCAG 2.1 Level A und damit über die EN 301 549 Maßstab für das BFSG, das seit dem 28. Juni 2025 unter anderem für Onlineshops, Bankdienstleistungen und andere Dienstleistungen für Verbraucher:innen gilt. Auch öffentliche Stellen müssen es über die BITV 2.0 bzw. das Landesrecht erfüllen. Dieser Abschnitt informiert allgemein und ersetzt keine Rechtsberatung.

1. Ein schneller Gewinn

Kaum ein Kriterium lässt sich so leicht erfüllen: eine Zeile Code, einmal im Template gesetzt. Gleichzeitig gehört ein fehlendes oder falsches lang-Attribut zu den Fehlern, die automatisierte Prüfwerkzeuge sofort melden.

2. Internationale Nutzer:innen besser erreichen

Mit korrekter Sprachkennzeichnung funktionieren Screenreader, Vorlesefunktionen und Übersetzungsangebote der Browser besser. Das verbessert die Nutzung für alle, die deine Inhalte in einer anderen als ihrer Muttersprache lesen.

3. Saubere technische Basis

Silbentrennung, Rechtschreibprüfung in Formularen und typografische Feinheiten hängen von der Sprachangabe ab. Barrierefreiheit ist kein direkter Rankingfaktor – eine saubere technische Basis hilft aber auch Suchmaschinen, deine Inhalte richtig zu verarbeiten.

6. Das Erfolgskriterium im Wortlaut des W3C

Success Criterion 3.1.1 Language of Page (Level A)

The default human language of each web page can be programmatically determined.

Kurz gesagt: Die Hauptsprache jeder Seite muss im Code so hinterlegt sein, dass Browser und Assistenztechnologien sie automatisch erkennen.