Tooltips und Toggletips barrierefrei gestalten
Tooltips sind ein alltägliches UI-Pattern – ein kleines Hilfetextfeld, das erscheint, wenn der Nutzer mit der Maus über ein Element fährt oder es per Tastatur fokussiert. So einfach das Konzept klingt, so viele Barrierefreiheitsfallen birgt es: Tooltips, die nur auf Hover reagieren, sind für Tastaturnutzer unsichtbar. Tooltips, die Informationen enthalten, die für das Verständnis notwendig sind, schließen mobile Nutzer aus. Und Tooltips, die bei der kleinsten Mausbewegung verschwinden, sind für Menschen mit Tremor oder motorischen Einschränkungen nicht nutzbar. WCAG 2.1 hat mit Kriterium 1.4.13 erstmals klare Anforderungen an Content on Hover or Focus definiert.
WCAG 1.4.13: Die drei Anforderungen an Content on Hover
WCAG 1.4.13 „Content on Hover or Focus" (Level AA) definiert drei Anforderungen für Inhalte, die bei Hover oder Fokus zusätzlich erscheinen: Erstens „Dismissable" – der Nutzer muss den zusätzlichen Inhalt schließen können, ohne den Trigger zu verlassen. In der Praxis: Die Escape-Taste schließt den Tooltip. Ausnahme: Der Tooltip überdeckt keinen anderen Inhalt und kommuniziert keinen Fehler. Zweitens „Hoverable" – wenn der Tooltip durch Maus-Hover ausgelöst wird, muss der Nutzer mit der Maus in den Tooltip wandern können, ohne dass er verschwindet. Das ist essentiell für Bildschirmlupen-Nutzer, die den Tooltip heranzoomen müssen. Drittens „Persistent" – der Tooltip muss sichtbar bleiben, bis der Nutzer den Hover/Fokus aktiv beendet, die Escape-Taste drückt oder der Inhalt nicht mehr relevant ist (z.B. bei einer Aktualisierung). Ein Tooltip, der nach 3 Sekunden automatisch verschwindet, verletzt dieses Kriterium. Diese drei Regeln gelten nur für zusätzlichen Inhalt, der durch die Webseite gesteuert wird – native Browser-Tooltips via `title`-Attribut sind ausgenommen.
Tooltip vs. Toggletip: Wann welches Pattern?
Ein Tooltip erscheint automatisch bei Hover oder Fokus und verschwindet beim Verlassen. Er eignet sich für ergänzende, nicht-essentielle Informationen – etwa eine Erklärung eines Icons oder ein Kurz-Hinweis. Technisch wird er mit `aria-describedby` an das auslösende Element gebunden und erscheint als `role="tooltip"`. Ein Toggletip hingegen wird durch einen expliziten Klick oder Tastendruck (Enter/Leertaste) ausgelöst und bleibt sichtbar, bis er aktiv geschlossen wird. Er eignet sich für wichtigere Informationen, die der Nutzer bewusst abrufen möchte. Technisch ist er ein Button mit `aria-expanded`, der ein Popup steuert. Die Faustregel: Wenn die Information für das Verständnis der Seite wichtig ist, verwenden Sie keinen Tooltip – machen Sie die Information direkt sichtbar oder nutzen Sie ein Toggletip. Wenn die Information rein ergänzend ist und die Seite auch ohne sie funktioniert, ist ein Tooltip angemessen. Auf Touch-Geräten gibt es keinen Hover – Tooltips, die nur auf Hover reagieren, sind dort unsichtbar. Toggletips funktionieren auf allen Eingabegeräten.
Technische Implementierung barrierefreier Tooltips
Ein barrierefreier Tooltip benötigt folgendes Markup: Das auslösende Element (z.B. ein Button oder ein Info-Icon) erhält `aria-describedby` mit der ID des Tooltip-Elements. Der Tooltip selbst hat `role="tooltip"` und ist standardmäßig mit `hidden` oder CSS verborgen. Bei Fokus oder Hover wird der Tooltip sichtbar. CSS-Positionierung erfolgt mit `position: absolute` relativ zum Trigger – achten Sie darauf, dass der Tooltip nicht am Viewport-Rand abgeschnitten wird (Flip-Logik). Der Tooltip muss interaktiv sein: Der Nutzer muss mit der Maus hineinfahren können, ohne dass er verschwindet. Implementieren Sie eine kurze Verzögerung (100-200ms) beim Verlassen des Triggers, bevor der Tooltip schließt – so kann die Maus zum Tooltip wandern. Escape-Taste schließt den Tooltip. Verwenden Sie CSS `pointer-events: auto` auf dem Tooltip, damit er hover-fähig ist. Für die Positionierung empfehlen sich Bibliotheken wie Floating UI oder Popper.js, die Viewport-Kollisionserkennung und Flip-Logik mitbringen. Vermeiden Sie das `title`-Attribut als Tooltip-Ersatz – es ist nicht tastaturzugänglich, nicht stylebar und wird von Screenreadern inkonsistent behandelt.
Typische Fehler und Anti-Patterns
Der häufigste Fehler: Tooltips, die nur auf `:hover` in CSS reagieren und keine Tastaturunterstützung haben. Lösung: `:focus` und `:focus-within` ergänzen oder JavaScript für konsistentes Verhalten verwenden. Tooltips auf nicht-fokussierbaren Elementen (Spans, Divs) – Screenreader-Nutzer können diese nie erreichen. Lösung: Verwenden Sie `
Mobile und Touch-Geräte
Auf Touch-Geräten existiert kein Hover-Zustand, was Tooltips grundsätzlich problematisch macht. Lösungen: Verwenden Sie Toggletips statt Tooltips – ein Tap auf das Info-Icon öffnet den Hinweis, ein zweiter Tap oder Tap außerhalb schließt ihn. Implementieren Sie eine Long-Press-Geste als Hover-Äquivalent – aber bieten Sie immer auch einen Tap als Alternative. Prüfen Sie, ob die Information nicht besser direkt sichtbar sein sollte – auf mobilen Geräten haben Sie weniger Platz, aber die Informationsdichte sollte nicht auf Kosten der Zugänglichkeit reduziert werden. Wenn Sie Touch-Events verwenden, beachten Sie `touch-action: manipulation` und verhindern Sie Doppelklick-Zoom-Probleme. Ein Tap auf den Tooltip-Trigger sollte nicht gleichzeitig den Tooltip öffnen und eine Navigation auslösen. Positionieren Sie Tooltips auf mobilen Geräten so, dass sie den Trigger nicht verdecken und nicht am Bildschirmrand abgeschnitten werden. Testen Sie mit echten Touch-Geräten, nicht nur mit den Chrome DevTools im Touch-Modus – das Verhalten unterscheidet sich.
Wie steht deine Webseite in diesem Punkt da?
Kostenloser Scan gegen 15 WCAG-2.1-AA-Kriterien – inkl. Tooltip & Barrierefreiheit-Check.
Jetzt Webseite prüfen →