Inhalte bei Hover und Fokus: Tooltips und Ausklapp-Menüs, die niemanden aussperren
Ein Tooltip erscheint, sobald die Maus über einem Symbol schwebt. Ein Untermenü klappt auf, wenn ein Navigationspunkt den Tastaturfokus bekommt. Solche Einblendungen sind praktisch, können aber Menschen mit Bildschirmvergrößerung oder reiner Tastaturbedienung massiv behindern. Das WCAG-Erfolgskriterium 1.4.13 „Content on Hover or Focus"(Stufe AA) stellt deshalb drei Bedingungen: Einblendungen müssen schließbar, überfahrbar und beständig sein. Diese Seite erklärt, was das konkret heißt und wie du es umsetzt.
Worum es geht: Inhalte, die kommen und gehen
Das Kriterium betrifft alle Inhalte, die zusätzlich erscheinen, wenn ein Element den Mauszeiger (Hover) oder den Tastaturfokus erhält, und wieder verschwinden, wenn Zeiger oder Fokus weiterwandern. Die häufigsten Beispiele: selbst gebaute Tooltips, aufklappende Untermenüs in der Navigation und kleine Vorschau-Popups, etwa eine Karten- oder Produktvorschau beim Überfahren eines Links.
Warum ist das ein Barrierefreiheits-Thema? Stell dir vor, du arbeitest mit einer Bildschirmvergrößerung bei 400 Prozent. Dein sichtbarer Ausschnitt ist dann nur ein kleines Fenster in eine große Seite. Um zu lesen, was in einem Tooltip steht, musst du den Ausschnitt verschieben. Wenn der Tooltip dabei verschwindet, sobald die Maus den Auslöser verlässt, kommst du nie bis zum Text. Und wenn eine Einblendung genau den Bereich verdeckt, den du gerade lesen wolltest, brauchst du einen Weg, sie loszuwerden, ohne deine Maus- und Fokusposition aufzugeben.
Das Kriterium ist seit WCAG 2.1 Teil des Standards, gilt unverändert in WCAG 2.2 auf Konformitätsstufe AA und ist damit auch Teil dessen, was BITV 2.0 und BFSG über die EN 301 549 faktisch verlangen.
Die drei Bedingungen auf einen Blick
Wenn deine Seite Inhalte bei Hover oder Fokus ein- und wieder ausblendet, müssen laut Kriterium alle drei der folgenden Bedingungen erfüllt sein. Die englischen Originalbegriffe lauten dismissable , hoverable und persistent :
Die folgenden drei Kapitel gehen die Bedingungen einzeln durch, mit dem jeweiligen Zweck und der typischen Umsetzung.
Schließbar: Ausblenden ohne Mausbewegung
Eine Einblendung kann genau den Inhalt verdecken, den jemand gerade lesen oder bedienen will. Deshalb verlangt die erste Bedingung einen Mechanismus, mit dem sich die Einblendung ausblenden lässt, ohne Mauszeiger oder Tastaturfokus zu bewegen. Der W3C-Begleittext nennt als etablierte Lösung die Esc -Taste.
Es gibt zwei Wege, diese Bedingung zu erfüllen:
- Nichts verdecken: Du positionierst die Einblendung so, dass sie außer Weißraum und rein dekorativen Hintergründen keine anderen Inhalte überlagert, auch nicht den Auslöser selbst. Dann ist kein Schließ-Mechanismus nötig.
- Schließ-Mechanismus anbieten:
Meist die robustere
Wahl, denn bei kleinen Viewports oder Zoom verdeckt fast jede
Einblendung irgendetwas. Standard: ein
keydown-Listener, der bei Esc die Einblendung entfernt.
tooltip.js · Schließen per Esc-Taste
document.addEventListener('keydown', (event) => {
if (event.key === 'Escape') {
hideTooltip(); // blendet die Einblendung aus …
}
}); // … ohne dass sich Fokus- oder Zeigerposition ändern.
Eine Ausnahme erlaubt das Kriterium ausdrücklich: Einblendungen, die einen Eingabefehler melden, dürfen bestehen bleiben, bis das Problem behoben ist, denn hier ist das Verdecken gewollt und die Meldung verlangt eine Reaktion.
Überfahrbar: der Zeiger darf auf die Einblendung
Die zweite Bedingung gilt, wenn die Einblendung per Mauszeiger
ausgelöst werden kann: Der Zeiger muss sich vom Auslöser auf
die Einblendung bewegen lassen, ohne dass sie verschwindet.
Das klingt selbstverständlich, scheitert in der Praxis aber oft daran,
dass das mouseleave
-Ereignis des Auslösers die Einblendung
sofort entfernt.
Zwei Gruppen profitieren besonders: Menschen, die mit Vergrößerung arbeiten und scrollen oder schwenken müssen, um eine große Einblendung vollständig zu sehen. Und Menschen, die über die Systemeinstellungen einen großen Mauszeiger nutzen, der den Einblendungstext sonst selbst verdeckt: Sie schieben den Zeiger an den Rand der Einblendung, um den Text freizulegen.
Praktisch bedeutet das: Die Einblendung sollte direkt an den Auslöser angrenzen oder ihn überlappen, damit der Zeiger ohne Lücke hinüberwandern kann. Liegt eine Lücke dazwischen, fällt der Zeiger auf dem Weg „ins Leere" und die Einblendung schließt sich. Technisch löst du das, indem Auslöser und Einblendung als gemeinsamer Hover-Bereich behandelt werden, etwa über ein umschließendes Element oder eine kurze Schließ-Verzögerung, die den Übergang erlaubt.
Beständig: die Einblendung bleibt, bis du entscheidest
Die dritte Bedingung sichert ausreichend Zeit zum Wahrnehmen: Die Einblendung muss sichtbar bleiben, bis eines von drei Ereignissen eintritt. Erst dann darf sie verschwinden:
| Ereignis | Beispiel |
|---|---|
| Hover oder Fokus werden entfernt | Die Nutzerin bewegt die Maus von Auslöser und Tooltip weg oder tabbt zum nächsten Element weiter. |
| Die Nutzerin schließt die Einblendung aktiv | Druck auf Esc , also über den Mechanismus aus der Bedingung „schließbar". |
| Die Information wird ungültig | Eine „Wird geladen…"-Meldung verschwindet, sobald der Ladevorgang abgeschlossen ist. |
Nicht erlaubt ist damit das beliebte Muster, einen Tooltip nach einer festen Zeitspanne automatisch auszublenden, etwa nach drei Sekunden. Menschen brauchen unterschiedlich lange, um eine Einblendung zu finden, sie in den vergrößerten Ausschnitt zu holen und zu lesen. Eine Stoppuhr im Code kann das nicht wissen.
Was nicht unter das Kriterium fällt
Genauso wichtig wie die drei Bedingungen ist die Abgrenzung: Nicht jede Einblendung fällt unter 1.4.13. Die Übersicht:
| Inhaltstyp | Fällt unter 1.4.13? | Begründung |
|---|---|---|
| Eigene Tooltips, Untermenüs, nicht-modale Popups | Ja | Vom Autor oder der Autorin gestaltete Zusatzinhalte bei Hover/Fokus, genau der Kernfall des Kriteriums. |
Browser-Tooltip über das title
-Attribut |
Nein | Darstellung wird vollständig vom Browser (User Agent) kontrolliert und nicht vom Autor verändert, explizite Ausnahme im Kriterium. |
| Modale Dialoge | Nein | Modale Dialoge müssen den Fokus übernehmen und sollten gar nicht erst durch Hover oder Fokus erscheinen (siehe SC 3.2.1 „Bei Fokus"). |
| Skip-Links, die bei Fokus sichtbar werden | Nein | Hier wird das fokussierte Element selbst sichtbar, es erscheint kein zusätzlicher Inhalt. |
| Eingabefehler-Meldungen | Teilweise | Fallen unter das Kriterium, sind aber von der Schließbar-Bedingung ausgenommen, weil sie Aufmerksamkeit und Korrektur verlangen. |
Zwei Missverständnisse
„WCAG verbietet Tooltips und Hover-Menüs."
Nein. Das Kriterium verbietet keine Einblendungen, es stellt Bedingungen an ihr Verhalten. Ein Tooltip, der schließbar, überfahrbar und beständig ist, ist vollständig konform. Der W3C-Begleittext empfiehlt allerdings, zuerst zu prüfen, ob die Information nicht besser dauerhaft sichtbar wäre, denn das ist für alle die vorhersehbarste Lösung.
„Mit dem title-Attribut bin ich auf der sicheren Seite."
Nur formal. Das title
-Attribut fällt zwar unter die
User-Agent-Ausnahme von 1.4.13, erfüllt aber den eigentlichen Zweck
oft nicht: Tastatur-Nutzer:innen sehen den Browser-Tooltip nie, und
auf Touchscreens gibt es kein Hover. Wer wichtige Informationen nur
ins title
-Attribut legt, schließt also weiterhin
Menschen aus, nur eben an anderer Stelle.
Praxis: ein Tooltip, der alles richtig macht
So sieht ein Tooltip-Grundgerüst aus, das die drei Bedingungen erfüllt
und sich am Tooltip-Pattern der ARIA Authoring Practices orientiert:
Der Auslöser referenziert den Tooltip per aria-describedby
, die Einblendung erscheint bei Hover und
Fokus, bleibt überfahrbar und lässt sich per Esc
schließen.
tooltip.html · Struktur
<button class="info-btn" aria-describedby="tip-iban"> Was ist eine IBAN? </button> <div id="tip-iban" role="tooltip" hidden> Die internationale Kontonummer, in Deutschland 22 Stellen. </div>
tooltip.js · Verhalten (gekürzt)
const btn = document.querySelector('.info-btn');
const tip = document.getElementById('tip-iban'); // Anzeigen bei Hover UND Tastaturfokus
btn.addEventListener('mouseenter', show);
btn.addEventListener('focus', show); // Überfahrbar: erst schließen, wenn Zeiger
// weder Auslöser noch Tooltip berührt
btn.addEventListener('mouseleave', scheduleHide);
tip.addEventListener('mouseenter', cancelHide);
tip.addEventListener('mouseleave', scheduleHide);
btn.addEventListener('blur', hide); // Schließbar: Esc blendet aus, Fokus bleibt stehen
document.addEventListener('keydown', (e) => {
if (e.key === 'Escape') hide();
});
function show() { tip.hidden = false; }
function hide() { tip.hidden = true; }
Die Funktion scheduleHide
wartet einen kurzen Moment
(etwa 150 Millisekunden), bevor sie ausblendet. Das überbrückt
den Zeigerweg vom Auslöser zur Einblendung und macht den Tooltip
überfahrbar, ohne dass er „klebt". Beständig ist er, weil kein
Zeitlimit ihn automatisch entfernt. Positioniere den Tooltip direkt
angrenzend an den Auslöser und prüfe mit Zoom (mindestens
200 Prozent), ob er lesbar bleibt.
Checkliste für deine nächste Einblendung
Wenn alle sechs Punkte bestehen, erfüllt deine Einblendung WCAG 1.4.13 und ist nebenbei für alle angenehmer zu bedienen: Auch Maus-Profis kennen den Frust, wenn ein Menü zuschnappt, weil der Zeiger einen Millimeter daneben lag.
Verhalten sich deine Tooltips und Menüs barrierefrei?
Wir prüfen deine Komponenten gegen WCAG 2.2, von Einblendungen über Fokusführung bis Tastaturbedienung, und zeigen deinem Team, wie barrierefreie Interaktionsmuster von Anfang an gelingen.
Beratung oder Schulung anfragen
