Warum dein Screenreader Deutsch mit englischem Akzent vorliest
Stell dir jemanden vor, der deine Startseite laut vorliest, aber nur Englischunterricht hatte und kein einziges deutsches Wort kennt. Aus "Herzlich willkommen bei der Bäckerei Musterhof" wird dann ungefähr "Hörtslick uillkammen bei där Bäckerai Sammer". Das "w" klingt wie in "water", das "ch" wird zum harten "k", das "ei" zum "ai" wie in "eye". Wer so etwas vorgelesen bekommt, versteht deinen Text nicht, sondern rät ihn.
Wir haben nachgesehen, wie oft das vorkommt. 6,3 Prozent der 14.984 geprüften Seiten geben ihre Sprache gar nicht an, weitere 1,8 Prozent sind fälschlich als englisch ausgezeichnet, obwohl der Inhalt deutsch ist. Zusammen sind das acht von hundert Seiten, also knapp jede zwölfte. Der zweite Fall ist der unangenehmere. Fehlt die Angabe komplett, raten viele Vorleseprogramme anhand der Systemsprache und liegen bei einem deutschen Publikum oft zufällig richtig. Steht dagegen ausdrücklich "englisch" im Quelltext, glaubt die Software das und schaltet die englische Stimme ein, auch wenn der ganze Bildschirm voller Umlaute ist.
Was die Vorlesestimme daraus macht
Ein Screenreader liest keine Buchstaben vor, er wendet Aussprache-Regeln an, und welche Regeln das sind, entscheidet er anhand der Sprachangabe des Dokuments. Steht dort "en", greifen englische Regeln. Umlaute kommen darin nicht vor, das "ß" fehlt im englischen Zeichenvorrat und wird je nach Stimme als "b" gesprochen oder verschluckt. Abkürzungen bekommen englische Buchstabennamen, "z. B." wird zu "zee bee" und "GmbH" zu "gee em bee aitch".
Wer täglich mit einem Screenreader arbeitet, erkennt das Muster nach wenigen Sekunden und schaltet von Hand auf die deutsche Stimme um. Das kostet Zeit und wiederholt sich auf jeder Seite, die denselben Fehler hat. Heikler sind kurze Textstücke, ein Feldname im Formular oder eine Fehlermeldung nach dem Absenden, denn dort ist zu wenig Text da, um den falschen Klang überhaupt als Fehler einzuordnen.
Betroffen sind auch Braillezeilen. Die deutsche Kurzschrift benutzt andere Kürzel als die englische, und welche Tabelle geladen wird, hängt ebenfalls an der Sprachangabe. Dazu kommen die Vorlesefunktionen, die inzwischen in jedem Browser und in jedem Telefon stecken. Auch sie fragen zuerst das Dokument, bevor sie eine Stimme wählen.
Der Handgriff im html-Tag
Die Sprache steht in einem einzigen Attribut ganz oben im Dokument, direkt am öffnenden html-Tag. So sieht eine Seite ohne Angabe aus:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Bäckerei Musterhof</title>
</head>
<body>
<h1>Herzlich willkommen</h1>
</body>
</html>
Und so mit:
<!DOCTYPE html>
<html lang="de">
<head>
<meta charset="utf-8">
<title>Bäckerei Musterhof</title>
</head>
<body>
<h1>Herzlich willkommen</h1>
</body>
</html>
Das war die ganze Änderung. lang="de" reicht völlig aus. Wenn du eine regionale Färbung mitgeben willst, geht auch lang="de-DE", lang="de-AT" oder lang="de-CH", was bei Stimmen mit regionaler Aussprache einen hörbaren Unterschied macht. Was du nicht brauchst, ist xml:lang, das stammt aus der XHTML-Zeit und ist in heutigem HTML nur eine Dopplung. Ebenfalls wirkungslos ist ein meta-Tag namens "language", das gelegentlich noch in alten Vorlagen herumliegt und von keinem Vorleseprogramm ausgewertet wird.
Einzelne fremdsprachige Stellen im Text
Deutsche Seiten enthalten fast immer ein paar englische Wörter, den Slogan, den Namen eines Produkts, ein Zitat aus einer Studie. Vorher steht so ein Satz unmarkiert im Fließtext und wird mit deutscher Stimme durchgenudelt:
<p>Unser Team arbeitet nach dem Prinzip
<strong>Trust the process</strong>.</p>
Nachher trägt genau dieses eine Element seine eigene Sprache, der Rest des Absatzes bleibt deutsch:
<p>Unser Team arbeitet nach dem Prinzip
<strong lang="en">Trust the process</strong>.</p>
Gute Screenreader wechseln an dieser Stelle die Stimme und danach wieder zurück. Übertreib es nicht, denn Wörter, die längst im Duden stehen, etwa Computer, Team oder Download, spricht die deutsche Stimme ohnehin so aus, wie deutsche Ohren es erwarten. Auszeichnen lohnt sich bei ganzen Sätzen, Zitaten und Namen, die englisch klingen sollen.
Wer die Angabe sonst noch ausliest
Nicht nur Hilfsmittel greifen auf das Attribut zu. Browser entscheiden daran, ob sie eine Übersetzung anbieten, was bei einer deutschen Seite mit lang="en" zu der absurden Situation führt, dass Chrome einem deutschen Besucher die Übersetzung ins Deutsche vorschlägt. Bei mehrsprachigen Websites sollte der Wert außerdem zu den hreflang-Verweisen passen, sonst behauptet dieselbe Seite an zwei Stellen etwas Verschiedenes. Systeme, die deinen Inhalt weiterverarbeiten, von Sprachassistenten über Lese-Apps bis zu KI-Suchen, nehmen die Angabe als ersten Hinweis, weil sie billiger ist als eine eigene Spracherkennung. Suchmaschinen bestimmen die Sprache dagegen vor allem aus dem sichtbaren Text, dort fällt ein falscher Wert kaum ins Gewicht.
Wo die Angabe in den gängigen Systemen sitzt
- WordPress: Einstellungen, dann Allgemein, dann Spracheinstellung der Website auf Deutsch. Das Theme gibt den Wert normalerweise über die Funktion
language_attributes()aus. Wenn sich nichts ändert, steht in der Dateiheader.phpein hart eingetrageneslang="en-US", das dort ersetzt werden muss. - Shopify: in
layout/theme.liquidsteht bei aktuellen Themeslang="{{ request.locale.iso_code }}". Ältere oder umgebaute Themes haben oft noch ein festes englisches Kürzel darin. - TYPO3: in der Site-Konfiguration je Sprache über das Sprachkürzel. Bei älteren Installationen kommt der Wert stattdessen aus
config.htmlTag_langKeyim TypoScript. - Webflow: in den Site-Einstellungen unter General; bei lokalisierten Projekten legt stattdessen die jeweilige Locale den Wert fest.
- Wix, Jimdo und Squarespace: die Sprache der Website in den allgemeinen Einstellungen umstellen und danach neu veröffentlichen. Direkten Zugriff auf das
html-Tag gibt es dort nicht. - Handgeschriebenes HTML: in jeder Datei einmal am
html-Tag, am besten gleich in der Vorlage, aus der neue Seiten entstehen.
Der Selbsttest in unter zwei Minuten
Du brauchst dafür nichts zu installieren, der Browser reicht.
- Öffne deine Startseite in Chrome, Edge oder Firefox.
- Klicke mit der rechten Maustaste auf eine leere Stelle der Seite und wähle "Untersuchen". Alternativ drückst du F12, auf dem Mac Cmd, Option und I zusammen.
- Wechsle auf den Reiter "Elemente" beziehungsweise "Inspektor" und scrolle in der Code-Ansicht ganz nach oben.
- Lies die Zeile direkt nach
<!DOCTYPE html>. Dort sollte<html lang="de">stehen. - Steht dort nur
<html>, fehlt die Angabe. Steht dortlang="en"oderlang="en-US", ist sie falsch. - Wiederhole den Blick auf einer Unterseite, einem Blogbeitrag und der Kontaktseite, denn manche Systeme setzen den Wert nur auf einem Teil der Vorlagen.
Wer es noch schneller mag, drückt Strg und U (auf dem Mac Cmd, Option und U) für den Seitenquelltext und sucht mit Strg und F nach lang=. Der erste Treffer ist die Angabe, um die es geht.
Was du danach im Blick behalten solltest
Die Sprachangabe gehört zu den Dingen, die einmal richtig gesetzt jahrelang halten und dann bei einem Theme-Wechsel still verschwinden. Nimm den Blick in die Entwicklerwerkzeuge deshalb in die Liste auf, die du nach jedem größeren Umbau abarbeitest. Dasselbe gilt für PDF-Dateien, die du zum Herunterladen anbietest, denn auch sie tragen intern eine Dokumentsprache, und auch dort steht bei Exporten aus englischsprachigen Programmen gern der falsche Wert. Wenn du wissen willst, wie deine Seite insgesamt dasteht, prüft der kostenlose Scan von Accessify das Attribut zusammen mit den übrigen technischen Grundlagen und zeigt dir, auf welchen Unterseiten es fehlt.
Ist deine Website barrierefrei? Der Schnelltest prüft deine Startseite in unter einer Minute und zeigt dir, wo es hakt. Ohne Anmeldung.
Seite kostenlos prüfen