Welche Barrierefreiheitsanforderungen gelten für Tooltips und Overlays?

Für Tooltips und Overlays gelten konkrete Barrierefreiheitsanforderungen aus den WCAG 2.2, die sicherstellen, dass diese Elemente für alle Nutzerinnen und Nutzer wahrnehmbar, bedienbar und verständlich sind. Das betrifft insbesondere die Tastaturbedienbarkeit, den Einsatz von ARIA-Attributen und die korrekte Fokussteuerung. Die folgenden Abschnitte beantworten die wichtigsten Fragen rund um dieses Thema.

Welche WCAG-Kriterien gelten speziell für Tooltips?

Tooltips fallen unter mehrere WCAG-Kriterien, vor allem unter Erfolgskriterium 1.4.13 (Inhalt bei Hover oder Fokus), das seit WCAG 2.1 gilt. Es legt fest, dass Inhalte, die bei Hover oder Tastaturfokus erscheinen, dauerhaft sichtbar bleiben, schließbar und bedienbar sein müssen, ohne dass das Element, das sie ausgelöst hat, verlassen werden muss.

Im Einzelnen verlangt WCAG 1.4.13, dass Tooltip-Inhalte drei Bedingungen erfüllen:

• Persistenz: Der Tooltip bleibt sichtbar, solange der Nutzer den Mauszeiger oder den Tastaturfokus nicht bewegt.
• Schließbarkeit: Nutzerinnen und Nutzer können den Tooltip schließen, ohne den Fokus zu verlieren, zum Beispiel durch Drücken der Escape-Taste.
• Erreichbarkeit mit dem Zeiger: Der Tooltip selbst muss mit der Maus erreichbar sein, ohne zu verschwinden, da Nutzer mit Vergrößerungssoftware oft den Mauszeiger auf den Tooltip bewegen müssen, um ihn zu lesen.

Zusätzlich greift Erfolgskriterium 4.1.3 (Statusmeldungen), wenn ein Tooltip Statusänderungen kommuniziert. Auch Kriterium 2.1.1 (Tastatur) ist relevant: Alle Funktionen, die per Maus erreichbar sind, müssen auch per Tastatur zugänglich sein. Tooltips, die ausschließlich bei Hover erscheinen und per Tastatur nicht erreichbar sind, verstoßen gegen dieses Kriterium. Wer eine Barrierefreiheitsprüfung durchführt, sollte diese Kriterien systematisch prüfen.

Was sind die häufigsten Barrierefreiheitsfehler bei Overlays?

Die häufigsten Barrierefreiheitsfehler bei Overlays betreffen fehlende Fokussteuerung, fehlende ARIA-Attribute und mangelnde Schließbarkeit per Tastatur. Diese Fehler machen Overlays für Screenreader-Nutzerinnen und -Nutzer sowie für Menschen, die ausschließlich die Tastatur verwenden, unzugänglich.

In der Praxis treten folgende Probleme besonders häufig auf:

• Fehlender Fokus-Trap: Wird ein modales Overlay geöffnet, muss der Tastaturfokus im Overlay verbleiben. Fehlt dieser sogenannte Focus-Trap, können Nutzerinnen und Nutzer unbemerkt hinter das Overlay navigieren und verlieren die Orientierung.
• Kein Fokus-Rücksprung: Nach dem Schließen eines Overlays muss der Fokus zu dem Element zurückkehren, das das Overlay geöffnet hat. Fehlt dieser Rücksprung, ist die Navigation für Tastaturnutzer desorientierend.
• Fehlende Escape-Funktionalität: Modale Overlays müssen per Escape-Taste schließbar sein. Ist das nicht implementiert, sind Nutzerinnen und Nutzer ohne Maus in einem Overlay gefangen.
• Hintergrundinhalt bleibt lesbar für Screenreader: Bei modalen Overlays muss der Hintergrundinhalt für Screenreader ausgeblendet werden, typischerweise über aria-hidden="true" auf dem Hauptinhalt.
• Unzureichende Kontraste: Overlay-Inhalte, insbesondere Texte auf halbtransparenten Hintergründen, unterschreiten häufig das geforderte Kontrastverhältnis von 4,5:1 für normalen Text.
• Fehlende Schließen-Schaltfläche: Overlays ohne sichtbare und semantisch korrekte Schließen-Schaltfläche sind für viele Nutzergruppen nicht bedienbar.

Wie unterscheiden sich modale und nicht-modale Overlays in den Anforderungen?

Modale Overlays blockieren die Interaktion mit dem restlichen Seiteninhalt und stellen damit deutlich höhere Anforderungen an Fokussteuerung und ARIA-Implementierung als nicht-modale Overlays, die parallel zur restlichen Seite bedienbar bleiben.

Anforderungen an modale Overlays

Modale Dialoge, zum Beispiel Bestätigungsfenster oder Cookie-Banner mit Pflichtinteraktion, erfordern einen vollständigen Focus-Trap. Der Tastaturfokus darf das Overlay nicht verlassen, solange es geöffnet ist. Das bedeutet, dass Tab und Shift+Tab den Fokus innerhalb des Overlays zirkulieren lassen müssen. Der Hintergrundinhalt muss über aria-hidden="true" für Screenreader unsichtbar gemacht werden. Das Overlay selbst erhält die Rolle dialog und ein zugängliches Label über aria-labelledby oder aria-label. Beim Öffnen wird der Fokus auf das Overlay oder ein erstes interaktives Element darin gesetzt.

Anforderungen an nicht-modale Overlays

Nicht-modale Overlays, etwa ausklappbare Menüs, Hinweisbanner oder Seitenleisten, erfordern keinen Focus-Trap. Nutzerinnen und Nutzer sollen weiterhin frei auf der Seite navigieren können. Dennoch gelten Anforderungen: Das Overlay muss per Tastatur erreichbar und schließbar sein, und der Fokus muss logisch durch die Seite fließen. Nicht-modale Dialoge erhalten die ARIA-Rolle dialog mit dem Attribut aria-modal="false" oder alternativ andere passende Rollen wie status oder alert, abhängig vom Inhalt.

Welche ARIA-Attribute sind für Tooltips und Overlays erforderlich?

Für Tooltips ist role="tooltip" in Kombination mit aria-describedby am auslösenden Element erforderlich. Für Overlays gelten je nach Typ unterschiedliche Rollen und Attribute, wobei role="dialog" mit aria-labelledby und aria-modal die zentralen Bausteine für modale Dialoge sind.

Im Detail gelten folgende Empfehlungen:

• Tooltips: Das auslösende Element erhält aria-describedby mit der ID des Tooltip-Elements. Das Tooltip-Element selbst erhält role="tooltip". Tooltips sollten nicht ausschließlich visuelle Informationen transportieren, die nirgendwo sonst zugänglich sind.
• Modale Dialoge: role="dialog", aria-modal="true", aria-labelledby (verweist auf die Überschrift des Dialogs) und gegebenenfalls aria-describedby für eine Beschreibung des Dialogzwecks.
• Alert-Dialoge: Wenn ein modales Overlay eine Warnung oder Fehlermeldung enthält, die sofortige Aufmerksamkeit erfordert, kommt role="alertdialog" zum Einsatz.
• Nicht-modale Hinweise: Statusmeldungen, die automatisch erscheinen, erhalten role="status" oder role="alert", damit Screenreader sie automatisch vorlesen.

Falsch eingesetzte ARIA-Attribute können die Barrierefreiheit verschlechtern statt verbessern. Der WAI-ARIA Authoring Practices Guide des W3C bietet detaillierte Implementierungsbeispiele für jeden dieser Mustertypen.

Wie lässt sich die Barrierefreiheit von Tooltips und Overlays testen?

Die Barrierefreiheit von Tooltips und Overlays lässt sich durch eine Kombination aus automatisierten Tests und manuellen Prüfungen testen. Automatisierte Tools erkennen typischerweise fehlende ARIA-Attribute und Kontrastprobleme, während manuelle Tests die Tastaturbedienbarkeit und die Screenreader-Ausgabe abdecken.

Für einen strukturierten Test empfiehlt sich folgendes Vorgehen:

1. Automatisierter Scan: Ein Barrierefreiheitstest-Tool wie decareto prüft den HTML-Code auf fehlende ARIA-Attribute, Kontrastprobleme und strukturelle Fehler. Dieser Schritt deckt einen erheblichen Teil technischer Fehler ab, typischerweise schätzungsweise 30 bis 50 Prozent aller möglichen Probleme.
2. Tastaturtest: Navigieren Sie ausschließlich mit der Tastatur durch die Seite. Prüfen Sie, ob Tooltips per Tab-Taste erreichbar sind, ob Overlays korrekt geöffnet und per Escape geschlossen werden können und ob der Fokus nach dem Schließen an die richtige Stelle zurückkehrt.
3. Screenreader-Test: Testen Sie mit einem Screenreader wie NVDA (Windows), JAWS oder VoiceOver (macOS/iOS), ob Tooltips und Overlays korrekt angesagt werden und ob die ARIA-Attribute die erwartete Ausgabe erzeugen.
4. Kontrast-Prüfung: Prüfen Sie Texte innerhalb von Overlays auf ausreichende Kontrastverhältnisse, besonders bei halbtransparenten Hintergründen.

Da nicht alle Barrierefreiheitsprobleme automatisiert erkennbar sind, ist die manuelle Prüfung unverzichtbar. Automatisierte Tests liefern jedoch eine wertvolle erste Einschätzung und helfen dabei, offensichtliche Fehler schnell zu identifizieren, bevor ein aufwendiger manueller Test durchgeführt wird.

Gelten diese Anforderungen auch unter dem BFSG?

Ja, die Anforderungen an Tooltips und Overlays gelten auch unter dem Barrierefreiheitsstärkungsgesetz (BFSG). Das BFSG, das seit Juni 2025 für viele Produkte und Dienstleistungen im privaten Sektor gilt, verweist auf die harmonisierten europäischen Normen, die ihrerseits auf den WCAG basieren.

Das BFSG setzt die EU-Richtlinie 2019/882 (European Accessibility Act) in deutsches Recht um. Für Websites und digitale Dienste bedeutet das in der Praxis, dass die Konformität mit WCAG 2.1 auf Level AA als Maßstab herangezogen wird. Alle oben beschriebenen Anforderungen an Fokussteuerung, ARIA-Attribute und Tastaturbedienbarkeit sind damit auch rechtlich relevant.

Besonders betroffen sind Unternehmen, die digitale Produkte oder Dienstleistungen im B2C-Bereich anbieten, darunter Online-Shops, Banking-Anwendungen und Buchungsportale. Öffentliche Stellen unterliegen bereits seit längerem der EU-Richtlinie 2016/2102, die ebenfalls WCAG-Konformität verlangt. Für alle Betroffenen gilt: Tooltips und Overlays sind keine Randthemen der Barrierefreiheit, sondern häufig genutzte Interaktionsmuster, die bei fehlerhafter Implementierung erhebliche Barrieren erzeugen. Eine regelmäßige BITV-Prüfung hilft dabei, Schwachstellen frühzeitig zu erkennen.

Wie decareto Sie beim Testen von Tooltips und Overlays unterstützt

Wir bei decareto bieten eine automatisierte Accessibility-Software, die Websites systematisch auf Barrierefreiheitsprobleme prüft, darunter auch typische Fehler bei Tooltips und Overlays. Unsere Plattform unterstützt Agenturen, Compliance-Teams und Datenschutzbeauftragte dabei, den Prüfaufwand erheblich zu reduzieren und Ergebnisse nachvollziehbar zu dokumentieren.

Konkret bietet decareto dabei folgende Funktionen:

• Automatisierter Barrierefreiheits-Scan auf Basis von axe-core, orientiert an WCAG 2.1 und 2.2, BITV und BFSG, mit Erkennung von ARIA-Fehlern, Kontrastproblemen und strukturellen HTML-Fehlern
• Priorisierung nach Schweregrad, sodass kritische Probleme wie fehlende Focus-Traps oder nicht schließbare Overlays sofort erkennbar sind
• Manuelle Problemerfassung direkt im Tool, um Befunde aus manuellen Tests und Screenreader-Prüfungen zu ergänzen und zu dokumentieren
• Überwachung von Hunderten Websites mit automatischen Benachrichtigungen bei Änderungen, damit neue Barrieren nicht unbemerkt bleiben
• Teilbare Reports mit Whitelabel-Option für externe Dienstleister, die Ergebnisse unter eigenem Logo präsentieren möchten

Möchten Sie Ihre Website auf Barrierefreiheit prüfen und dabei auch Tooltips und Overlays systematisch unter die Lupe nehmen? Jetzt kostenlos starten und einen ersten Scan durchführen.

Dieser Text wurde mit Hilfe von KI erstellt und könnte Fehler beinhalten.

Ähnliche Artikel

• Was sind die häufigsten Fehler bei ARIA-Labels auf Websites?
• Welche Barrierefreiheitspflichten gelten für Web-Agenturen seit dem BFSG?
• Was prüft ein WCAG Contrast Checker bei Textelementen?
• Welchen Nutzen bietet Single Sign-On (SSO) für Compliance-Teams bei DSGVO-Prüfungen?
• Welche Datenschutzlücken entstehen durch veraltete Blog-Beiträge mit alten Tracking-Skripten?