WCAG 1.4.13: Inhalt bei Hover oder Fokus

WCAG 1.4.13 verlangt, dass zusätzliche Inhalte, die beim Überfahren mit dem Zeiger oder beim Tastaturfokus erscheinen, drei Bedingungen erfüllen: Sie lassen sich schließen, ohne dass sich Zeiger oder Fokus bewegen, sie verschwinden nicht, wenn der Zeiger auf sie wandert, und sie bleiben stehen, bis der Nutzer sie beendet. Gemeint sind Tooltips, Untermenüs, Vorschaukarten und Erklärblasen. Nicht gemeint ist das native title-Attribut, das der Browser selbst steuert.

(Englisch: Content on Hover or Focus. Der BIK-BITV-Test nennt den Prüfschritt „Eingeblendete Inhalte bedienbar“.)

Das Wichtigste in Kürze

• Drei Bedingungen, alle drei müssen erfüllt sein: schließbar (dismissible), überfahrbar (hoverable), beständig (persistent).
• Schließbar heißt: ohne Zeiger- oder Fokusbewegung. Esc ist der erwartete Weg; auch das erneute Aktivieren des auslösenden Elements wird akzeptiert.
• Überfahrbar gilt nur für die Zeigereingabe. Bei Tastaturfokus wird nicht verlangt, dass man mit der Maus auf die Einblendung fahren kann.
• Beständig heißt: kein Timeout. Ein Tooltip, der sich nach drei Sekunden selbst einzieht, fällt durch (auch wenn die Zeit „eigentlich reicht“).
• Der häufigste technische Auslöser ist eine Lücke zwischen Auslöser und Blase: Der Zeiger verlässt dazwischen den Hover-Bereich, und der Inhalt klappt weg.
• Ausgenommen ist, was der Browser steuert (das native title-Attribut). Als Tooltip taugt es aus anderen Gründen trotzdem nicht.
• Zwei weitere Ausnahmen betreffen die Schließbarkeit: Fehlermeldungen und Einblendungen, die keinen anderen Inhalt verdecken, müssen nicht wegklickbar sein.
• Häufigste Fundstellen: Icon-Tooltips in Tabellen, Mega-Menüs mit Abstand zum Menüpunkt, Nutzerkarten in Kommentaren, Erklärblasen an Formularfeldern.

Was muss ein Tooltip können?

Das Kriterium kam 2018 mit WCAG 2.1 dazu. Es zielt auf eine Situation, die man am eigenen Bildschirm selten nachvollziehen kann: eine Einblendung, die genau das verdeckt, was jemand gerade lesen wollte und die sich nicht wegbekommen lässt.

Schließbar. Es muss einen Weg geben, den eingeblendeten Inhalt zu beenden, ohne Zeiger oder Fokus zu bewegen. Der erwartete Weg ist Esc; der Prüfschritt akzeptiert auch das erneute Aktivieren des auslösenden Elements. Der Grund ist handfest: Wer den Bildschirm stark vergrößert, sieht einen kleinen Ausschnitt. Eine Blase, die 200 Pixel breit ist, deckt darin womöglich den halben Satz ab, um den es geht. Den Zeiger wegzubewegen ist keine Lösung, wenn der Zeiger die Leseposition markiert.

Zwei Ausnahmen gelten hier: Der Inhalt muss nicht schließbar sein, wenn er eine Eingabefehlermeldung übermittelt oder wenn er keinen anderen Inhalt verdeckt oder ersetzt. Eine Blase, die im freien Randbereich erscheint, ist unkritisch.

Überfahrbar. Erscheint der Inhalt beim Überfahren, muss der Zeiger vom Auslöser auf den Inhalt wandern dürfen, ohne dass er verschwindet. Sonst kommt man nie an den Text heran und schon gar nicht an einen Link darin. Diese Bedingung gilt nur für die Zeigereingabe; bei Tastaturfokus verlangt das Kriterium sie nicht.

Beständig. Der Inhalt bleibt sichtbar, bis der Nutzer den Auslöser verlässt, ihn aktiv schließt oder die Information hinfällig wird. Ein Timeout ist damit ausgeschlossen. Wer langsamer liest oder erst zur Blase navigieren muss, braucht die Zeit und ein Timer weiß nicht, wie lange das dauert.

Was ausgenommen ist: Einblendungen, die der Browser selbst erzeugt. Das native title-Attribut fällt darunter, weil du sein Verhalten nicht steuerst. Damit ist es formal kein Verstoß. Als Tooltip bleibt es trotzdem ungeeignet: Es erscheint auf Touchgeräten gar nicht, wird von manchen Screenreadern übersprungen und verschwindet in Windows nach wenigen Sekunden von selbst. Mehr dazu unter Tooltips & Popover-API.

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

Wen betrifft es besonders?

Menschen, die den Bildschirm stark vergrößern, sind der Grund, warum es dieses Kriterium gibt. Bei 400 % Zoom ist der sichtbare Ausschnitt so klein, dass eine Erklärblase leicht den gesamten Kontext verdeckt. Und weil sie den Zeiger als Leseanker benutzen, ist „einfach wegfahren“ keine Option. Dann verlieren sie die Stelle.

Menschen mit Tremor oder unruhiger Zeigerführung kämpfen mit der zweiten Bedingung. Wenn zwischen Auslöser und Blase eine Lücke von zehn Pixeln liegt, flackert der Inhalt bei jeder Handbewegung. Den Zeiger von einem kleinen Icon in eine kleine Blase zu führen, ohne unterwegs den Kontakt zu verlieren, ist eine Präzisionsaufgabe.

Menschen, die mehr Zeit zum Lesen brauchen (bei Legasthenie, nach einem Schlaganfall, in einer Fremdsprache) scheitern an der dritten. Drei Sekunden reichen für ein Wort, nicht für einen erklärenden Satz.

Und schließlich Screenreader-Nutzer: Für sie ist es zusätzlich wichtig, dass die Einblendung überhaupt per Tastatur erscheint und über aria-describedby mit dem Auslöser verbunden ist. Das prüft formal 2.1.1 beziehungsweise 4.1.2 (in der Praxis fällt beides zusammen).

Richtig & falsch im Code

Die zweite Bedingung scheitert fast immer an derselben Stelle: einem Abstand, der den Hover-Bereich unterbricht.

/* Falsch: 12 Pixel Luft zwischen Auslöser und Blase.
   Der Zeiger verlässt dazwischen beide Elemente. Der Tooltip klappt weg. */
.tooltip {
  position: absolute;
  top: calc(100% + 12px);
}

/* Richtig: die Blase schließt lückenlos an, der Abstand
   entsteht durch Innenabstand statt durch Versatz. */
.tooltip {
  position: absolute;
  top: 100%;
  padding-top: 12px;
  background-clip: content-box; /* Optik bleibt gleich */
}

Wer die Blase aus optischen Gründen wirklich abgesetzt braucht, überbrückt die Lücke mit einem unsichtbaren Element:

/* Alternative: eine unsichtbare Brücke hält den Hover-Kontakt */
.tooltip::before {
  content: '';
  position: absolute;
  inset-block-start: -12px;
  inset-inline: 0;
  block-size: 12px;
}

Beim Schließen kommt es darauf an, dass der Fokus stehen bleibt. Ein blur() auf dem Auslöser wäre genau der Fehler, den das Kriterium verhindern will:

// Falsch: schließt zwar, verschiebt aber den Fokus
document.addEventListener('keydown', (e) => {
  if (e.key === 'Escape') {
    tooltip.hidden = true;
    ausloeser.blur(); // Fokus weg. Genau das verbietet 1.4.13
  }
});

// Richtig: Esc schließt, der Fokus bleibt auf dem Auslöser
document.addEventListener('keydown', (e) => {
  if (e.key !== 'Escape') return;
  const offen = document.querySelector('.tooltip:not([hidden])');
  if (!offen) return;
  offen.hidden = true;
  // kein blur(), kein focus() woanders hin
});

Ein Timeout ist der dritte Klassiker. Wenn du ihn im Code findest, ist er der Befund. Ersatzlos streichen:

// Falsch: der Tooltip zieht sich nach drei Sekunden selbst ein
zeigeTooltip();
setTimeout(versteckeTooltip, 3000);

// Richtig: er bleibt, bis Hover/Fokus endet oder der Nutzer schließt
zeigeTooltip();

Die native Popover-API nimmt einem den Großteil der Arbeit ab. Esc und Klick-außerhalb sind dort eingebaut, und die Einblendung liegt automatisch in der obersten Ebene:

<!-- Richtig: Popover-API, mit Esc-Verhalten ohne eigenes JavaScript -->
<button type="button" popovertarget="erklaerung-bbg"
        aria-describedby="erklaerung-bbg">
  Beitragsbemessungsgrenze
</button>
<div id="erklaerung-bbg" popover="auto" role="tooltip">
  Höchstbetrag des Einkommens, bis zu dem Beiträge erhoben werden.
</div>

Für Navigations-Flyouts gilt dasselbe Regelwerk. Dort ist die Lücke zwischen Menüpunkt und Untermenü der Standardfehler. Muster dafür stehen unter Mega-Menüs und Menüs & Dropdowns.

So testest du es

1. Alle Einblendungen sammeln. Tooltips an Icons, Untermenüs, Vorschaukarten bei Links, Erklärblasen an Formularfeldern, Nutzerkarten bei Namen, Diagramm-Tooltips.
2. Prüfung 1 (schließbar): Einblendung auslösen und Esc drücken, ohne Maus und Fokus zu bewegen. Verschwindet sie? Alternativ: Auslöser erneut aktivieren.
3. Prüfung 2 (überfahrbar): Mit dem Zeiger langsam vom Auslöser auf die Blase fahren. Bleibt sie stehen? Genau in der Mitte der Strecke fällt es durch, wenn eine Lücke existiert.
4. Prüfung 3 (beständig): Einblendung auslösen und zwanzig Sekunden nichts tun. Verschwindet sie von selbst, ist das der Befund.
5. Alles mit der Tastatur wiederholen. Auslöser mit Tab fokussieren: Erscheint derselbe Inhalt? Bleibt er? Lässt er sich mit Esc schließen? Für die Tastatur wird das Überfahren nicht verlangt.
6. Bei 400 % Zoom gegenprüfen. Erst dort zeigt sich, ob die Einblendung Inhalt verdeckt und damit, ob die Ausnahme „verdeckt nichts“ überhaupt greift.
7. Auf dem Touchgerät testen. Es gibt kein Überfahren: Erscheint der Inhalt beim Antippen, und lässt er sich wieder schließen? Ein Tooltip, der auf dem Handy gar nicht erscheint, ist eine Informationslücke.

Häufiger Fehler in der Praxis

Der häufigste Fund ist die Lücke im CSS. Ein top: calc(100% + 8px) sieht gut aus und verletzt die zweite Bedingung. Der Zeiger fällt beim Übergang zwischen Auslöser und Blase in ein Loch. Mit einer ruhigen Hand und einer schnellen Bewegung merkt man es kaum; mit Tremor oder bei starkem Zoom ist die Blase unerreichbar. Ich hab mir angewöhnt, bei jeder neuen Tooltip-Komponente als Allererstes langsam vom Auslöser zur Blase zu fahren. Das dauert drei Sekunden und findet den Fehler zuverlässig.

Der zweite ist das Timeout aus der Bibliothek. Viele Tooltip-Bibliotheken bringen eine hideDelay- oder duration-Option mit, und die Voreinstellung schließt nach ein paar Sekunden. Das ist keine bewusste Entscheidung, sondern die Standardkonfiguration. Trotzdem ist es ein Verstoß gegen die dritte Bedingung.

Der dritte ist der Tooltip, den nur die Maus kennt. Er hängt an mouseenter, nicht an focus. Mit der Tastatur passiert nichts, auf dem Touchgerät auch nicht. Formal ist das ein Verstoß gegen 2.1.1 Tastatur. Im Prüfbericht tauchen dann beide Nummern auf, weil der Inhalt für einen Teil der Nutzer schlicht nicht existiert.

Und noch ein Muster, das ich immer wieder sehe: Wichtige Information nur im Tooltip. Der Preis ohne Mehrwertsteuer, die Lieferzeit, der Hinweis auf die Mindestlaufzeit. Alles ist versteckt hinter einem Fragezeichen-Icon. Selbst wenn die Einblendung alle drei Bedingungen erfüllt: Was zur Entscheidung gehört, gehört auf die Seite. Ein Tooltip ist für Ergänzungen da, nicht für Bedingungen.

Häufige Fragen

Muss ein Tooltip mit dem title-Attribut die drei Bedingungen erfüllen?

Nein. Einblendungen, deren Erscheinen und Verhalten der Browser bestimmt, sind ausdrücklich ausgenommen. Dazu gehört das native title-Attribut. Als Tooltip-Lösung taugt es trotzdem nicht: Auf Touchgeräten erscheint es gar nicht, manche Screenreader lesen es nicht vor, und in Windows verschwindet es nach wenigen Sekunden von selbst.

Gilt „überfahrbar“ auch, wenn die Einblendung per Tastatur ausgelöst wurde?

Nein. Der Prüfschritt hält fest, dass für den Tastaturfokus nicht verlangt wird, den Mauszeiger auf den Inhalt bewegen zu können. Die zweite Bedingung betrifft nur Einblendungen, die durch Überfahren mit dem Zeiger erscheinen. Schließbarkeit und Beständigkeit gelten dagegen in beiden Fällen.

Reicht es, wenn der Tooltip beim Wegbewegen der Maus verschwindet?

Nein, das ist genau der Fall, den die erste Bedingung ausschließt. Verlangt wird ein Weg, die Einblendung zu beenden, ohne Zeiger oder Fokus zu bewegen (in der Regel Esc). Die Ausnahme greift nur, wenn die Einblendung keinen anderen Inhalt verdeckt oder wenn sie eine Eingabefehlermeldung übermittelt.

Fällt ein Untermenü im Mega-Menü unter 1.4.13?

Ja. Alles, was bei Hover oder Fokus zusätzlich erscheint, fällt darunter. Das gilt auch für Navigations-Flyouts. Sie müssen sich mit Esc schließen lassen, beim Übergang vom Menüpunkt zum Untermenü stehen bleiben und dürfen keinen Timer haben. Die Lücke zwischen Menüpunkt und Untermenü ist dort der häufigste Fehler.

Darf ein Tooltip überhaupt Links enthalten?

Ja, und die zweite Bedingung existiert genau dafür: Der Nutzer muss die Blase mit dem Zeiger erreichen können, um etwas darin anzuklicken. Sobald interaktive Elemente darin liegen, ist es allerdings kein Tooltip mehr im engeren Sinn, sondern ein Popover. Dann gehört auch die Tastaturnavigation hinein. Muster dafür stehen unter Tooltips & Popover-API.

Verwandte Themen

• Tooltips & Popover-API: das vollständige Umsetzungsmuster
• Mega-Menüs: Flyouts nach denselben drei Regeln
• 2.4.11 Fokus nicht verdeckt: die umgekehrte Verdeckungsfrage
• 2.1.1 Tastatur: warum ein Nur-Maus-Tooltip doppelt auffällt
• 1.4.10 Reflow: kleine Ausschnitte, in denen Einblendungen teuer werden