F\u00fcr interaktive Elemente wie Schaltfl\u00e4chen, Links, Formulare und Navigationskomponenten gelten nach den WCAG-Richtlinien besondere Barrierefreiheitsanforderungen. Sie m\u00fcssen wahrnehmbar, bedienbar, verst\u00e4ndlich und robust gestaltet sein. Das bedeutet konkret: klare Beschriftungen, ausreichende Kontraste, vollst\u00e4ndige Tastaturbedienbarkeit und kompatible Implementierung mit assistiven Technologien wie Screenreadern. Die folgenden Abschnitte beantworten die wichtigsten Fragen rund um interaktive Elemente und digitale Barrierefreiheit.<\/p>\n
Als interaktive Elemente gelten im Sinne der Barrierefreiheit alle Bestandteile einer Website, mit denen Nutzende aktiv interagieren k\u00f6nnen. Dazu z\u00e4hlen Links, Schaltfl\u00e4chen (Buttons), Formulare, Dropdown-Men\u00fcs, Tabs, Akkordeons, Dialoge, Schieberegler und Mediensteuerungen. Entscheidend ist, dass diese Elemente f\u00fcr alle Nutzenden zug\u00e4nglich und bedienbar sein m\u00fcssen, unabh\u00e4ngig von k\u00f6rperlichen oder sensorischen Einschr\u00e4nkungen.<\/p>\n
Die WCAG unterscheiden zwischen nativen HTML-Elementen, die von Browsern und assistiven Technologien von Haus aus unterst\u00fctzt werden, und benutzerdefinierten Komponenten, die mit JavaScript und ARIA-Attributen nachger\u00fcstet werden m\u00fcssen. Ein natives Besonders im modernen Webdesign, das stark auf JavaScript-Frameworks und dynamische Inhalte setzt, entstehen h\u00e4ufig Barriereprobleme bei interaktiven Elementen, weil die technische Umsetzung nicht konsequent auf Zug\u00e4nglichkeit ausgerichtet ist.<\/p>\n F\u00fcr Schaltfl\u00e4chen und Links gelten mehrere konkrete WCAG-Erfolgskriterien, die vor allem Erkennbarkeit, Beschriftung und Bedienbarkeit betreffen. Die wichtigsten sind Kriterium 2.4.6 (\u00dcberschriften und Beschriftungen), 2.4.4 (Linkzweck), 4.1.2 (Name, Rolle, Wert) sowie 1.4.3 (Kontrast, Minimum). Links m\u00fcssen au\u00dferdem optisch vom umgebenden Text unterscheidbar sein, was Kriterium 1.4.1 regelt.<\/p>\n Jede Schaltfl\u00e4che muss eine aussagekr\u00e4ftige, programmatisch ermittelbare Beschriftung besitzen. Ein Icon-Button ohne sichtbaren Text ben\u00f6tigt zwingend ein Links m\u00fcssen ihren Zweck aus dem Linktext allein oder aus dem unmittelbaren Kontext heraus verst\u00e4ndlich machen. Texte wie \u201ehier klicken“ oder \u201emehr erfahren“ sind problematisch, weil sie ohne Kontext keine Information dar\u00fcber liefern, wohin der Link f\u00fchrt. Screenreader-Nutzende navigieren h\u00e4ufig durch Auflistungen aller Links auf einer Seite, weshalb jeder Linktext f\u00fcr sich allein verst\u00e4ndlich sein sollte. Au\u00dferdem d\u00fcrfen Links nicht ausschlie\u00dflich \u00fcber Farbe von normalem Text unterschieden werden, ohne einen zus\u00e4tzlichen visuellen Hinweis wie Unterstreichung zu verwenden.<\/p>\n Barrierefreie Formulare erfordern klare, programmatisch verkn\u00fcpfte Beschriftungen f\u00fcr jedes Eingabefeld, verst\u00e4ndliche Fehlermeldungen und eine vollst\u00e4ndige Tastaturbedienbarkeit. Jedes Formularfeld muss ein zugeh\u00f6riges 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\u00f6glichst ein Korrekturvorschlag gegeben werden. Die Fehlermeldung muss programmatisch mit dem betroffenen Feld verkn\u00fcpft sein, etwa \u00fcber Pflichtfelder m\u00fcssen als solche kenntlich gemacht werden, und zwar nicht nur visuell, sondern auch im Code, zum Beispiel durch das Alle interaktiven Elemente einer Website m\u00fcssen ausschlie\u00dflich 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\u00f6nnen, etwa wegen motorischer Einschr\u00e4nkungen, sind vollst\u00e4ndig auf Tastaturnavigation angewiesen.<\/p>\n 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\u00e4rft.<\/p>\n Besondere Herausforderungen entstehen bei modalen Dialogen und Overlays. \u00d6ffnet sich ein Dialog, muss der Fokus in diesen Dialog verschoben werden, und Nutzende d\u00fcrfen nicht in den Hintergrundinhalt tabben k\u00f6nnen, solange der Dialog ge\u00f6ffnet ist. Beim Schlie\u00dfen des Dialogs muss der Fokus auf das ausl\u00f6sende Element zur\u00fcckkehren. Dieses Muster, auch als \u201eFocus Trap“ bezeichnet, ist f\u00fcr viele Entwicklungsteams eine h\u00e4ufige Fehlerquelle. Automatisierte Barrierefreiheitstests<\/a> k\u00f6nnen helfen, solche strukturellen Probleme fr\u00fchzeitig zu identifizieren.<\/p>\n Das Barrierefreiheitsst\u00e4rkungsgesetz (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\u00fcr interaktive Website-Elemente bedeutet das, dass die Anforderungen der WCAG 2.1 auf Konformit\u00e4tsstufe AA als technischer Referenzstandard gelten.<\/p>\n Betroffen sind insbesondere Unternehmen, die digitale Dienstleistungen f\u00fcr Verbraucherinnen und Verbraucher anbieten, etwa im E-Commerce, im Banking oder bei Buchungsportalen. F\u00fcr diese Unternehmen sind zug\u00e4ngliche Formulare, bedienbare Schaltfl\u00e4chen und korrekt implementierte Navigationsstrukturen keine optionale Verbesserung mehr, sondern eine gesetzliche Anforderung.<\/p>\n Praktisch relevant ist das BFSG vor allem f\u00fcr interaktive Kernfunktionen: Ein Checkout-Prozess, der ohne Maus nicht abschlie\u00dfbar ist, ein Login-Formular ohne korrekte Beschriftungen oder ein Produktfilter, der f\u00fcr Screenreader-Nutzende nicht bedienbar ist, k\u00f6nnen rechtliche Risiken darstellen. Unternehmen sollten ihre interaktiven Elemente systematisch pr\u00fcfen lassen und Schwachstellen priorisiert beheben. Hinweis: Ob eine Website die gesetzlichen Anforderungen des BFSG vollst\u00e4ndig erf\u00fcllt, kann nur durch eine fachkundige Pr\u00fcfung festgestellt werden, die sowohl automatisierte als auch manuelle Tests umfasst.<\/p>\n Barrierefreiheitsprobleme bei interaktiven Elementen lassen sich durch eine Kombination aus automatisierten Scans und manuellen Tests systematisch identifizieren. Automatisierte Tools pr\u00fcfen den HTML-Code auf bekannte Fehler wie fehlende Labels, unzureichende Kontraste oder falsch verwendete ARIA-Attribute. Manuelle Tests decken dar\u00fcber hinaus Probleme auf, die automatisch nicht erkennbar sind, etwa die logische Tab-Reihenfolge oder das korrekte Verhalten von Fokusfallen in Dialogen.<\/p>\n Sch\u00e4tzungen aus der Forschungspraxis, unter anderem von der Universit\u00e4t Bielefeld, gehen davon aus, dass automatisierte Tests etwa 30 bis 50 Prozent aller Barriereprobleme abdecken k\u00f6nnen. Das bedeutet: Automatisierte Pr\u00fcfungen sind ein wichtiger erster Schritt, ersetzen aber keine vollst\u00e4ndige manuelle Pr\u00fcfung nach dem BITV-Pr\u00fcfverfahren.<\/p>\n Ein sinnvoller Pr\u00fcfprozess sieht typischerweise so aus:<\/p>\n<button><\/code>-Element ist von Haus aus tastaturbedienbar und f\u00fcr Screenreader erkennbar. Ein <div><\/code>, das optisch wie ein Button aussieht, hingegen nicht, sofern es nicht entsprechend ausgezeichnet wird.<\/p>\nWelche WCAG-Kriterien gelten speziell f\u00fcr Schaltfl\u00e4chen und Links?<\/h2>\n
Anforderungen an Schaltfl\u00e4chen<\/h3>\n
aria-label<\/code>– oder aria-labelledby<\/code>-Attribut, damit Screenreader den Zweck vorlesen k\u00f6nnen. Der Kontrast zwischen Text und Hintergrundfarbe muss mindestens 4,5:1 betragen, bei gro\u00dfem Text mindestens 3:1. Fokuszust\u00e4nde m\u00fcssen sichtbar sein, damit Tastaturnutzende erkennen, welche Schaltfl\u00e4che gerade aktiv ist.<\/p>\nAnforderungen an Links<\/h3>\n
Wie m\u00fcssen Formulare barrierefrei gestaltet sein?<\/h2>\n
<label><\/code>-Element besitzen, das mit dem Feld \u00fcber das for<\/code>-Attribut verbunden ist. Placeholder-Texte allein reichen nicht aus, da sie beim Tippen verschwinden und von Screenreadern nicht zuverl\u00e4ssig vorgelesen werden.<\/p>\naria-describedby<\/code>, damit Screenreader sie beim Fokussieren des Feldes vorlesen. Rein farbliche Markierungen wie ein roter Rahmen reichen nicht aus.<\/p>\nrequired<\/code>-Attribut oder ein aria-required=\"true\"<\/code>. Komplexe Formulare mit mehreren Schritten sollten den aktuellen Fortschritt anzeigen und es erm\u00f6glichen, eingegebene Daten vor dem Absenden zu \u00fcberpr\u00fcfen und zu korrigieren.<\/p>\nWelche Anforderungen gelten f\u00fcr Tastatur- und Fokussteuerung?<\/h2>\n
Wie wirkt sich das BFSG auf interaktive Website-Elemente aus?<\/h2>\n
Wie lassen sich Barrierefreiheitsprobleme bei interaktiven Elementen systematisch pr\u00fcfen?<\/h2>\n
\n