F\u00fcr Tooltips und Overlays gelten konkrete Barrierefreiheitsanforderungen aus den WCAG 2.2, die sicherstellen, dass diese Elemente f\u00fcr alle Nutzerinnen und Nutzer wahrnehmbar, bedienbar und verst\u00e4ndlich 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.<\/p>\n
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\u00dfbar und bedienbar sein m\u00fcssen, ohne dass das Element, das sie ausgel\u00f6st hat, verlassen werden muss.<\/p>\n
Im Einzelnen verlangt WCAG 1.4.13, dass Tooltip-Inhalte drei Bedingungen erf\u00fcllen:<\/p>\n
Zus\u00e4tzlich greift Erfolgskriterium 4.1.3 (Statusmeldungen), wenn ein Tooltip Status\u00e4nderungen kommuniziert. Auch Kriterium 2.1.1 (Tastatur) ist relevant: Alle Funktionen, die per Maus erreichbar sind, m\u00fcssen auch per Tastatur zug\u00e4nglich sein. Tooltips, die ausschlie\u00dflich bei Hover erscheinen und per Tastatur nicht erreichbar sind, versto\u00dfen gegen dieses Kriterium. Wer eine Barrierefreiheitspr\u00fcfung<\/a> durchf\u00fchrt, sollte diese Kriterien systematisch pr\u00fcfen.<\/p>\n Die h\u00e4ufigsten Barrierefreiheitsfehler bei Overlays betreffen fehlende Fokussteuerung, fehlende ARIA-Attribute und mangelnde Schlie\u00dfbarkeit per Tastatur. Diese Fehler machen Overlays f\u00fcr Screenreader-Nutzerinnen und -Nutzer sowie f\u00fcr Menschen, die ausschlie\u00dflich die Tastatur verwenden, unzug\u00e4nglich.<\/p>\n In der Praxis treten folgende Probleme besonders h\u00e4ufig auf:<\/p>\n Modale Overlays blockieren die Interaktion mit dem restlichen Seiteninhalt und stellen damit deutlich h\u00f6here Anforderungen an Fokussteuerung und ARIA-Implementierung als nicht-modale Overlays, die parallel zur restlichen Seite bedienbar bleiben.<\/p>\n Modale Dialoge, zum Beispiel Best\u00e4tigungsfenster oder Cookie-Banner mit Pflichtinteraktion, erfordern einen vollst\u00e4ndigen Focus-Trap. Der Tastaturfokus darf das Overlay nicht verlassen, solange es ge\u00f6ffnet ist. Das bedeutet, dass Tab und Shift+Tab den Fokus innerhalb des Overlays zirkulieren lassen m\u00fcssen. Der Hintergrundinhalt muss \u00fcber Nicht-modale Overlays, etwa ausklappbare Men\u00fcs, Hinweisbanner oder Seitenleisten, erfordern keinen Focus-Trap. Nutzerinnen und Nutzer sollen weiterhin frei auf der Seite navigieren k\u00f6nnen. Dennoch gelten Anforderungen: Das Overlay muss per Tastatur erreichbar und schlie\u00dfbar sein, und der Fokus muss logisch durch die Seite flie\u00dfen. Nicht-modale Dialoge erhalten die ARIA-Rolle F\u00fcr Tooltips ist Im Detail gelten folgende Empfehlungen:<\/p>\n Falsch eingesetzte ARIA-Attribute k\u00f6nnen die Barrierefreiheit verschlechtern statt verbessern. Der WAI-ARIA Authoring Practices Guide des W3C bietet detaillierte Implementierungsbeispiele f\u00fcr jeden dieser Mustertypen.<\/p>\n Die Barrierefreiheit von Tooltips und Overlays l\u00e4sst sich durch eine Kombination aus automatisierten Tests und manuellen Pr\u00fcfungen testen. Automatisierte Tools erkennen typischerweise fehlende ARIA-Attribute und Kontrastprobleme, w\u00e4hrend manuelle Tests die Tastaturbedienbarkeit und die Screenreader-Ausgabe abdecken.<\/p>\n F\u00fcr einen strukturierten Test empfiehlt sich folgendes Vorgehen:<\/p>\n Da nicht alle Barrierefreiheitsprobleme automatisiert erkennbar sind, ist die manuelle Pr\u00fcfung unverzichtbar. Automatisierte Tests liefern jedoch eine wertvolle erste Einsch\u00e4tzung und helfen dabei, offensichtliche Fehler schnell zu identifizieren, bevor ein aufwendiger manueller Test durchgef\u00fchrt wird.<\/p>\n Ja, die Anforderungen an Tooltips und Overlays gelten auch unter dem Barrierefreiheitsst\u00e4rkungsgesetz (BFSG). Das BFSG, das seit Juni 2025 f\u00fcr viele Produkte und Dienstleistungen im privaten Sektor gilt, verweist auf die harmonisierten europ\u00e4ischen Normen, die ihrerseits auf den WCAG basieren.<\/p>\n Das BFSG setzt die EU-Richtlinie 2019\/882 (European Accessibility Act) in deutsches Recht um. F\u00fcr Websites und digitale Dienste bedeutet das in der Praxis, dass die Konformit\u00e4t mit WCAG 2.1 auf Level AA als Ma\u00dfstab herangezogen wird. Alle oben beschriebenen Anforderungen an Fokussteuerung, ARIA-Attribute und Tastaturbedienbarkeit sind damit auch rechtlich relevant.<\/p>\n Besonders betroffen sind Unternehmen, die digitale Produkte oder Dienstleistungen im B2C-Bereich anbieten, darunter Online-Shops, Banking-Anwendungen und Buchungsportale. \u00d6ffentliche Stellen unterliegen bereits seit l\u00e4ngerem der EU-Richtlinie 2016\/2102, die ebenfalls WCAG-Konformit\u00e4t verlangt. F\u00fcr alle Betroffenen gilt: Tooltips und Overlays sind keine Randthemen der Barrierefreiheit, sondern h\u00e4ufig genutzte Interaktionsmuster, die bei fehlerhafter Implementierung erhebliche Barrieren erzeugen. Eine regelm\u00e4\u00dfige BITV-Pr\u00fcfung<\/a> hilft dabei, Schwachstellen fr\u00fchzeitig zu erkennen.<\/p>\n Wir bei decareto bieten eine automatisierte Accessibility-Software, die Websites systematisch auf Barrierefreiheitsprobleme pr\u00fcft, darunter auch typische Fehler bei Tooltips und Overlays. Unsere Plattform unterst\u00fctzt Agenturen, Compliance-Teams und Datenschutzbeauftragte dabei, den Pr\u00fcfaufwand erheblich zu reduzieren und Ergebnisse nachvollziehbar zu dokumentieren.<\/p>\n Konkret bietet decareto dabei folgende Funktionen:<\/p>\nWas sind die h\u00e4ufigsten Barrierefreiheitsfehler bei Overlays?<\/h2>\n
\n
aria-hidden=\"true\"<\/code> auf dem Hauptinhalt.<\/li>\nWie unterscheiden sich modale und nicht-modale Overlays in den Anforderungen?<\/h2>\n
Anforderungen an modale Overlays<\/h3>\n
aria-hidden=\"true\"<\/code> f\u00fcr Screenreader unsichtbar gemacht werden. Das Overlay selbst erh\u00e4lt die Rolle dialog<\/code> und ein zug\u00e4ngliches Label \u00fcber aria-labelledby<\/code> oder aria-label<\/code>. Beim \u00d6ffnen wird der Fokus auf das Overlay oder ein erstes interaktives Element darin gesetzt.<\/p>\nAnforderungen an nicht-modale Overlays<\/h3>\n
dialog<\/code> mit dem Attribut aria-modal=\"false\"<\/code> oder alternativ andere passende Rollen wie status<\/code> oder alert<\/code>, abh\u00e4ngig vom Inhalt.<\/p>\nWelche ARIA-Attribute sind f\u00fcr Tooltips und Overlays erforderlich?<\/h2>\n
role=\"tooltip\"<\/code> in Kombination mit aria-describedby<\/code> am ausl\u00f6senden Element erforderlich. F\u00fcr Overlays gelten je nach Typ unterschiedliche Rollen und Attribute, wobei role=\"dialog\"<\/code> mit aria-labelledby<\/code> und aria-modal<\/code> die zentralen Bausteine f\u00fcr modale Dialoge sind.<\/p>\n\n
aria-describedby<\/code> mit der ID des Tooltip-Elements. Das Tooltip-Element selbst erh\u00e4lt role=\"tooltip\"<\/code>. Tooltips sollten nicht ausschlie\u00dflich visuelle Informationen transportieren, die nirgendwo sonst zug\u00e4nglich sind.<\/li>\nrole=\"dialog\"<\/code>, aria-modal=\"true\"<\/code>, aria-labelledby<\/code> (verweist auf die \u00dcberschrift des Dialogs) und gegebenenfalls aria-describedby<\/code> f\u00fcr eine Beschreibung des Dialogzwecks.<\/li>\nrole=\"alertdialog\"<\/code> zum Einsatz.<\/li>\nrole=\"status\"<\/code> oder role=\"alert\"<\/code>, damit Screenreader sie automatisch vorlesen.<\/li>\n<\/ul>\nWie l\u00e4sst sich die Barrierefreiheit von Tooltips und Overlays testen?<\/h2>\n
\n
Gelten diese Anforderungen auch unter dem BFSG?<\/h2>\n
Wie decareto Sie beim Testen von Tooltips und Overlays unterst\u00fctzt<\/h2>\n
\n