Tooltip

Definition: Ein Tooltip ist ein kleines, nicht-modales, flüchtiges UI-Element das beim Hovern über oder beim Fokussieren eines Interface-Elements erscheint und ergänzende kontextbezogene Information zu diesem Element anzeigt – typischerweise als kleine Hinweisbox mit Pfeil-Zeiger zum Auslöser-Element. Tooltips sind Werkzeuge des Progressive-Disclosure-Prinzips: sie halten die primäre Interface-Oberfläche übersichtlich und liefern ergänzende Informationen nur bei Bedarf. Tooltip-Auslöser: Hover (mouseenter; Desktop); Fokus/Tab (Tastaturnavigation; Accessibility-Pflicht); Long-Press (Mobile; 500ms Drücken als Hover-Ersatz; plattformabhängig). Tooltip-Typen: Beschreibungs-Tooltip (erklärt Funktion eines Icons ohne Label; z.B. «Bearbeiten» über Bleistift-Icon); Format-Tooltip (zeigt erwartetes Input-Format; z.B. «TT.MM.JJJJ» über Datumsfeld); Shortcut-Tooltip (zeigt Keyboard-Shortcut; z.B. «Speichern (Strg+S)»); Definition-Tooltip (erklärt Fachbegriff oder Abkürzung); Kontext-Tooltip (zeigt Preview oder zusätzliche Daten; z.B. User-Card beim Hover über @Username). Tooltip vs. Popover: Tooltip = nur Text; kein Fokus; nur durch Hover/Focus; auto-dismissed; keine interaktiven Elemente; Popover = kann Rich Content enthalten; kann Fokus erhalten; Keyboard-Navigation innerhalb; manuell geschlossen; HTML <popover>-Attribut (HTML Living Standard 2023; Chrome 114+). Tooltip vs. title-Attribut: HTML-title erscheint nach 1+ Sekunde Hover; nicht zugänglich über Touch; kein Styling möglich; Screen-Reader-Verhalten inkonsistent; kein Ersatz für gutes Tooltip-Design.

Erläuterung

Das Tooltip-Pattern hat seinen Ursprung in frühen grafischen Benutzeroberflächen: Alan Kay (Xerox PARC; Palo Alto; CA; Smalltalk; Alto; «Computer Metaphors»; 1970er) und sein Team entwickelten kontextbezogene Hilfe als Interface-Konzept; Tooltips als spezifisches UI-Pattern wurden in Macintosh System 7 (Apple; 1991) als «Balloon Help» eingeführt – schwebende Sprech-Blasen die bei Hover Hilfe-Informationen zeigten; das System war jedoch zu aufdringlich und wurde in Mac OS X durch dezentere Tooltips ersetzt. Microsoft Windows 95 (1995) etablierte das moderne Tooltip-Format das bis heute Standard ist: kleines Rechteck; gelber/beiger Hintergrund; schwarzer Text; kurze Verzögerung; automatisches Ausblenden; die Windows-95-Taskbar nutzte Tooltips um Icon-Namen anzuzeigen; dieses Pattern wurde web-adaptiert. Jakob Nielsen (Nielsen Norman Group; Fremont; CA) und Kate Moran (NNGroup; «Tooltip Guidelines», nngroup.com; 2015; aktualisiert 2021) definierten die Grundregeln für effektive Tooltips: Tooltips sollen ergänzende Information liefern; niemals kritische Information die zur Aufgabenerledigung notwendig ist; das Interface sollte ohne Tooltip vollständig verständlich sein; Tooltips sind «optional extra»; Nielsen's «recognition over recall» Heuristik impliziert dass häufig benötigte Informationen sichtbar sein sollten nicht versteckt in Tooltips. W3C WCAG 2.1 führte 2018 die spezifische Anforderung WCAG 1.4.13 Content on Hover or Focus (Level AA) für Tooltips ein: wenn Inhalte durch Hover oder Focus sichtbar werden müssen sie drei Anforderungen erfüllen: Hoverable (Nutzer kann den Mauszeiger vom Auslöser über den Tooltip bewegen ohne dass der Tooltip verschwindet; notwendig wenn Nutzer Text im Tooltip kopieren oder Links darin klicken möchten); Dismissable (Nutzer kann den Tooltip durch Escape-Taste schließen ohne Fokus zu bewegen; für Nutzer bei denen Tooltip wichtigen Inhalt verdeckt); Persistent (der Tooltip verschwindet nicht automatisch bis Nutzer Fokus oder Hover entfernt oder den Tooltip selbst schließt); Patrick Lauke (Web-Accessibility-Experte; Manchester; UK) und Adrian Roselli (adrroselli.com) dokumentierten ausführlich wie WCAG 1.4.13 in der Praxis implementiert werden muss und welche häufigen Implementierungen dagegen verstoßen. Floating UI (Modulares Positioning-Library; npm; @floating-ui/dom; 2021; successor to Popper.js von Thibault Courouble 2015; floating-ui.com) löste das technische Problem der Tooltip-Positionierung: Tooltips müssen dynamisch positioniert werden da sie am Viewport-Rand abgeschnitten werden können; Floating-UI berechnet die optimale Position (oben/unten/links/rechts + Offset) und Kollisionsvermeidung (Flip; Shift; Arrow-Positioning) automatisch; wird von shadcn/ui Tooltip, Radix UI Tooltip und React-Tooltip verwendet.

Tooltip-Implementierung und ARIA-Semantik

ARIA role=tooltip und aria-describedby: Korrekte ARIA-Implementierung: <button id="edit-btn" aria-describedby="edit-tooltip">✏️</button><div role="tooltip" id="edit-tooltip">Bearbeiten (Strg+E)</div>; aria-describedby: Screen-Reader liest Button-Accessible-Name + Beschreibung aus Tooltip; Reihenfolge: «Bearbeiten, Taste» (Button-Rolle) + «Bearbeiten (Strg+E)» (Tooltip-Text); role=«tooltip» vs. aria-label: aria-label = kurzer Name für Element ohne zugänglichen Namen (ersetzt visuellen Text); aria-describedby → role=«tooltip» = zusätzliche ergänzende Beschreibung (ergänzt bestehenden Namen); aria-describedby nur auf Tooltip-Container das role=«tooltip» hat zeigen; CSS für Tooltip-Sichtbarkeit: Tooltip-Container initial mit visibility:hidden oder display:none; bei Hover/Focus des Auslöser-Elements: visibility:visible; WCAG 1.4.13 Hoverable: pointer-events: auto auf dem Tooltip selbst (Standard wenn sichtbar); Hover über Tooltip → Tooltip bleibt sichtbar; mouseenter/mouseleave Event-Management mit Delay: showTimeout = setTimeout(showTooltip, 500); bei mouseleave: clearTimeout(showTimeout); Dismissable: document.addEventListener('keydown', e => { if (e.key === 'Escape') hideTooltip(); }); Persistent: Tooltip bleibt bis mouseout vom Tooltip ODER Auslöser-Element; z-index: Tooltip über anderen Elementen; z-index: 1000 als Basis; kein Stacking-Context-Problem
Tooltip-Positionierung und Viewport-Handling: Manuelle CSS-Positionierung (einfache Fälle): position:absolute auf Tooltip-Container; position:relative auf Auslöser; top:-100%; left:50%; transform:translateX(-50%) für zentriert oben; Pfeil mit ::after Pseudo-Element (Border-Trick: transparente Borders mit einer farbigen Seite als Triangle); Problem: Viewport-Kollision bei Elementen am Rand; Floating-UI-Lösung (empfohlen für professionelle Projekte): npm install @floating-ui/dom; import { computePosition, flip, shift, offset, arrow } from '@floating-ui/dom'; computePosition(button, tooltip, { placement: 'top', middleware: [offset(6), flip(), shift({padding: 5}), arrow({element: arrowEl})] }).then(({x, y, placement, middlewareData}) => { Object.assign(tooltip.style, {left: x + 'px', top: y + 'px'}); }); Floating-UI-Middleware: offset = Abstand vom Auslöser; flip = wechselt Seite wenn Platz nicht reicht; shift = verschiebt Tooltip wenn er abgeschnitten wird; arrow = positioniert Pfeil korrekt nach Flip/Shift; React-Tooltip (npm; ReactTooltip-Library): Wrapper um Floating-UI für React; Tooltip-Delay-Standard: 500ms Hover-Delay ist Industrie-Konvention (verhindert unbeabsichtigte Tooltip-Auslösung bei schneller Mausbewegung); für Shortcut-Tooltips: 1000ms Delay (selten gebraucht); für kritische Warn-Tooltips: 0ms Delay
Mobile Tooltip-Problem und Alternativen: Mobile Hover-Problem: Touch-Geräte haben keine Hover-Interaktion; Tooltip beim Tap-und-Halten (Long-Press) ist möglich aber keine gute UX (Nutzer erwarten Long-Press für andere Aktionen wie Text-Auswahl; Context-Menu); Lösungsansätze für Mobile: (1) Inline-Hilfe statt Tooltip: kurzen Hilfe-Text direkt unter Element platzieren (<small class=«help-text»>); spart Platz aber immer sichtbar; (2) Info-Icon (ⓘ) als Tap-Target: klickbares Fragezeichen oder i-Icon das Hilfe-Text als Inline-Expansion oder kleinen Dialog öffnet; kein Hover notwendig; WCAG-konform; (3) Placeholder-Text in Inputs als Format-Hinweis (ersetzt Format-Tooltips); (4) Popover-Ansatz: tapbarer Info-Button der ein Popover mit Rich-Content öffnet; explizit schließbar; fokussierbar; Detects Touch vs. Hover: CSS @media (hover: hover) { /* nur auf Hover-fähigen Geräten */ .tooltip-trigger:hover .tooltip { visibility: visible; } }; JavaScript matchMedia('(hover: hover)') für feature-basiertes Tooltip-Enabling; Tablets: Hybrid-Geräte (Surface; iPad mit Tastatur) können hovern; testen!

Tooltip-Anti-Patterns und Best Practices

Wann Tooltips einsetzen und wann nicht: Richtige Tooltip-Einsätze: Icon-only-Buttons ohne Text-Label (Tooltip = Label); Keyboard-Shortcut-Hinweise auf Funktionen die auch anders erreichbar sind; optionale Format-Hinweise für Formularfelder; Erklärung von Fachbegriffen oder Abkürzungen; Preview-Information (Username-Card; Link-Preview); Falsche Tooltip-Einsätze (Anti-Patterns): Critical Information – Information die Nutzer zur Aufgabenerledigung brauchen muss im Interface sichtbar sein; Pflichtfeld-Erklärung; Fehlermeldung; Essential-Kontext; Mobile-Important-Actions – Funktionen die Mobile-Nutzer brauchen werden durch Hover-only-Tooltips versteckt; Redundante Tooltips – Tooltip wiederholt exakt das Label des Elements (kein Mehrwert; nur Clutter); Sehr langer Text – mehr als 2 kurze Sätze im Tooltip; Tooltips sind für kurze Hinweise; für längeren Text Popover oder Inline-Hilfe nutzen; Interactive Content im einfachen Tooltip – Links; Buttons; Formulare gehören in Popover nicht in Tooltip; Nielsen Norman Group «Tooltip Guidelines» (Kate Moran; 2021): «Tooltips work well for providing supplemental information that not every user will need; they work poorly for information that most users will need»

Praxistipp: Die häufigste Tooltip-Falle: kritische Pflichtinformation im Tooltip verstecken weil das Interface dann «sauberer» aussieht. Wenn 30% oder mehr Ihrer Nutzer den Tooltip öffnen um eine Aufgabe erledigen zu können, ist die Information zu wichtig für einen Tooltip – sie gehört permanent sichtbar ins Interface. Und für die WCAG-1.4.13-Compliance: testen Sie ob Ihr Tooltip beim Hinüberbewegen des Mauszeigers vom Auslöser auf den Tooltip sichtbar bleibt (Hoverable-Requirement) und ob Escape den Tooltip schließt ohne den Fokus zu bewegen (Dismissable-Requirement). Diese beiden Punkte scheitern in der Mehrheit der Tooltip-Implementierungen beim Accessibility-Audit.