WCAG & BFSG: WCAG-Referenz: Bedienbar

WCAG 2.4.2: Seitentitel

WCAG 2.4.2 verlangt, dass jede Seite einen <title> hat, der ihr Thema oder ihren Zweck beschreibt. Er ist das Erste, was ein Screenreader beim Seitenwechsel ansagt. Deshalb muss er auch außerhalb der Seite verständlich sein: im Browser-Tab, im Verlauf, im Lesezeichen und im Suchergebnis.

(Englisch: Page Titled; deutsche Normübersetzung: „Seite mit Titel versehen“. Der BIK-BITV-Test nennt den Prüfschritt „Sinnvolle Dokumenttitel“.)

Stufe Prinzip Teil der WCAG seit Rechtlich verbindlich?
A Bedienbar 2.0 (2008) Ja (über EN 301 549 in BFSG & BITV)

Das Wichtigste in Kürze

  • Zwei Bestandteile machen einen vollständigen Titel: die individuelle Seitenbeschreibung und der Name des Angebots. Fehlt der Angebotsname, bewertet der BITV-Test nur noch mit „eher erfüllt“.
  • Das Spezifische steht vorn. In schmalen Tabs und bei Screenreader-Ansagen wird hinten abgeschnitten. Vorn steht deshalb, was diese Seite von allen anderen unterscheidet.
  • Jeder Titel muss einzigartig sein. Zehnmal „Startseite“ macht Verlauf und Tab-Leiste unbrauchbar.
  • Schmuckzeichen gehören nicht in den Titel. Ketten aus Tilden, Gleichheits- oder Sternzeichen werden vom Screenreader mitgelesen; der BITV-Test bewertet das als nicht voll erfüllt.
  • Single-Page-Anwendungen müssen document.title bei jedem Routenwechsel setzen. Sonst heißt die ganze Anwendung dauerhaft wie ihr Einstiegspunkt.
  • Prozessschritte und Fehlerzustände gehören hinein: „Zahlung (Schritt 2 von 3)“ oder „3 Fehler im Registrierungsformular“.
  • Der Titel ist nicht die H1. Er muss ohne Seitenkontext funktionieren, die Überschrift steht im Kontext. Beide dürfen sich unterscheiden.
  • Doppelter Nutzen: Derselbe Titel ist die blaue Zeile im Suchergebnis und damit SEO-Grundausstattung.

Was gehört in den title-Tag?

Der Titel ist die einzige Information über eine Seite, die außerhalb dieser Seite existiert. Er steht im Tab, im Verlauf, im Lesezeichen, in der Fensterliste des Betriebssystems, im Suchergebnis und in der Vorschau, die ein Messenger beim Teilen erzeugt. Überall dort gibt es keinen Kontext. Nur dieser eine Satz steht zur Verfügung.

Für Screenreader-Nutzer kommt eine zweite Rolle dazu: Beim Laden einer neuen Seite und beim Wechsel zwischen Tabs wird der Titel als Erstes vorgelesen. Er ist die Antwort auf die Frage „Wo bin ich gelandet?“, bevor irgendein Inhalt kommt. Ein Titel wie „Willkommen“ beantwortet sie nicht.

Der BITV-Test macht daraus eine Zweiteilung, die in der WCAG selbst nur zwischen den Zeilen steht: Ein guter Titel enthält die individuelle Seitenbeschreibung und die Bezeichnung des Angebots. Fehlt der Angebotsname, bewertet der Prüfschritt mit „eher erfüllt“. Der Titel ist dann brauchbar, aber im Lesezeichen oder im Verlauf nicht mehr zuzuordnen.

Bewährt hat sich dieses Muster:

Seitentyp Titelmuster Beispiel
Inhaltsseite Thema | Angebot „BFSG-Checkliste für Websites | html-einfach.de“
Prozessschritt Schritt (x von y) | Angebot „Zahlung (Schritt 2 von 3) | Beispiel-Shop“
Fehlerzustand Anzahl Fehler und Thema | Angebot „3 Fehler im Registrierungsformular | Beispiel-Shop“
Suchergebnis Treffer für „Begriff“ | Angebot „12 Treffer für ‚Kontrast‘ | html-einfach.de“
Startseite Angebot: Kurzbeschreibung „html-einfach.de: Barrierefreiheit und semantisches HTML“

Ein Detail aus dem Prüfschritt, das kaum irgendwo steht: Frames und iframes brauchen eigene Titel. Wer einen eingebetteten Kartendienst oder ein Formular über <iframe> einbindet, muss das title-Attribut setzen. Sonst kündigt der Screenreader nur „Frame“ an.

Der vollständige Wortlaut steht im Understanding-Dokument des W3C zu 2.4.2; das deutsche Prüfvorgehen beschreibt der Prüfschritt 2.4.2 des BIK BITV-Tests.

Zwei Browser-Tableisten mit je vier Tabs untereinander. Oben, rot markiert, tragen alle vier Tabs denselben abgeschnittenen Text, der mit Beispiel-Shop beginnt und bei Ihr Onli… abbricht, darunter die Anmerkung: nicht unterscheidbar, der Screenreader sagt viermal dasselbe an. Unten, grün markiert, tragen dieselben vier Tabs die Titel Warenkorb (3 Artikel), Zahlung (Schritt 2 von 3), Versandarten und 3 Fehler im Formular, jeweils gefolgt vom Angebotsnamen, darunter die Anmerkung: das Spezifische steht vorn und bleibt auch im schmalen Tab sichtbar.
Dieselben vier Seiten: Steht der Angebotsname vorn, sind alle Tabs gleich. Steht das Thema vorn, bleibt jeder unterscheidbar.

Wen betrifft es besonders?

Für Screenreader-Nutzer ist der Titel der Ankunftspunkt. Wer zwischen mehreren Tabs wechselt (etwa zwischen Formular und Hilfeseite), hört beim Umschalten nur ihn. Sind alle Titel gleich, muss man jedes Mal neu in den Inhalt hineinhören, um zu wissen, wo man ist. Das ist kein Komfortverlust, sondern ein zusätzlicher Arbeitsschritt bei jedem Wechsel.

Menschen mit kognitiven Einschränkungen orientieren sich stark an Tab-Beschriftungen, wenn mehrere Fenster offen sind. Auch hier gilt: Zehn identische Tabs sind zehn Rätsel.

Wer mit Sprachsteuerung arbeitet, wechselt Fenster über deren Namen. Heißen drei Fenster gleich, funktioniert der Befehl nicht mehr eindeutig.

Und unabhängig von Behinderung profitiert jeder, der mit vielen Tabs arbeitet, in seinem Verlauf sucht oder ein Lesezeichen von vor drei Monaten wiederfindet. Der Titel ist eines der wenigen Dinge, deren Nutzen sich sofort messen lässt: an der Zahl der Leute, die den richtigen Tab beim ersten Versuch treffen.

Richtig & falsch im Code

<!-- Falsch: nichtssagend, überall gleich, mit Schmuckzeichen -->
<title>Startseite</title>
<title>Willkommen</title>
<title>=== Beispiel GmbH ===</title>
<title>Beispiel GmbH | Ihr Partner für innovative Lösungen seit 1987 | Home</title>

<!-- Richtig: spezifisch zuerst, Angebot dahinter -->
<title>BFSG-Checkliste für Websites | html-einfach.de</title>
<title>Zahlung (Schritt 2 von 3) | Beispiel-Shop</title>
<title>3 Fehler im Formular | Registrierung | Beispiel-Shop</title>

Bei Single-Page-Anwendungen ist der Titel der Punkt, an dem der Seitenwechsel für assistive Technik überhaupt erst sichtbar wird. Ohne ihn passiert aus Sicht des Screenreaders schlicht nichts:

// Richtig: Titel bei jedem Routenwechsel setzen …
router.afterEach((route) => {
  document.title = `${route.meta.titel} | Beispiel-Shop`;
});

Das allein reicht allerdings nicht: Anders als beim echten Seitenwechsel liest kein Screenreader den neuen Titel von sich aus vor. Deshalb gehört der Fokus nach dem Wechsel auf die neue Überschrift und eine Live-Region meldet den Wechsel:

// … und den Wechsel zusätzlich ansagen
router.afterEach((route) => {
  document.title = `${route.meta.titel} | Beispiel-Shop`;
  document.getElementById('routen-ansage').textContent =
    `${route.meta.titel} geladen`;
  document.querySelector('main h1')?.focus();
});
<h1 tabindex="-1">Zahlung</h1>
<p id="routen-ansage" role="status" class="visually-hidden"></p>

Eingebettete Inhalte bekommen ihren eigenen Titel im Attribut:

<!-- Falsch: der Screenreader kündigt nur „Frame" an -->
<iframe src="https://beispiel.de/karte"></iframe>

<!-- Richtig -->
<iframe src="https://beispiel.de/karte"
        title="Interaktive Karte mit unseren Standorten"></iframe>

So testest du es

  1. Durch die wichtigsten Seiten klicken und nur auf den Tab schauen. Ist jeder Titel einzigartig? Erkennt man am ersten Drittel schon, worum es geht? Der Tab zeigt bei vielen offenen Seiten kaum mehr als 20 Zeichen.
  2. Doppelte Titel maschinell suchen. Jeder SEO-Crawler (Screaming Frog, Sitebulb, auch die Search Console) listet identische Titel als eigenen Bericht. Das ist der schnellste Weg zu einer vollständigen Liste.
  3. Automatisch gegenprüfen: axe und Lighthouse melden fehlende, leere oder doppelte <title>-Elemente. Ob der Titel aussagekräftig ist, kann kein Werkzeug beurteilen. Das bleibt Sichtprüfung.
  4. Die Screenreader-Probe. Mit NVDA oder VoiceOver einen Seitenwechsel machen und nur auf die erste Ansage hören: Sagt sie, wo man gelandet ist?
  5. Prozesse und Fehlerfälle durchspielen. Ändert sich der Titel beim Wechsel von Schritt 1 auf Schritt 2? Nach einer fehlgeschlagenen Übermittlung? In der Suchergebnisliste mit anderem Suchbegriff?
  6. Bei Single-Page-Anwendungen im Verlauf nachsehen. Der Browser-Verlauf ist der ehrlichste Test: Steht dort zehnmal derselbe Eintrag, wird document.title nicht gesetzt.

Ob überhaupt ein Titel da ist und ob er mehr sagt als „Startseite“, prüft der Struktur-Check automatisch mit.

Häufiger Fehler in der Praxis

Der häufigste Befund ist der Angebotsname vorn. „Beispiel GmbH: Über uns“, „Beispiel GmbH: Leistungen“, „Beispiel GmbH: Kontakt“: Im schmalen Tab sieht man nur „Beispiel GmbH: …“, und der Screenreader sagt bei jedem Wechsel zuerst dreimal dasselbe. Umgedreht funktioniert derselbe Titel einwandfrei. Es ist die Korrektur mit dem besten Verhältnis von Aufwand zu Wirkung, die ich kenne (meistens eine Zeile im Template).

Der zweite ist der Titel aus dem Redaktionssystem, der nie angefasst wurde: „Neue Seite“, „Seite 2“, „Kopie von Kontakt“, „unbenannt-3“. Solche Titel entstehen nicht aus Unwissen, sondern weil das Feld im Redaktionssystem weit unten liegt und optional ist. Ich hab mir angewöhnt, in Audits zuerst nach genau diesen Zeichenketten zu suchen. Sie sind praktisch immer da.

Der dritte ist die dekorierte Titelzeile. Sternchen, Pfeile, Tilden oder Trennketten aus Gleichheitszeichen sollen im Suchergebnis auffallen. Der Screenreader liest sie mit: „Stern Stern Stern Sommeraktion Stern Stern Stern“. Der BITV-Test führt Schmuckzeichen ausdrücklich als Grund für die Bewertung „nicht voll erfüllt“ auf. Ein einzelnes Trennzeichen wie der senkrechte Strich oder der Gedankenstrich ist dagegen unproblematisch. Die meisten Screenreader lesen es in der Standardeinstellung gar nicht vor.

Häufige Fragen

Muss der Titel mit der H1 übereinstimmen?

Nein. Die beiden haben verschiedene Aufgaben: Die H1 steht im Kontext der Seite und darf deshalb kurz sein, der Titel steht ohne Kontext im Tab und braucht meist den Angebotsnamen dazu. Sie sollten aber dasselbe Thema benennen. Ein Titel, der etwas anderes ankündigt als die Überschrift zeigt, ist irreführend.

Wie lang darf ein Seitentitel sein?

Die WCAG nennt keine Grenze. Praktisch zählen zwei Beschränkungen: Der Browser-Tab zeigt bei vielen offenen Seiten kaum mehr als 20 bis 30 Zeichen, und Google schneidet die SERP-Zeile bei etwa 580 Pixeln ab, was ungefähr 60 Zeichen entspricht. Für die SEO-Seite des Themas gilt der Korridor 30 bis 60 Zeichen. Für die Barrierefreiheit zählt nur, dass das Aussagekräftige vorn steht.

Gilt das Kriterium auch für PDF-Dateien?

Ja. Ein PDF braucht einen Dokumenttitel in den Metadaten, und in den Anzeigeeinstellungen muss „Dokumenttitel“ statt „Dateiname“ eingestellt sein. Sonst zeigt der Reader weiterhin Antrag_final_v3.pdf an. Details unter PDF-Barrierefreiheit.

Wie mache ich das in einer Single-Page-Anwendung richtig?

document.title muss bei jedem Routenwechsel gesetzt werden. Das erfüllt 2.4.2. Damit der Wechsel auch bemerkt wird, gehören zwei Dinge dazu: den Fokus auf die neue Überschrift setzen und den Wechsel über eine Live-Region ansagen. Ohne diese Ergänzung ist der Titel zwar korrekt, aber niemand erfährt davon.

Sind Emoji im Titel ein Verstoß?

Nicht automatisch, aber sie sind riskant. Screenreader lesen Emoji als beschreibenden Namen vor. Aus einem Feuer-Symbol wird „Feuer“ mitten im Satz. Wenn das Emoji Information vermittelt, gehört sie zusätzlich als Text hinein; wenn nicht, gehört es raus. Am Anfang des Titels ist es besonders ungünstig, weil es genau die Stelle belegt, an der das Thema stehen sollte.

Verwandte Themen

Gratis E-Book PDF, 37 Seiten HTML & Barrierefreiheit, WCAG & BFSG, GEO & SEO

Kostenloses E-Book

Das Praxishandbuch für sauberes, zugängliches Web

Alles rund um semantisches HTML, Barrierefreiheit, WCAG & BFSG, GEO und SEO — praxisnah und am echten Code. In mehreren Feedbackschleifen von Leserinnen und Lesern verbessert.

  • 3.000+ Downloads
  • 7. Auflage
  • 37 Seiten
  • PDF

Kein Spam. Abmeldung jederzeit mit einem Klick möglich.