Im Allgemeinen verstehen wir unter einem Tooltip eine nicht-modale Text-Einblendung. Die Informationen des Tooltips sind standardmäßig ausgeblendet und stehen erst zur Verfügung, wenn Nutzende ein Steuerelement fokussieren. Bei benutzerdefinierten Komponenten kann der Inhalt recht unterschiedlich ausgeprägt sein. Es kann sich dabei um ein Wort, einen kurzen Text oder gar um umfangreichen strukturierten oder interaktiven Inhalt handeln. Die Art des Inhalts und der Zweck sind wichtige Kriterien, die bei der barrierefreien Umsetzung eine Rolle spielen und möglicherweise gar ein abweichendes Umsetzungsmuster erfordern.

Tooltips

Tooltips (im konventionellen Sinne) liefern Informationen über ein vorhandenes Bedienelement. Mit dem Text selbst interagieren Nutzende jedoch nicht. Dieser Aspekt unterscheidet sie wesentlich von sogenannten Toggletips. Toggletips werden daher als eigene UI-Komponente beschrieben.

Native Tooltips (title)

Für die Umsetzung von nativen Tooltips hält die HTML-Spezifikation seit fast drei Jahrzehnten das title-Attribut bereit. Trotz seiner Beständigkeit hat dieses Attribut bei den Barrierefreiheits-Fachleuten einen äußerst schlechten Ruf. Der Einsatz erfolgt in der Praxis oft unbedacht, redundant oder geschieht unter der falschen Annahme, es sei ein Barrierfreiheits- und SEO-Feature. Das Gegenteil ist leider der Fall. Die HTML-Spezifikation warnt regelrecht vor dessen Einsatz.

Sie beschreibt den Tooltip sinngemäß als zusätzlichen, nicht zwingend notwendigen Hilfstext. Wichtige Informationen sollen nicht mit Hilfe des title-Attributs vermittelt werden. Der Browser zeigt den Wert (den Text) nur bei Berührung mit einem Zeigegerät an. Das bedeutet, er ist nur für Menschen verfügbar, die auch ein Zeigegerät nutzen — zum Beispiel eine Maus.

Nutzende, die andere Eingabemittel verwenden, werden Tooltips nicht oder nur mit Schwierigkeiten wahrnehmen können. Hierzu zählen:

  • Menschen, die mit der Tastatur navigieren
  • Mausnutzende, die eingeschränkte feinmotorische Fähigkeiten besitzen
  • Spracheingabe-Nutzende
  • Menschen, die Touch-Geräten verwenden
  • Menschen, die eine Vergrößerungssoftware einsetzen

Benutzerdefinierte Tooltips ("Custom Tooltips")

Nachdem nun native Tooltips die beschriebenen Defizite mit sich bringen, bieten nachgebaute Tooltips ("Custom Tooltips") im Hinblick auf Barrierefreiheit mehr Potenzial.

Damit sie für alle Menschen zugänglich sind, müssen Tooltips:

  • mit der Maus, einer Tastatur, einem Screenreader, einer Vergrößerungssoftware und jeder anderen Hilfstechnologie verfügbar sein.
  • Egal mit welchen Mitteln, die Nutzenden müssen Tooltips anzeigen und natürlich lesen können.
  • Sie dürfen außerdem Nutzende nicht daran hindern, andere Aufgaben auf der Webseite auszuführen.

Wichtig für eine barrierefreie Umsetzung (insbesondere für die nicht-visuelle Nutzung), ist ein semantischer HTML-Code. Er sorgt dafür, dass Informationen zur Bedeutung und Funktion eines Elements auf einer abstrakten Ebene vorhanden sind und Menschen, die einen Screenreader nutzen, zur Verfügung stehen. Hinsichtlich des Zwecks können wir Tooltips zur Beschriftung und für weiterführende Hinweise unterscheiden.

Der Tooltip zur Beschriftung (Name)

Tooltips fungieren als Beschriftung, wenn Symbol-Schalflächen nicht ausreichend selbsterklärend sind. Web-Autoren und -Autorinnen nutzen in diesem Fall benutzerdefinierte Tooltips, um die grafische Schaltfläche explizit mit einem eingeblendeten Text zu bezeichnen. Für ein Herz-Icon erscheint beispielsweise der Tooltip „Gefällt mir“. Er dient als Textalternative für das Icon oder anders ausgedrückt, der Tooltip ist der zugängliche Name ("accessible name") der Symbol-Schaltfläche. Der zugängliche Name identifiziert und bezeichnet das Bedienelement.

Screenshot eines Umsetzungsbeispiels der ARIA Authoring Practices (APG) Task Force. Unter einem Schalter mit einem gelben Herzsymbol ist ein geöffneter Tooltip mit dem Text "Like" zu sehen. Darunter findet sich eine Darstellung des HTML-Quellcodes zum Beispiel.
Beschriftung per Tooltip

Ein Tooltip kann den zugänglichen Namen eines Bedienelements liefern.

Quelle: codepen.io, Zoë Bijl / APG Task Force, , Alle Rechte vorbehalten

Bei dieser Umsetzung steht sehenden wie nicht sehenden Menschen die Textalternative gleichermaßen zur Verfügung. Während sehende Menschen sie visuell als Texteinblendung wahrnehmen, liest der Screenreader sie vor. Dafür muss der Text für das Hilfsmittel programmatisch ermittelbar sein. Die Verknüpfung von auslösendem Element und Text erfolgt mit Hilfe des Attributs aria-labelledby.

Der Screenreader liest zuerst den zugänglichen Namen (die Textalternative) vor und gibt danach die Rolle des Elements aus. Zum Beispiel: Gefällt mir Schalter.

<button class="tooltip-trigger" aria-labelledby="tooltip">
    <!-- Icon, img oder svg -->
</button>
<div id="tooltip">Gefällt mir</div>

Bitte beachten Sie: Enthält das button-Element einen weiteren Textinhalt, so gibt der Screenreader diesen nur aus, wenn dieser Text und der Tooltip-Text jeweils über eine id referenziert werden. Der Wert des aria-labelledby-Attributs überschreibt ansonsten die vorhandene Beschriftung der Schaltfläche.

Beispiel: Eine Symbol-Schaltfläche, die neu eingegangene Nachrichten über eine Zahl anzeigt, blendet zusätzlich einen Tooltip mit dem Text „Benachrichtigungen“ ein. Der Wert von aria-labelledby besteht dann aus zwei, durch ein Leerzeichen getrennte id-Werte. Das Attribut aria-labelledby referenziert dadurch beide Textbestandteile und beide werden vorgelesen.

Der Tooltip für zusätzliche Hinweise (Beschreibung)

Diese Funktion kommt dem konventionellen title-Attribut nahe. Der Tooltip dient als Erklär- oder Hilfetext. Der eingeblendete Text liefert eine zusätzliche Beschreibung ("accessible description") für das interaktive Element. Genau wie der Name muss auch die Beschreibung programmatisch ermittelbar sein. Die Verknüpfung erfolgt mit dem Attribut aria-describedby.

Screenshot eines Umsetzungsbeispiels der ARIA Authoring Practices (APG) Task Force. Unter einem Schalter mit einem Zahnradsymbol ist ein geöffneter Tooltip mit dem Text &quot;View and manage settings&quot; zu sehen. Darunter findet sich eine Darstellung des HTML-Quellcodes zum Beispiel.
Ergänzung per Tooltip

Wo ein zugänglicher Name bereits vorhanden ist, kann ein Tooltip ergänzend beschreiben.

Quelle: codepen.io, Zoë Bijl / APG Task Force, , Alle Rechte vorbehalten

Bitte beachten Sie: Während eine zugängliche Beschreibung, abhängig vom Kontext, nur in manchen Situationen nötig ist, ist ein zugänglicher Name für alle interaktiven Elemente unabdingbar. Wenn Sie also den Tooltip-Text mit aria-describedby verknüpfen, so müssen Sie gewährleisten, dass für das Bedienelement selbst ein zugänglicher Name zur Verfügung steht. Sie können dies für eine Symbol-Schaltfläche beispielsweise mit dem aria-label-Attribut oder mit Hilfe von visuell verstecktem Text umsetzen (dieser Text ist dann nur für die assistive Technologie verfügbar).

Der Screenreader gibt in diesem Fall zuerst den zugängliche Namen, dann die Rolle des Elements aus. Als letzten Bestandteil (meist etwas verzögert) liest er den verknüpften Tooltip-Text vor. Zum Beispiel: Mein Profil Schalter Einstellungen zu Ihrem Profil ansehen und anpassen.

<button class="settings" aria-describedby="description">
    <!-- Icon, img oder svg -->
    <span class="visually-hidden">Mein Profil</span>
</button>
<div role="tooltip" id="description">
    Einstellungen zu Ihrem Profil ansehen und anpassen
</div>

Ist der Tooltip ausgeblendet, sollte er für Screenreader-Nutzende versteckt sein. Sie verhindern dadurch, dass ihn der Screenreader im Lesemodus möglicherweise noch einmal ausgibt. Normalerweise ist dies durch den Einsatz von display: none bereits gegeben. Gegebenenfalls können Sie zusätzlich aria-hidden="true" einsetzen. Der Wert sollte im eingeblendeten Zustand dynamisch auf "false" wechseln. Dies gilt für den „Tooltip als Beschriftung“ wie auch für den „Tooltip für Beschreibungen“.

Der Einsatz von role="tooltip"

Die ARIA-Spezifikation hält eine spezifische Rolle (role="tooltip") für die Umsetzung von Tooltips bereit. Die Definition von role="tooltip" und dessen Anwendung ist gemäß Spezifikation jedoch recht eng und vergleichbar mit der des title-Attributs beziehungsweise des Tooltips für Beschreibungen. Laut Spezifikation sollen Autoren und Autorinnen sicherstellen, dass sie role="tooltip" in Kombination mit aria-describedby gebrauchen (siehe Code-Beispiel „Tooltips für Beschreibungen“).

Der Einsatz von role="tooltip" ist im Kontext eines beschreibenden Tooltips zwar standardkonform, das Attribut hat derzeit jedoch keine Auswirkungen auf die Ausgabe des Screenreaders (Stand November 2021). aria-labelledby oder aria-describedby sorgen dafür, dass der Screenreader den verknüpften Text vorliest.

Steuerung mit hover und focus

Wie bereits erwähnt, sollten Tooltips nicht nur mit der Maus, sondern auch mit der Tastatur zu steuern sein. Das bedeutet, ein Tooltip sollte beim Eintreten der (JavaScript-)Ereignisse focus und mouseover eingeblendet sowie bei blur und mouseout wieder ausgeblendet werden.

Dieses Verhalten kann jedoch manche Nutzende vor eine weitere Herausforderung stellen. Menschen, die eine Vergrößerungssoftware nutzen, sehen (je nach Vergrößerungsstufe) nur einen kleinen Bereich der Webseite. Während der Mauszeiger über den Inhalt der Seite gleitet, wandert dieser sichtbare Ausschnitt mit. Blendet die Maus (oder Tastatur) einen Tooltip ein, überlagert er möglicherweise ungewollt Inhalte. Genauso kann es leicht passieren, dass ein Tooltip ungewollt wieder ausgeblendet wird.

Die Web Content Accessibility Guidelines (WCAG) reagieren mit der Version 2.1 auf dieses Problem mit dem Erfolgskriterium 1.4.13 Content on Hover or Focus. Wenn der Mauszeiger oder Tastaturfokus zusätzliche Inhalte ein- bzw. ausblendet, gilt Folgendes:

  • Nutzende können den eingeblendeten Inhalt schließen, ohne den Fokus zu bewegen (etwa mit der ESC-Taste). Dies ist nicht gegeben, wenn sie etwa nach einem Schließen-Element suchen müssten. Die Anforderung soll dem bereits beschriebenen Umstand entgegen wirken, dass bei Nutzung einer Vergrößerungssoftware die Einblendung unbeabsichtigt andere Inhalte verdeckt.
  • Nutzende können die Maus über den Inhalt des Tooltips bewegen, ohne dass der Tooltip verschwindet. Dies verhindert die Schwierigkeit, den Mauszeiger über dem auslösenden Element halten zu müssen. Außerdem ermöglichen Sie seheingeschränkten Menschen, mit dem Mauszeiger über den Tooltip-Text zu gleiten und den sichtbaren Ausschnitt zu verschieben.
  • Der Tooltip sollte so lange sichtbar bleiben, bis Nutzende ihn aktiv ausblenden, zum Beispiel über Weiter-TAB-en, Wegbewegen der Maus vom eingeblendeten Inhalt oder explizites Schließen mit die Tastatur. Sie stellen damit sicher, dass sich Nutzende für das Lesen des Inhalts so viel Zeit lassen können wie nötig.
Das Kreuz mit der Flucht

Die Forderung der WCAG, eingeblendeter Inhalt müsse zu schließen sein, ohne dass dafür der Fokus oder die Zeigerposition verändert wird, hat mitunter gravierende Konsequenzen, die vielleicht nicht gleich offensichtlich sind. Es wird etwa vorgeschlagen, Tooltips sollten zum Beispiel über die ESC-Taste (für englisch "Escape", also „Flucht“ oder „Entkommen“) zu schließen sein.

Um zusätzliche Inhalte einzublenden, sobald ein Element den Tastaturfokus erhält oder mit einem Zeigegerät überfahren wird ("Hover"), werden im einfachsten Fall nur ein paar wenige Zeilen CSS benötigt, die das ansonsten ausgeblendete Element vorübergehend sichtbar machen.

button + .tooltip {
    display: none;
}
button:focus + .tooltip,
button:hover + .tooltip {
    display: block;
}

Um diesen per CSS herbeigeführten Zustand wieder aufzuheben, muss nur die jeweilige Ursache beseitigt werden: Das Element muss den Fokus verlieren, respektive der Zeiger muss das Element wieder verlassen. Ähhh — war da nicht etwas!? Richtig: ein klarer Verstoß gegen die Forderungen der WCAG!

Wenn stattdessen die Tastatur genutzt werden soll, um den Tooltip wieder auszublenden, etwa mit der ESC-Taste, dann ist dazu plötzlich eine andere Technologie notwendig: JavaScript. Während sich CSS dazu eignet, unsere Website schick aussehen zu lassen, ist die Überwachung der Tastatur ganz klar JavaScript-Domäne. Aber halt! Ganz abgesehen davon, dass wir uns mit JavaScript (vielleicht ungewollt?) eine zusätzliche technische Abhängigkeit an Bord holen, haben wir nun ein Problem: Es kann per JavaScript kein Zustand aufgehoben werden, der per CSS herbeigeführt wurde.

Nur, wenn JavaScript auch am Einblenden des Tooltips beteiligt war, kommt es fürs Ausblenden überhaupt in Frage. Damit fällt die einfachste Möglichkeit — nämlich das Einblenden per CSS allein — leider weg, solange man dem Erfolgskriterium 1.4.13 Content on Hover or Focus wirklich gerecht werden möchte. Die zukünftigen WAI-ARIA Authoring Practices 1.2 halten ein dazu passendes Umsetzungsbeispiel bereit. Eine wirklich robuste Umsetzung sollte aber wohl am Besten das Prinzip des Progressive Enhancement beherzigen und zunächst als reine CSS-Lösung an Browser ausgeliefert werden, die erst dann vor Ort per JavaScript um die Tastatursteuerbarkeit angereichert und entsprechend angepasst wird.

Experte für Barrierefreiheit / CAO, Geschäftsführer, Mitglied der Geschäftsleitung

Dipl.-Ing. Joschi Kuphal, CPWA · ADS

Toggletips

Native Tooltips und Custom Tooltips haben eine wichtige Gemeinsamkeit: Nutzende interagieren nur mit dem dazugehörigen Bedienelement. Der Tooltip selbst wird bei hover oder focus automatisch eingeblendet und vom Screenreader als eine Zeichenfolge vorgelesen. Semantische Informationen (Überschriften oder Links) gibt der Screenreader nicht aus, da der Tooltip selbst keinen Fokus erhält.

Bei umfangreichen, strukturierten oder semantischen Texteinblendungen ergeben sich andere Bedarfe. Nutzende müssen in diesem Fall mit dem Inhalt interagieren und semantische Informationen wahrnehmen können. Ein anderes Umsetzungsmuster ist daher notwendig: Der sogenannte Toggletip.

Beim Toggletip hat das Bedienelement die Aufgabe, erst bei Aktivierung weitere Inhalte einzublenden. Die zusätzlichen Informationen stehen im DOM nach dem auslösenden Element und Nutzende können sie nach Einblendung regulär erkunden. Sie können Links und Schaltflächen fokussieren, da sie in der natürlichen Fokusreihenfolge enthalten sind.

Eine Ausgabe bei Fokuserhalt mittels aria-describedby könnte (je nach Textumfang) in diesem Szenario viel zu ausführlich und schwer wahrnehmbar sein.

Screenshot vom &quot;Infotip&quot; in den eBay MIND Patterns. Ein Hand-Cursor liegt über einer blauen &quot;i&quot;-Icon-Schaltfläche. Rechts neben dem Cursor ist eine Texteinblendung mit einem Schließen-Schalter zu sehen.
Toggletip bei eBay

In seinen ebay MIND Patterns, einer Sammlung barrierefreier Anwendungsmuster, zeigt eBay Toggletip-Varianten mit oder ohne interaktiven Inhalt.

Quelle: ebay.gitbook.io, eBay Inc., , MIT

Technische Umsetzung

Die technische Umsetzung entspricht im Wesentlichen der des Disclosure-Widgets:

  • Nutzende aktivieren eine Schaltfläche mit der Maus, Tastatur oder Touch und die Einblendung erscheint. Der Fokus bleibt auf der Schaltfläche, bei erneuter Aktivierung schließt sie sich. Noch sinnvoller ist gar, wenn sich die Einblendung automatisch schließt, sobald sich der Tastaturfokus aus dem Toggletip hinausbewegt.
  • Ein button-Element dient als Steuerelement. Achten Sie darauf, dass die Schaltfläche einen zugänglichen Namen hat (eine Text-Beschriftung oder Textalternative).
  • Der Inhalt des Toggletips sollte die Lesereihenfolge beachten, im DOM also (direkt) nach dem auslösenden Element stehen. Auf diese Weise können Menschen, die einen Screenreader nutzen, die Inhalte direkt mit den Pfeiltasten und allen ihnen zur Verfügung stehenden Tastaturbefehlen erkunden und damit interagieren.
  • Für das Verständnis des jeweiligen Zustandes der Komponente sorgt der Einsatz des Attributs aria-expanded mit dem Wert true oder false. Es vermittelt, ob der Toggletip ein- oder ausgeblendet ist („erweitert“ oder „reduziert“).

Hinweise und Tipps

  • Das title-Attribut ist nicht für die Umsetzung eines zugänglichen Namens (Textalternative oder Beschriftung) gedacht, sondern (laut Spezifikation) lediglich für nicht substanzielle, zusätzliche Inhalte.
  • Vermeiden Sie redundanten Text im Tooltip. Wiederholen Sie keinen Link- oder Alternativtext. Die Ausgabe des Screenreaders kann dadurch in manchen Fällen störend lang sein.
  • Gestalten Sie Ihre Benutzeroberfläche so, dass Sie auf Tooltips verzichten können. Bieten Sie möglichst einen statischen, sichtbaren Text im Kontext der Symbol-Schaltfläche an.
  • Verwenden Sie für Beschriftungen von Formularfeldern immer permanent sichtbaren Text. Dies ist auch für Hinweistexte und Fehlermeldungen empfehlenswert.
  • Tooltips sollten die letzte Lösung sein, wenn der Platz wirklich knapp ist. Für Touchscreen-Nutzende funktionieren benutzerdefinierte Tooltips, wenn überhaupt, dann nicht sehr gut. hover ist bei Touch-Bedienung nicht verfügbar. Es ist nicht möglich, eine Schaltfläche oder einen Link zu fokussieren, ohne ihn zu aktivieren.
  • Unterstützen Sie bei der Umsetzung von benutzerdefinierten Tooltips Maus- und Tastaturbedienung. Beachten Sie auch die Anforderungen zur Steuerung bei hover und focus (zum Beispiel Schließen mit der ESC-Taste).
  • Das Attribut aria-haspopup ist nicht für die Umsetzung von Tooltips geeignet. Das Attribut mit dem Wert "true" ist gleichbedeutend mit aria-haspopup="menu" und ist laut Spezifikation nur einzusetzen, wenn der Container, der als Popup dient, mit role="menu" ausgezeichnet ist (bei einem Tooltip ergibt das keinen Sinn).
  • Tooltip-Texte sollten kurz und prägnant sein, damit Nutzende sie unmittelbar erfassen und verstehen können.
  • Ist die Text-Einblendung an ein nicht interaktives Element gebunden? Sie können in diesem Fall eine funktionslose Schaltfläche vermeiden, wenn Sie sich für die Umsetzung als Toggletip entscheiden.

Zusammenfassung

Grafische Elemente können dazu beitragen, dass wir Bedienelemente schneller verstehen. Setzt man sie isoliert ein, sind sie jedoch nicht für jede Person gleichermaßen aussagekräftig und verständlich. Sie können die Bedeutung einer Symbol-Schaltfläche für alle Nutzenden am einfachsten kommunizieren, indem Sie Text neben oder unter der Symbol-Schaltfläche bereitstellen. Prüfen Sie, ob Sie bei der Konzeption entsprechenden Platz für Text berücksichtigen können. Sollte dies nicht möglich sein, unterscheiden Sie bei der Umsetzung die Funktion des eingeblendeten Inhalts. Verwenden Sie:

Unterstützen Sie Maus- und Tastaturbedienung und berücksichtigen Sie die Anforderungen zur Steuerung bei hover und focus. Unter anderem müssen Nutzende die Einblendung ohne Änderung der Fokus-Position schließen können (etwa mit der ESC-Taste).

Interessante Ergebnisse zur Nutzerfreundlichkeit von Tooltips liefert eine Usability-Studie mit Menschen mit Behinderungen (Vortrag von Sarah Higley, Youtube 2020).

Ressourcen

Weiterführende Informationen, darunter Links auf zusätzliche Ressourcen, bieten unter anderem diese englischsprachigen Artikel: