Für interaktive Elemente wie Schaltflächen, Links, Formulare und Navigationskomponenten gelten nach den WCAG-Richtlinien besondere Barrierefreiheitsanforderungen. Sie müssen wahrnehmbar, bedienbar, verständlich und robust gestaltet sein. Das bedeutet konkret: klare Beschriftungen, ausreichende Kontraste, vollständige Tastaturbedienbarkeit und kompatible Implementierung mit assistiven Technologien wie Screenreadern. Die folgenden Abschnitte beantworten die wichtigsten Fragen rund um interaktive Elemente und digitale Barrierefreiheit.
Was gilt als interaktives Element im Sinne der Barrierefreiheit?
Als interaktive Elemente gelten im Sinne der Barrierefreiheit alle Bestandteile einer Website, mit denen Nutzende aktiv interagieren können. Dazu zählen Links, Schaltflächen (Buttons), Formulare, Dropdown-Menüs, Tabs, Akkordeons, Dialoge, Schieberegler und Mediensteuerungen. Entscheidend ist, dass diese Elemente für alle Nutzenden zugänglich und bedienbar sein müssen, unabhängig von körperlichen oder sensorischen Einschränkungen.
Die WCAG unterscheiden zwischen nativen HTML-Elementen, die von Browsern und assistiven Technologien von Haus aus unterstützt werden, und benutzerdefinierten Komponenten, die mit JavaScript und ARIA-Attributen nachgerüstet werden müssen. Ein natives <button>-Element ist von Haus aus tastaturbedienbar und für Screenreader erkennbar. Ein <div>, das optisch wie ein Button aussieht, hingegen nicht, sofern es nicht entsprechend ausgezeichnet wird.
Besonders im modernen Webdesign, das stark auf JavaScript-Frameworks und dynamische Inhalte setzt, entstehen häufig Barriereprobleme bei interaktiven Elementen, weil die technische Umsetzung nicht konsequent auf Zugänglichkeit ausgerichtet ist.
Welche WCAG-Kriterien gelten speziell für Schaltflächen und Links?
Für Schaltflächen und Links gelten mehrere konkrete WCAG-Erfolgskriterien, die vor allem Erkennbarkeit, Beschriftung und Bedienbarkeit betreffen. Die wichtigsten sind Kriterium 2.4.6 (Überschriften und Beschriftungen), 2.4.4 (Linkzweck), 4.1.2 (Name, Rolle, Wert) sowie 1.4.3 (Kontrast, Minimum). Links müssen außerdem optisch vom umgebenden Text unterscheidbar sein, was Kriterium 1.4.1 regelt.
Anforderungen an Schaltflächen
Jede Schaltfläche muss eine aussagekräftige, programmatisch ermittelbare Beschriftung besitzen. Ein Icon-Button ohne sichtbaren Text benötigt zwingend ein aria-label– oder aria-labelledby-Attribut, damit Screenreader den Zweck vorlesen können. Der Kontrast zwischen Text und Hintergrundfarbe muss mindestens 4,5:1 betragen, bei großem Text mindestens 3:1. Fokuszustände müssen sichtbar sein, damit Tastaturnutzende erkennen, welche Schaltfläche gerade aktiv ist.
Anforderungen an Links
Links müssen ihren Zweck aus dem Linktext allein oder aus dem unmittelbaren Kontext heraus verständlich machen. Texte wie „hier klicken“ oder „mehr erfahren“ sind problematisch, weil sie ohne Kontext keine Information darüber liefern, wohin der Link führt. Screenreader-Nutzende navigieren häufig durch Auflistungen aller Links auf einer Seite, weshalb jeder Linktext für sich allein verständlich sein sollte. Außerdem dürfen Links nicht ausschließlich über Farbe von normalem Text unterschieden werden, ohne einen zusätzlichen visuellen Hinweis wie Unterstreichung zu verwenden.
Wie müssen Formulare barrierefrei gestaltet sein?
Barrierefreie Formulare erfordern klare, programmatisch verknüpfte Beschriftungen für jedes Eingabefeld, verständliche Fehlermeldungen und eine vollständige Tastaturbedienbarkeit. Jedes Formularfeld muss ein zugehöriges <label>-Element besitzen, das mit dem Feld über das for-Attribut verbunden ist. Placeholder-Texte allein reichen nicht aus, da sie beim Tippen verschwinden und von Screenreadern nicht zuverlässig vorgelesen werden.
Fehlermeldungen sind ein besonders kritischer Punkt. Tritt ein Fehler auf, muss er nach WCAG 3.3.1 in Textform beschrieben werden, und nach 3.3.3 sollte möglichst ein Korrekturvorschlag gegeben werden. Die Fehlermeldung muss programmatisch mit dem betroffenen Feld verknüpft sein, etwa über aria-describedby, damit Screenreader sie beim Fokussieren des Feldes vorlesen. Rein farbliche Markierungen wie ein roter Rahmen reichen nicht aus.
Pflichtfelder müssen als solche kenntlich gemacht werden, und zwar nicht nur visuell, sondern auch im Code, zum Beispiel durch das required-Attribut oder ein aria-required="true". Komplexe Formulare mit mehreren Schritten sollten den aktuellen Fortschritt anzeigen und es ermöglichen, eingegebene Daten vor dem Absenden zu überprüfen und zu korrigieren.
Welche Anforderungen gelten für Tastatur- und Fokussteuerung?
Alle interaktiven Elemente einer Website müssen ausschließlich mit der Tastatur erreichbar und bedienbar sein. Das ist in WCAG-Kriterium 2.1.1 (Tastatur) verankert und gilt als eine der grundlegendsten Barrierefreiheitsanforderungen. Nutzende, die keine Maus verwenden können, etwa wegen motorischer Einschränkungen, sind vollständig auf Tastaturnavigation angewiesen.
Konkret bedeutet das: Jedes interaktive Element muss per Tab-Taste erreichbar sein, und die Tab-Reihenfolge muss logisch und nachvollziehbar sein. Der aktuelle Fokus muss jederzeit sichtbar sein, was durch WCAG 2.4.7 (Fokus sichtbar) gefordert wird. In WCAG 2.2 wurde dieses Kriterium mit 2.4.11 (Fokus nicht verdeckt, Minimum) und 2.4.12 (Fokus nicht verdeckt, erweitert) weiter verschärft.
Besondere Herausforderungen entstehen bei modalen Dialogen und Overlays. Öffnet sich ein Dialog, muss der Fokus in diesen Dialog verschoben werden, und Nutzende dürfen nicht in den Hintergrundinhalt tabben können, solange der Dialog geöffnet ist. Beim Schließen des Dialogs muss der Fokus auf das auslösende Element zurückkehren. Dieses Muster, auch als „Focus Trap“ bezeichnet, ist für viele Entwicklungsteams eine häufige Fehlerquelle. Automatisierte Barrierefreiheitstests können helfen, solche strukturellen Probleme frühzeitig zu identifizieren.
Wie wirkt sich das BFSG auf interaktive Website-Elemente aus?
Das Barrierefreiheitsstärkungsgesetz (BFSG), das die EU-Richtlinie zum European Accessibility Act in deutsches Recht umsetzt, verpflichtet seit dem 28. Juni 2025 viele Unternehmen dazu, digitale Produkte und Dienstleistungen barrierefrei zu gestalten. Für interaktive Website-Elemente bedeutet das, dass die Anforderungen der WCAG 2.1 auf Konformitätsstufe AA als technischer Referenzstandard gelten.
Betroffen sind insbesondere Unternehmen, die digitale Dienstleistungen für Verbraucherinnen und Verbraucher anbieten, etwa im E-Commerce, im Banking oder bei Buchungsportalen. Für diese Unternehmen sind zugängliche Formulare, bedienbare Schaltflächen und korrekt implementierte Navigationsstrukturen keine optionale Verbesserung mehr, sondern eine gesetzliche Anforderung.
Praktisch relevant ist das BFSG vor allem für interaktive Kernfunktionen: Ein Checkout-Prozess, der ohne Maus nicht abschließbar ist, ein Login-Formular ohne korrekte Beschriftungen oder ein Produktfilter, der für Screenreader-Nutzende nicht bedienbar ist, können rechtliche Risiken darstellen. Unternehmen sollten ihre interaktiven Elemente systematisch prüfen lassen und Schwachstellen priorisiert beheben. Hinweis: Ob eine Website die gesetzlichen Anforderungen des BFSG vollständig erfüllt, kann nur durch eine fachkundige Prüfung festgestellt werden, die sowohl automatisierte als auch manuelle Tests umfasst.
Wie lassen sich Barrierefreiheitsprobleme bei interaktiven Elementen systematisch prüfen?
Barrierefreiheitsprobleme bei interaktiven Elementen lassen sich durch eine Kombination aus automatisierten Scans und manuellen Tests systematisch identifizieren. Automatisierte Tools prüfen den HTML-Code auf bekannte Fehler wie fehlende Labels, unzureichende Kontraste oder falsch verwendete ARIA-Attribute. Manuelle Tests decken darüber hinaus Probleme auf, die automatisch nicht erkennbar sind, etwa die logische Tab-Reihenfolge oder das korrekte Verhalten von Fokusfallen in Dialogen.
Schätzungen aus der Forschungspraxis, unter anderem von der Universität Bielefeld, gehen davon aus, dass automatisierte Tests etwa 30 bis 50 Prozent aller Barriereprobleme abdecken können. Das bedeutet: Automatisierte Prüfungen sind ein wichtiger erster Schritt, ersetzen aber keine vollständige manuelle Prüfung nach dem BITV-Prüfverfahren.
Ein sinnvoller Prüfprozess sieht typischerweise so aus:
- Automatisierten Scan durchführen: Grobe, häufig vorkommende Fehler wie fehlende Alt-Texte, Kontrastprobleme oder nicht beschriftete Buttons werden schnell und flächendeckend identifiziert.
- Ergebnisse nach Schweregrad priorisieren: Kritische Probleme, die grundlegende Funktionen blockieren, werden zuerst behoben. Geringfügige Probleme können nachrangig behandelt werden.
- Manuelle Tests ergänzen: Tastaturnavigation, Screenreader-Verhalten, Zoom-Fähigkeit und die Verständlichkeit von Inhalten werden manuell geprüft.
- Behebung dokumentieren und nachverfolgen: Gefundene Probleme werden mit konkreten Handlungsempfehlungen an Entwicklungsteams übergeben, und die Behebung wird dokumentiert.
- Regelmäßig überwachen: Da Websites sich kontinuierlich verändern, sollte die Prüfung kein einmaliges Ereignis sein, sondern in regelmäßigen Abständen wiederholt werden.
Für die BITV-Prüfung einer Website empfiehlt es sich, zunächst mit einem automatisierten Scan grobe Fehler zu beseitigen, bevor ein aufwändiger manueller Test in Auftrag gegeben wird. Das spart Zeit und Kosten.
So unterstützt decareto bei der Prüfung interaktiver Elemente
Wir bei decareto haben unsere Accessibility-Software gezielt dafür entwickelt, Barrierefreiheitsprobleme bei interaktiven Elementen schnell und strukturiert sichtbar zu machen. Das leistet unsere Plattform konkret:
- Automatisierter Scan nach WCAG und BITV: Wir prüfen Ihre Website auf Basis der Open-Source-Bibliothek axe-core und identifizieren Fehler bei Schaltflächen, Links, Formularen, ARIA-Attributen und Farbkontrasten, orientiert an WCAG 2.1 und vorbereitet auf WCAG 2.2.
- Priorisierung nach Schweregrad: Gefundene Probleme werden nach Kritikalität eingestuft, von kritischen Blockern bis zu geringfügigen Optimierungen, damit Ihr Team weiß, wo es zuerst ansetzen soll.
- Konkrete Handlungsempfehlungen: Zu jedem Problem liefern wir verständliche Hinweise zur Behebung, inklusive Code-Beispielen, die Entwicklerinnen und Entwickler direkt umsetzen können.
- Manuelle Tests integrieren: Probleme, die automatisch nicht erkennbar sind, können manuell erfasst und dem Report hinzugefügt werden, etwa Tastaturnavigationsprobleme oder die Verstehbarkeit von Inhalten.
- Dauerhaftes Monitoring: Wir überwachen Ihre Website kontinuierlich und benachrichtigen Sie automatisch, wenn neue Barrieren entstehen, etwa nach einem Website-Update.
- Report teilen und Barrierefreiheitserklärung vorbereiten: Reports lassen sich direkt mit Kundinnen und Kunden teilen, auch unter eigenem Logo per Whitelabel-Funktion.
Möchten Sie Ihre Website auf Barrierefreiheit prüfen und interaktive Elemente systematisch auf WCAG-Konformität testen? Jetzt kostenlos starten und noch heute einen ersten Accessibility-Report erstellen.
Dieser Text wurde mit Hilfe von KI erstellt und könnte Fehler beinhalten.
Ähnliche Artikel
- Wie setzt man einen Consent-Banner DSGVO-konform um und welche Fehler sollte man unbedingt vermeiden?
- Welche Unterseiten und Bereiche werden bei einem DSGVO-Scan oft übersehen?
- Welche Datenschutzlücken entstehen durch veraltete Blog-Beiträge mit alten Tracking-Skripten?
- Was sind häufige WCAG-Fehler bei Tabellen auf Websites?
- Welche DSGVO-Anforderungen gelten für internationale Websites mit deutschsprachigem Publikum?
