WCAG 1.4.13: Inhalt bei Hover oder Fokus

WCAG 1.4.13 verlangt, dass zusätzlicher Inhalt, der beim Bewegen des Zeigers oder beim Tastaturfokus erscheint, abweisbar, hoverbar und persistent ist – damit sichergestellt ist, dass Nutzer mit Sehbeeinträchtigungen, motorischen Einschränkungen und kognitiven Behinderungen auf Tooltip-ähnliche Inhalte zugreifen und mit ihnen interagieren können, ohne sie unerwartet zu verlieren.

Was diese Regel bedeutet

WCAG 1.4.13 befasst sich mit einem häufigen Interaktionsmuster im Web: Inhalte, die sichtbar werden, wenn ein Nutzer den Zeiger über ein Element bewegt oder die Tastaturfokussierung darauf setzt. Dazu gehören Tooltips, Untermenüs, benutzerdefinierte Dropdown-Hinweise, Datepicker-Popovers und alle anderen Overlays, die als Reaktion auf Hover- oder Fokus-Ereignisse erscheinen. Das Kriterium gilt immer dann, wenn solche Inhalte nicht nativ vom Browser gesteuert werden (zum Beispiel ist der native Tooltip des title-Attributs ausgenommen), und es legt drei Kernanforderungen fest, die alle gleichzeitig erfüllt sein müssen.

Schließbar: Der Nutzer muss in der Lage sein, die zusätzlichen Inhalte zu schließen, ohne den Zeigerfokus oder den Tastaturfokus zu verschieben. Der Standardmechanismus dafür ist das Drücken der Escape-Taste. Dies verhindert, dass das Overlay andere Seiteninhalte auf eine Weise verdeckt, die der Nutzer nicht auflösen kann – besonders kritisch für Nutzer, die den Bildschirm vergrößert haben und nicht einfach woanders hinschauen können.

Hoverbar: Wenn die zusätzlichen Inhalte erscheinen, weil der Nutzer über ein auslösendes Element gehovert hat, muss der Nutzer den Zeiger auf die neu erschienenen Inhalte bewegen können, ohne dass diese verschwinden. Wenn ein Tooltip in dem Moment verschwindet, in dem der Cursor das auslösende Element verlässt, können Nutzer längere Inhalte nicht lesen, keinen Text daraus kopieren oder Links bzw. Steuerelemente darin aktivieren.

Beständig: Die zusätzlichen Inhalte müssen sichtbar bleiben, bis der Hover- oder Fokus-Trigger entfernt wird, der Nutzer sie schließt (zum Beispiel über Escape) oder die Information nicht mehr gültig ist. Inhalte dürfen nicht über einen Timer oder nach einer willkürlichen Verzögerung verschwinden, während sich der Zeiger oder der Fokus noch auf dem Trigger oder dem Overlay selbst befindet.

Ein „Pass“ erfordert, dass alle drei Bedingungen erfüllt sind. Ein „Fail“ tritt ein, wenn eine einzige Bedingung fehlt – zum Beispiel ein Tooltip, der verschwindet, wenn der Zeiger sich vom Trigger in Richtung Tooltip bewegt (nicht hoverbar), oder einer, der sich nach drei Sekunden automatisch schließt (nicht beständig), oder einer, der nicht geschlossen werden kann, ohne den Fokus zu verschieben (nicht schließbar). Die einzige offizielle Ausnahme, die WCAG vorsieht, ist, wenn die visuelle Darstellung der zusätzlichen Inhalte vollständig vom User Agent gesteuert wird – browsernative Tooltips, die ausschließlich durch das title-Attribut erzeugt werden, fallen in diese Kategorie und sind ausgenommen, auch wenn sie ihre eigenen Barrieren für die Barrierefreiheit mit sich bringen.

Warum das wichtig ist

Dieses Kriterium kommt in erster Linie Nutzern zugute, die Schwierigkeiten haben, Standard-Maus- oder Tastaturinteraktionen zu steuern, Nutzern, die auf Bildschirmvergrößerung angewiesen sind, und Nutzern, die Informationen langsamer verarbeiten. Zu verstehen, wer betroffen ist, hilft Teams, die Behebung korrekt zu priorisieren.

Nutzer mit Sehbehinderungen verwenden häufig Bildschirmvergrößerungssoftware wie ZoomText oder die integrierte Betriebssystemlupe, was bedeutet, dass sie bei hohen Zoomstufen nur einen kleinen Teil des Bildschirms sehen. Wenn ein Tooltip erscheint, kann er teilweise außerhalb des Bildschirms liegen, und der Nutzer muss dorthin schwenken. Wenn der Tooltip in dem Moment verschwindet, in dem der Zeiger den Trigger verlässt, kann der Nutzer nicht dorthin schwenken, um ihn zu lesen. Laut Weltgesundheitsorganisation leben weltweit etwa 2,2 Milliarden Menschen mit einer Form von Sehbeeinträchtigung, und ein erheblicher Teil derjenigen, die Computer nutzen, ist eher auf Vergrößerung als auf einen Screenreader angewiesen.

Nutzer mit motorischen Beeinträchtigungen – einschließlich Menschen mit Parkinson, Tremor oder eingeschränkter Feinmotorik – können alternative Zeigegeräte, Kopfzeiger oder Blickverfolgungssysteme verwenden. Präzise Zeigersteuerung ist für diese Nutzer schwierig, was bedeutet, dass das Bewegen von einem kleinen Trigger-Element zu einem kleinen Tooltip, ohne versehentlich beide zu verlassen, nahezu unmöglich sein kann, wenn der Hover-Bereich nicht fehlertolerant ist. Die Hoverbar-Anforderung adressiert dies direkt.

Nutzer mit kognitiven Beeinträchtigungen lesen möglicherweise langsam oder müssen Inhalte mehrfach lesen. Ein Tooltip, der sich nach wenigen Sekunden automatisch schließt, gibt diesen Nutzern nicht genug Zeit, die Informationen aufzunehmen, und ein Tooltip, der nicht geschlossen werden kann, ohne den Fokus zu verschieben, kann ihre Aufmerksamkeit in einem verwirrenden Interaktionszustand festhalten.

Betrachten wir ein konkretes Szenario: Eine Banking-Website zeigt Details zum Kontozinssatz in einem Tooltip an, der erscheint, wenn der Nutzer über ein kleines Informationssymbol hovert. Ein Nutzer mit Sehbehinderung, der auf 400 % gezoomt hat, sieht jeweils nur einen Teil der Seite. Er hovert über das Symbol, der Tooltip erscheint, und er beginnt, den Zeiger in Richtung Tooltip zu bewegen, um das Kleingedruckte zu lesen – aber der Tooltip verschwindet sofort, weil er nur an den Hover-Zustand des Elternelements gebunden ist. Der Nutzer kann die erforderlichen Offenlegungsinformationen nicht abrufen. Dies ist nicht nur eine Frage der Benutzerfreundlichkeit; in regulierten Branchen kann es eine rechtliche Barriere für Barrierefreiheit darstellen.

Über die spezifischen Auswirkungen auf Menschen mit Behinderungen hinaus verbessert die korrekte Umsetzung dieses Kriteriums auch die allgemeine Benutzerfreundlichkeit für alle Nutzer auf Touch-und-Tastatur-Hybridgeräten, reduziert Supportanfragen aufgrund „verschwindender“ UI-Elemente und signalisiert sowohl Nutzern als auch Prüfern die Qualität der Benutzeroberfläche.

Wie man testet

Automatisierter Basisscan: Führen Sie axe DevTools oder Lighthouse auf der Seite mit Hover-/Fokus-gesteuerten Inhalten aus. Notieren Sie alle markierten Probleme mit Tooltip-Rollen, Kontrast oder Fokus-Sichtbarkeit – diese bestätigen keine Konformität mit 1.4.13, schaffen aber eine Ausgangsbasis. Halten Sie fest, welche Elemente Overlay-Inhalte auslösen, damit Sie sie in den manuellen Schritten gezielt prüfen können.
Alle Hover-/Fokus-gesteuerten Inhalte identifizieren: Scrollen Sie durch die Seite und hovern Sie systematisch über jedes interaktive Element – Icon-Buttons, Links mit zusätzlichen Beschreibungen, Formularfeld-Hinweise, Navigationselemente, Datentabellen-Header und Diagrammdatenpunkte. Listen Sie jedes Element auf, das zusätzliche Inhalte erscheinen lässt.
Die Hoverbar-Anforderung testen: Hovern Sie für jeden identifizierten Trigger darüber, um das Overlay anzuzeigen, und bewegen Sie dann den Zeiger langsam vom Trigger-Element auf den Overlay-Inhalt selbst. Das Overlay muss während dieser Bewegung sichtbar bleiben. Wenn es verschwindet, bevor der Zeiger es erreicht, ist das Kriterium nicht erfüllt.
Die Schließbar-Anforderung testen: Während ein Overlay sichtbar ist (ausgelöst durch Hover oder Tastaturfokus), drücken Sie die Escape-Taste. Das Overlay muss sich schließen. Wenn es sich nicht schließt, ist das Kriterium nicht erfüllt. Führen Sie diesen Test sowohl mit dem Zeiger auf dem Trigger als auch mit dem Zeiger über dem Overlay durch.
Die Beständigkeits-Anforderung testen: Lösen Sie ein Overlay aus und lassen Sie dann Ihren Zeiger mindestens 10–15 Sekunden lang auf dem Trigger oder dem Overlay stehen. Das Overlay muss während dieser Zeit sichtbar bleiben. Wenn es ausblendet, ausläuft oder ohne Nutzeraktion verschwindet, ist das Kriterium nicht erfüllt.
Nur-Tastatur-Test: Navigieren Sie mit der Tabulatortaste durch die Seite, ausschließlich mit der Tastatur. Wenn der Fokus auf einem Trigger landet, der zusätzliche Inhalte anzeigt, prüfen Sie: (a) die Inhalte erscheinen, (b) das Drücken von Escape schließt sie, und (c) die Inhalte verschwinden nicht von selbst, solange der Fokus auf dem Trigger bleibt. Verwenden Sie NVDA mit Firefox, JAWS mit Chrome und VoiceOver mit Safari, um zu bestätigen, dass Screenreader die Inhalte ebenfalls korrekt ausgeben.
Test mit Bildschirmvergrößerung: Stellen Sie den Browserzoom auf 400 % oder aktivieren Sie die Vergrößerung auf Betriebssystemebene. Wiederholen Sie die Hover-Tests. Bestätigen Sie, dass ein Nutzer, der den Viewport schwenken muss, um den Tooltip zu erreichen, dies tun kann, ohne dass der Tooltip verschwindet.
JavaScript-Quellcode prüfen: Suchen Sie im Code nach setTimeout-, mouseleave-, mouseout- und blur-Event-Handlern, die mit der Logik zum Ausblenden von Overlays verknüpft sind. Bestätigen Sie, dass die Ausblendlogik nicht ausgelöst wird, während sich der Zeiger über dem Overlay befindet oder der Trigger den Fokus behält, und dass kein Auto-Schließen-Timer gesetzt ist.

Wie man es behebt

Nur-CSS-Tooltip, der bei mouseleave verschwindet – Falsch

<!-- Tooltip only shown via CSS :hover on parent; disappears as soon as
     the pointer moves off the trigger toward the tooltip text -->
<span class='tip-wrapper'>
  Info
  <span class='tooltip'>This is the tooltip content.</span>
</span>

<!-- CSS (illustrative) -->
<!--
.tooltip { display: none; }
.tip-wrapper:hover .tooltip { display: block; }
-->

Nur-CSS-Tooltip, der bei mouseleave verschwindet – Richtig

<!-- Correct: tooltip is also shown when the pointer is over the tooltip itself,
     and the gap between trigger and tooltip is covered so pointer movement
     does not accidentally dismiss the overlay. -->
<span class='tip-wrapper'>
  Info
  <span class='tooltip' role='tooltip' id='tip1'>This is the tooltip content.</span>
</span>

<!-- CSS (illustrative) -->
<!--
.tooltip { display: none; position: absolute; }
.tip-wrapper:hover .tooltip,
.tooltip:hover { display: block; }
/* Use padding or a transparent pseudo-element bridge between trigger and tooltip */
-->

JavaScript-Tooltip ohne Escape-Schließen – Falsch

<button aria-describedby='tip2' data-tooltip='Account balance details'>
  Balance
</button>
<div id='tip2' role='tooltip' hidden>Account balance details</div>

<script>
// Only mouseenter/mouseleave — no keyboard or Escape handling
document.querySelector('button').addEventListener('mouseenter', () => {
  document.getElementById('tip2').removeAttribute('hidden');
});
document.querySelector('button').addEventListener('mouseleave', () => {
  document.getElementById('tip2').setAttribute('hidden', '');
});
</script>

JavaScript-Tooltip ohne Escape-Schließen – Richtig

<button aria-describedby='tip2' data-tooltip='Account balance details'>
  Balance
</button>
<div id='tip2' role='tooltip' hidden>Account balance details</div>

<script>
const btn = document.querySelector('button');
const tip = document.getElementById('tip2');

function showTip() { tip.removeAttribute('hidden'); }
function hideTip() { tip.setAttribute('hidden', ''); }

// Show on hover and focus
btn.addEventListener('mouseenter', showTip);
btn.addEventListener('focus', showTip);

// Hide only when pointer leaves BOTH trigger AND tooltip
btn.addEventListener('mouseleave', (e) => {
  // Short delay allows pointer to reach the tooltip
  setTimeout(() => {
    if (!tip.matches(':hover') && !btn.matches(':hover')) hideTip();
  }, 100);
});
tip.addEventListener('mouseleave', () => {
  if (!btn.matches(':hover')) hideTip();
});

// Hide on blur (keyboard)
btn.addEventListener('blur', hideTip);

// Dismissible via Escape key — required by 1.4.13
document.addEventListener('keydown', (e) => {
  if (e.key === 'Escape' && !tip.hidden) hideTip();
});
</script>

Auto-schließender Tooltip mit setTimeout – Falsch

<button id='info-btn'>More info</button>
<div id='tip3' role='tooltip' hidden>Here is the additional information for this field.</div>

<script>
document.getElementById('info-btn').addEventListener('mouseenter', () => {
  const t = document.getElementById('tip3');
  t.removeAttribute('hidden');
  // Violation: auto-dismisses after 3 seconds regardless of user state
  setTimeout(() => t.setAttribute('hidden', ''), 3000);
});
</script>

Auto-schließender Tooltip mit setTimeout – Richtig

<button id='info-btn' aria-describedby='tip3'>More info</button>
<div id='tip3' role='tooltip' hidden>Here is the additional information for this field.</div>

<script>
const btn2 = document.getElementById('info-btn');
const tip3 = document.getElementById('tip3');

// No setTimeout — tooltip persists until user removes hover/focus or presses Escape
function show() { tip3.removeAttribute('hidden'); }
function hide() {
  setTimeout(() => {
    if (!tip3.matches(':hover') && !btn2.matches(':hover') && document.activeElement !== btn2) {
      tip3.setAttribute('hidden', '');
    }
  }, 100);
}

btn2.addEventListener('mouseenter', show);
btn2.addEventListener('focus', show);
btn2.addEventListener('mouseleave', hide);
btn2.addEventListener('blur', hide);
tip3.addEventListener('mouseleave', hide);
document.addEventListener('keydown', (e) => {
  if (e.key === 'Escape') tip3.setAttribute('hidden', '');
});
</script>

Häufige Fehler

Nur CSS-:hover verwenden, ohne die Lücke zwischen Trigger und Tooltip abzudecken: Wenn es auch nur eine Lücke von 1–2 px zwischen dem Trigger-Element und dem Tooltip-Container gibt, führt die Bewegung des Zeigers zwischen ihnen dazu, dass der Hover-Zustand verloren geht und der Tooltip ausgeblendet wird, bevor der Nutzer ihn erreicht. Verwenden Sie ein transparentes Pseudo-Element oder überlappende Innenabstände (Padding), um diese Lücke zu überbrücken.
Ausblendlogik an mouseleave des Triggers binden, ohne zu prüfen, ob der Zeiger auf den Tooltip gewechselt ist: Der Tooltip verschwindet in dem Moment, in dem der Cursor den Trigger verlässt, selbst wenn das Ziel der Tooltip selbst ist. Prüfen Sie immer tip.matches(':hover'), bevor Sie ausblenden, oder verwenden Sie eine kurze Verzögerung (Debounce).
Vergessen, Fokus- und Blur-Ereignisse zusätzlich zu mouseenter und mouseleave zu verdrahten: Nutzer, die ausschließlich mit der Tastatur arbeiten und zum Trigger tabben, sehen den Tooltip nie, wenn nur Mausereignisse verarbeitet werden; die zugehörigen Informationen sind ohne Maus vollständig unzugänglich.
Keinen Escape-Listener hinzufügen und davon ausgehen, dass Wegklicken ausreicht: Tastaturnutzer und Nutzer mit Bildschirmvergrößerung können nicht einfach „wegklicken“ von einem Overlay. Escape ist der erwartete und für dieses Kriterium erforderliche Mechanismus zum Schließen.
Den Escape-Listener nur am Trigger-Element statt am document platzieren: Wenn der Nutzer den Fokus auf den Tooltip oder ein anderes Element verschiebt, wird ein Listener, der auf den Trigger beschränkt ist, nicht ausgelöst. Der Escape-Handler muss am Dokument oder einem gemeinsamen Vorfahren hängen, der immer Tastaturereignisse erhält, wenn das Overlay geöffnet ist.
setTimeout verwenden, um Tooltips nach einer festen Dauer automatisch zu schließen: Jeder timerbasierte Schließvorgang, der ausgelöst wird, während sich der Zeiger noch auf dem Trigger oder Tooltip befindet oder während der Trigger noch den Tastaturfokus hat, verstößt direkt gegen die Beständigkeits-Anforderung. Entfernen Sie alle Auto-Schließen-Timer aus Hover-/Fokus-gesteuerten Overlays.
Tooltip-Sichtbarkeit ausschließlich über title-Attribut-Ersatz mit benutzerdefiniertem Styling steuern: Entwickler, die den nativen title-Tooltip entfernen und ihn durch eine benutzerdefinierte Version ersetzen, müssen alle drei Anforderungen von 1.4.13 selbst implementieren. Die Ausnahme für browsernative Tooltips gilt nicht für benutzerdefinierte JavaScript-Nachbildungen desselben Musters.
Kein Test mit Bildschirmvergrößerung bei 400 % Zoom: Ein Tooltip, der bei normalem Zoom zugänglich erscheint, kann bei hohen Zoomstufen teilweise außerhalb des Bildschirms liegen, sodass der Nutzer schwenken muss – und wenn er verschwindet, bevor der Nutzer dorthin schwenken kann, fällt ein Test, der bei 100 % Zoom bestanden wurde, unter realen Nutzungsbedingungen durch.
pointer-events: none auf den Tooltip-Container anwenden: Diese CSS-Eigenschaft verhindert, dass der Zeiger jemals als „über“ dem Tooltip betrachtet wird, wodurch es unmöglich wird, die Hoverbar-Anforderung zu erfüllen, unabhängig von anderer Logik. Tooltips, mit denen Nutzer interagieren oder über die sie einfach hovern müssen, um sie sichtbar zu halten, dürfen niemals pointer-events: none haben.
ARIA-role='tooltip' allein als ausreichend für die Konformität betrachten: Das Hinzufügen von role='tooltip' und aria-describedby ist wichtig für die Screenreader-Zugänglichkeit, adressiert aber eine andere Ebene des Problems. Diese ARIA-Attribute machen Inhalte nicht automatisch schließbar, hoverbar oder beständig – das Interaktionsverhalten muss weiterhin explizit implementiert werden.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

Die Präsidialverfügung 2025/10 der Türkei, veröffentlicht im Amtsblatt mit der Nummer 32933 am 21. Juni 2025, etabliert ein formelles Barrierefreiheitsmandat, das WCAG-Standards durch Verweis einbezieht. Die Verfügung verpflichtet die erfassten Stellen zur Umsetzung von Web-Barrierefreiheitsmaßnahmen im Einklang mit international anerkannten Richtlinien, und Konformität auf Level AA – zu dem auch WCAG 1.4.13 gehört – wird sowohl nachdrücklich empfohlen als auch für Stellen verlangt, die das Barrierefreiheitslogo (Erişilebilirlik Logosu) des Ministeriums für Familie und Soziale Dienste (Aile ve Sosyal Hizmetler Bakanlığı) anstreben.

Die Verfügung umfasst eine breite Palette von Akteurstypen, die in der Türkei tätig sind. Öffentliche Institutionen und staatliche Stellen auf allen Verwaltungsebenen sind verpflichtet, ihre digitalen Dienste barrierefrei zu gestalten. Im Privatsektor erstreckt sich die Verpflichtung auf E-Commerce-Plattformen, Banken und Finanzdienstleister, Krankenhäuser und private Gesundheitseinrichtungen, Telekommunikationsanbieter mit 200.000 oder mehr Abonnenten, Reisebüros, private Transportunternehmen und Privatschulen, die unter der Genehmigung des Ministeriums für Nationale Bildung (Millî Eğitim Bakanlığı) tätig sind.

WCAG 1.4.13 ist besonders relevant in türkischen digitalen Kontexten, in denen Tooltip- und Popover-Muster in E-Government-Portalen (wie e-Devlet-Integrationen), Banking- und Fintech-Oberflächen, die Gebühren- oder Zinsinformationen in Tooltips anzeigen, und Systemen zur Gesundheits-Terminvergabe, die zusätzliche Anweisungen über Hover-gesteuerte Overlays einblenden, weit verbreitet sind. Eine Banking-Plattform, die 1.4.13 nicht erfüllt, könnte verhindern, dass Kunden mit Sehbehinderung Zinsinformationen lesen, die über einen Tooltip bereitgestellt werden – ein Szenario mit Auswirkungen sowohl auf die Barrierefreiheit als auch auf den finanziellen Verbraucherschutz.

Für Stellen, die das Erişilebilirlik Logosu anstreben, umfasst ein Barrierefreiheitsaudit manuelle Tests von Hover- und Fokus-Verhalten gerade deshalb, weil automatisierte Tools diese Verstöße nicht erkennen können. Organisationen, die ein Barrierefreiheits-Overlay-SDK wie Accsible verwenden, sollten sicherstellen, dass alle vom Widget eingefügten Tooltips, geführten Tour-Popovers oder kontextuellen Hilfepanels, die vom SDK selbst eingeführt werden, vollständig mit allen drei Anforderungen von 1.4.13 konform sind – schließbar über Escape, hoverbar ohne Schließen und beständig bis zur Nutzeraktion. Andernfalls würden durch das Werkzeug, das die Barrierefreiheit verbessern soll, neue Barrieren eingeführt, was sowohl die regulatorische Konformität als auch das Vertrauen der Nutzer untergräbt.