Tooltips & Popover-API

Ein Tooltip ist ein kurzer, rein ergänzender Hinweis zu einem Bedienelement: über aria-describedby angebunden, per Maus wie per Tastatur erreichbar und mit Esc schließbar. Ein Popover ist etwas anderes – ein eigenständiger Layer, den der Browser über das popover-Attribut selbst verwaltet und der im Gegensatz zum Tooltip auch Bedienelemente enthalten darf.

Die beiden werden ständig verwechselt, und die Folgen sind immer dieselben: Hinweise, die nur die Maus kennt. Wichtige Inhalte, die auf dem Handy nie erscheinen. Overlays, die den Fokus verschlucken. Dabei gibt es für beide Fälle heute saubere Wege – einer davon seit Kurzem sogar ohne eine Zeile JavaScript.

Das Wichtigste in Kürze

• Ein Tooltip beschreibt, er bedient nicht. Steht im Overlay etwas zum Anklicken, ist es kein Tooltip mehr.
• aria-describedby bindet an, role="tooltip" beschreibt nur die Art. Ohne die Anbindung liest kein Screenreader den Hinweis vor.
• WCAG 1.4.13 verlangt drei Dinge: ausblendbar per Esc, mit dem Zeiger erreichbar, beständig bis zum Verlassen.
• Das title-Attribut erfüllt keine davon. Auf Touch unsichtbar, per Tastatur meist unerreichbar, im Aussehen nicht beeinflussbar.
• popover erledigt Top-Layer, Esc und Klick daneben, liefert aber keine Rolle, keine Hover-Steuerung und – ohne Anchor Positioning – keine Position.
• Auf Touch gibt es kein Hover. Was per Zeiger erscheint, braucht dort eine Variante mit Klick: den Toggletip.

Vier Bauteile, die ständig verwechselt werden

Bevor es um Attribute geht, lohnt die Einordnung. Zwei Fragen reichen, um das richtige Bauteil zu finden:

1. Steht im Overlay etwas, das man anklicken kann? Ein Link, ein Knopf, ein Feld? Dann ist es kein Tooltip. Tooltips sind für Screenreader eine Beschreibung – sie werden am Stück vorgelesen, und Bedienelemente darin sind für Tastaturnutzende oft gar nicht erreichbar.
2. Muss der Rest der Seite währenddessen blockiert sein? Nur bei einer erzwungenen Entscheidung – „Bestellung wirklich stornieren?“ – ist das der Fall. Dann ist es ein modaler Dialog. Alles dazwischen ist ein Popover.

Bleibt noch der Toggletip: der kleine Bruder des Tooltips für alles, was auch auf dem Handy funktionieren muss. Er sieht aus wie ein Tooltip, öffnet aber per Klick und wird über eine Live-Region angesagt. Dazu unten mehr.

Der Tooltip: was hineingehört und was nicht

Ein Tooltip ist eine kurze, ergänzende Beschreibung – ein Satz, selten zwei. Alles, was zum Verständnis nötig ist, gehört in den sichtbaren Text. Angebunden wird der Hinweis über aria-describedby:

<button aria-describedby="tip-export">Exportieren</button>
<span role="tooltip" id="tip-export" hidden>Als CSV-Datei herunterladen</span>

Drei Details entscheiden hier über die Barrierefreiheit:

• aria-describedby ist die Anbindung. Fehlt sie, existiert der Hinweis für Screenreader nicht – gleichgültig, wie schön die Sprechblase aussieht.
• role="tooltip" beschreibt nur die Art des Elements. Es erzeugt keine Beziehung und keine Ansage; es schadet aber nichts und hilft beim Verstehen des Markups.
• Der Auslöser braucht selbst einen Namen. Ein Icon-Button ohne Beschriftung bekommt zusätzlich ein aria-label – der Tooltip ersetzt es nicht. Details dazu in Icons & SVGs.

aria-describedby oder aria-labelledby?

Die Verwechslung ist häufig, der Unterschied aber klar:

Ein Tooltip beschreibt ein Element, das bereits einen Namen hat. aria-labelledby würde diesen Namen überschreiben – und dann heißt der Knopf plötzlich „Als CSV-Datei herunterladen“ statt „Exportieren“. Das ist selten gewollt.

Warum title als Tooltip nicht reicht

Das native title-Attribut sieht nach der bequemen Lösung aus. Es ist aber die unzuverlässigste Variante, die HTML zu bieten hat:

Ich würd mir das title-Attribut deshalb gar nicht erst angewöhnen. Als Notbehelf für eine Randinformation mag es durchgehen – für alles, was jemand wirklich lesen können muss, ist es der falsche Ort.

Randnotiz – die eine Ausnahme. Bei <iframe> ist title kein Tooltip, sondern der zugängliche Name des eingebetteten Bereichs: <iframe title="Anfahrtskarte">. Dort ist das Attribut nicht nur erlaubt, sondern Pflicht. Gleiches gilt für <abbr title="…">, wo es die Auflösung einer Abkürzung trägt.

WCAG 1.4.13: drei Bedingungen, eine fällt ständig durch

Erfolgskriterium 1.4.13 „Inhalt bei Hover oder Fokus“ (Stufe AA) gilt für jeden Inhalt, der durch Zeiger oder Tastaturfokus zusätzlich eingeblendet wird – Tooltips, Vorschaukarten, aufklappende Untermenüs. Drei Bedingungen müssen erfüllt sein.

Ausblendbar. Esc muss den Tooltip schließen, ohne dass Zeiger oder Fokus sich bewegen. Das klingt banal, ist aber der Punkt, an dem eine reine CSS-Lösung nicht mehr ausreicht – für Esc braucht es eine Handvoll JavaScript:

document.addEventListener('keydown', (e) => {
  if (e.key !== 'Escape') return;
  document.querySelectorAll('[data-tooltip-offen]').forEach((el) => {
    el.removeAttribute('data-tooltip-offen');
  });
});

Bewegbar. Der Zeiger muss den Tooltip erreichen können, ohne dass dieser verschwindet – etwa um einen langen Hinweis zu markieren oder ihn bei starker Vergrößerung zu lesen. Genau hier steckt der häufigste Fehler: Wer den optischen Abstand zwischen Auslöser und Sprechblase als Außenabstand setzt, reißt eine Lücke auf. Verlässt die Maus den Auslöser, ist der Tooltip weg, bevor sie ihn erreicht. Die Lösung ist der gleiche Abstand als Innenabstand – eine unsichtbare Brücke:

/* Falsch: der Abstand ist eine Lücke ohne Hover */
.tooltip { margin-bottom: 8px; }

/* Richtig: der Abstand gehört zum Tooltip und trägt den Hover */
.tooltip-huelle { padding-bottom: 8px; }
.tooltip { background: #1b1f27; color: #fff; border-radius: 8px; padding: 8px 10px; }

Beständig. Der Hinweis bleibt sichtbar, bis Hover oder Fokus enden, der Inhalt ungültig wird oder man ihn schließt. Ein Tooltip, der nach zwei Sekunden von selbst verschwindet, verstößt gegen dieses Kriterium – langsame Leser und Menschen mit motorischen Einschränkungen kommen dabei nicht mit.

Die Popover-API

Für alles, was aufklappt und mehr als einen Satz enthält, gibt es seit Kurzem eine native Lösung: das popover-Attribut. Der Browser übernimmt dabei vier Aufgaben, die man früher selbst schreiben musste.

<button popovertarget="konto">Mein Konto</button>

<div id="konto" popover>
  <p>Angemeldet als j.sommer</p>
  <a href="/profil.html">Profil</a>
  <button type="button">Abmelden</button>
</div>

Was der Browser hier von allein erledigt:

• Top-Layer. Das Popover liegt über allem anderen – kein z-index-Wettrennen, kein Abschneiden durch overflow: hidden eines Elternelements.
• Light-Dismiss. Ein Klick daneben schließt es und gibt den Fokus an den Auslöser zurück.
• Esc. Ebenfalls eingebaut, mit derselben Fokusrückgabe.
• Beziehung für assistive Technik. popovertarget verknüpft Auslöser und Panel, vergleichbar mit aria-controls plus aria-expanded – ohne dass du beides selbst pflegen musst.

Die drei Popover-Arten

popover="hint" ist der jüngste Zuwachs und genau für Tooltips gedacht: Es verdrängt offene auto-Popover nicht, wenn also ein Menü geöffnet ist, verschwindet es nicht beim Anzeigen eines Hinweises. Die Unterstützung ist Mitte 2026 aber noch nicht flächendeckend – für Hover-Hinweise fährst du derzeit mit CSS :hover/:focus-visible zuverlässiger.

Steuern lässt sich das Ganze auch feiner, über popovertargetaction="show", "hide" oder "toggle" sowie die Methoden showPopover(), hidePopover() und togglePopover(). Zum Gestalten gibt es die Pseudoklasse :popover-open und – bei modalen Varianten – ::backdrop.

Was der Browser dir nicht abnimmt

Drei Dinge musst du weiterhin selbst regeln:

1. Die Rolle. Das popover-Attribut setzt keine implizite ARIA-Rolle. Ein Menü braucht weiterhin die passende Auszeichnung – siehe Menüs & Dropdowns und Rollen, States & Properties.
2. Hover und Fokus. Die API kennt nur „öffnen“ und „schließen“, keine Zeigerereignisse. Für einen Tooltip, der bei Hover erscheint, brauchst du weiterhin CSS oder ein paar Zeilen JavaScript.
3. Die Position. Ohne weiteres Zutun erscheint das Popover mittig im Viewport. Dass es unter seinem Auslöser klebt, ist Aufgabe von CSS.

Positionieren mit CSS Anchor Positioning

Genau dafür gibt es seit 2026 den passenden Gegenpart. Anchor Positioning verankert ein Element an einem anderen – ohne Messcode, ohne Bibliothek:

.ausloeser { anchor-name: --konto-knopf; }

#konto {
  position-anchor: --konto-knopf;
  position-area: block-end span-inline-end;   /* darunter, rechtsbündig */
  margin-block-start: 0.5rem;
  position-try-fallbacks: flip-block, flip-inline;  /* kippt am Rand um */
}

position-try-fallbacks ist dabei der Teil, für den man früher eine Bibliothek gebraucht hat: Passt das Panel unten nicht mehr auf den Bildschirm, klappt der Browser es nach oben. Die Kernfunktionen sind in aktuellen Chrome-, Firefox- und Safari-Versionen verfügbar; für ältere Browser genügt als Rückfall eine schlichte absolute Positionierung, denn unpositionierte Popover sind sichtbar, nur eben mittig.

Popover oder Dialog?

Die Faustregel: Ein Popover ist nicht modal – der Rest der Seite bleibt bedienbar, und das ist meistens auch richtig so. Erst wenn eine Entscheidung fallen muss, bevor es weitergeht, greifst du zum <dialog>. Übrigens kennt auch <dialog> das popover-Attribut – dann verhält es sich nicht-modal und profitiert trotzdem vom Top-Layer.

Touch: das vergessene Drittel

Auf Touchgeräten gibt es kein Hover. Ein reiner Tooltip ist dort schlicht nicht erreichbar – und weil ein wachsender Teil der Zugriffe vom Handy kommt, ist das kein Randfall. Die Antwort darauf ist der Toggletip: derselbe Hinweis, aber per Klick geöffnet und über eine Live-Region angesagt.

<button type="button" aria-expanded="false" aria-controls="hinweis-versand">
  <span class="visually-hidden">Erklärung zum Versandpreis</span>
  <svg aria-hidden="true" focusable="false" width="16" height="16"><!-- Info-Symbol --></svg>
</button>

<div id="hinweis-versand" role="status" hidden>
  Der Preis gilt inklusive Versand innerhalb Deutschlands.
</div>

Der Unterschied zum Tooltip steckt in der Ansage: Der Text wird beim Öffnen neu in die Live-Region geschrieben und dadurch vorgelesen – er hängt nicht als Beschreibung am Knopf. Und weil der Auslöser ein echter Button mit aria-expanded ist, funktioniert er per Maus, Tastatur und Touch gleichermaßen. Achte dabei auf die Zielgröße von mindestens 24 × 24 CSS-Pixeln (2.5.8); Info-Symbole geraten gern zu klein.

Häufige Fehler

• Tooltip nur bei Hover – für Tastatur und Touch damit unerreichbar.
• Wichtige Inhalte im Tooltip statt im sichtbaren Text. Was nur bei Hover erscheint, existiert für viele nicht.
• Bedienelemente im Tooltip. Links und Knöpfe darin sind per Tastatur oft nicht erreichbar – das ist dann ein Popover.
• Kein Esc zum Schließen, oder Esc nur auf dem Auslöser statt global.
• Der Abstand als margin statt als padding – die Lücke, an der Bedingung 2 scheitert.
• aria-labelledby statt aria-describedby – der Tooltip überschreibt dann den Namen des Bedienelements.
• title als vollwertiger Tooltip.
• Popover für eine erzwungene Entscheidung, wo ein modaler Dialog hingehört.

In fünf Minuten selbst prüfen

1. Tab-Taste bis zum Auslöser. Erscheint der Hinweis auch ohne Maus?
2. Esc drücken, während der Zeiger auf dem Auslöser steht. Schließt er sich?
3. Mit der Maus in den Tooltip fahren. Bleibt er stehen?
4. Warten. Verschwindet er nach ein paar Sekunden von selbst? Dann ist Bedingung 3 verletzt.
5. Auf 200 % zoomen. Liegt die Sprechblase noch im sichtbaren Bereich?
6. Am Handy antippen. Kommt der Inhalt dort überhaupt an?

Mehr zum systematischen Vorgehen steht unter Selbst testen.

Häufige Fragen

Ist die Popover-API schon einsetzbar?

Ja. popover="auto" und popover="manual" sind in allen aktuellen Browsern verfügbar. Jünger und noch nicht überall vorhanden sind popover="hint" und Teile des Anchor Positioning – beides lässt sich mit einfachen Rückfällen absichern.

Brauche ich mit der Popover-API noch ARIA?

Für Top-Layer, Esc und Light-Dismiss nicht mehr. Für die Bedeutung des Inhalts schon: Ein Menü braucht seine Rolle, eine Statusmeldung ihre Live-Region. Das Attribut regelt das Verhalten, nicht die Semantik.

Wie sage ich einen Tooltip korrekt an?

Über aria-describedby am Auslöser, das auf die ID des Tooltip-Elements zeigt. Der Hinweis wird dann nach Name und Rolle als ergänzende Beschreibung vorgelesen.

Darf ein Tooltip einen Link enthalten?

Nein. Sobald etwas im Overlay bedienbar ist, brauchst du ein Popover – im Tooltip wäre der Link für Tastaturnutzende unerreichbar und würde als Teil der Beschreibung vorgelesen.

Was ist der Unterschied zwischen Tooltip und Toggletip?

Der Tooltip beschreibt ein vorhandenes Bedienelement und erscheint bei Hover oder Fokus. Der Toggletip öffnet per Klick, enthält eigenständige Zusatzinfo und wird über eine Live-Region angesagt. Auf Touchgeräten funktioniert nur der Toggletip.

Reicht CSS allein für einen barrierefreien Tooltip?

Fast. Hover und Fokus lassen sich mit :hover und :focus-visible abbilden, die Hover-Brücke mit padding. Nur für „Esc schließt“ braucht es die wenigen Zeilen JavaScript von oben – ohne die scheitert Bedingung 1 aus WCAG 1.4.13.

Gilt 1.4.13 auch für aufklappende Navigationen?

Ja. Jedes Untermenü, das bei Hover erscheint, fällt darunter – Esc muss schließen, der Weg mit der Maus ins Panel darf nicht abreißen. Wie das aussieht, zeigt Mega-Menüs.

Fazit

Tooltips sind kurze Ergänzungen: über aria-describedby angebunden, per Hover und Fokus erreichbar, mit Esc schließbar und durch einen Innenabstand mit dem Auslöser verbunden. Sobald Bedienelemente ins Spiel kommen, ist die native Popover-API die schlanke Wahl – sie übernimmt Top-Layer, Esc und Light-Dismiss, überlässt dir aber Rolle, Hover und Position. Und sobald der Hintergrund gesperrt werden muss, ist es weder das eine noch das andere, sondern der modale Dialog. Für die Auswahl gilt wie überall die erste Regel von ARIA: erst das native Bauteil, dann Attribute.

• Verwendung der Popover-API – MDN Web Docs
• Tooltip Pattern – WAI-ARIA Authoring Practices Guide (W3C)