Blog

Wie testet man Formulare auf Barrierefreiheit?

Herausgegeben von Decareto

4 Minuten lesen

November 10, 2026

Formulare auf Barrierefreiheit zu testen bedeutet, sowohl automatisierte Scans als auch manuelle Prüfmethoden zu kombinieren, um sicherzustellen, dass alle Nutzerinnen und Nutzer unabhängig von ihren Fähigkeiten Formulare vollständig bedienen können. Die relevanten Standards dafür liefern die WCAG 2.1 und 2.2, ergänzt durch die BITV 2.0 sowie das Barrierefreiheitsstärkungsgesetz (BFSG), das seit Juni 2025 für viele digitale Angebote verbindlich gilt. Im Folgenden beantworten wir die wichtigsten Fragen rund um barrierefreie Webformulare.

Welche Barrierefreiheitsanforderungen gelten speziell für Formulare?

Für Webformulare gelten eine Reihe spezifischer WCAG-Erfolgskriterien, die sicherstellen, dass Formularelemente erkennbar, bedienbar und verständlich sind. Besonders relevant sind die Kriterien aus den Bereichen Perceivable, Operable und Understandable, konkret etwa 1.3.1 (Info und Beziehungen), 1.4.3 (Kontrast), 2.1.1 (Tastatur) und 3.3.1 bis 3.3.4 (Fehlererkennung und Hilfestellung).

Im Einzelnen bedeutet das für Formulare:

Beschriftungen (Labels): Jedes Eingabefeld benötigt ein programmatisch verknüpftes Label, das Screenreader korrekt vorlesen können. Platzhaltertexte (Placeholder) ersetzen Labels nicht.
Tastaturzugänglichkeit: Alle Formularelemente, also Eingabefelder, Dropdowns, Checkboxen, Radiobuttons und Schaltflächen, müssen ohne Maus erreichbar und bedienbar sein.
Farbkontrast: Text in Formularfeldern sowie Beschriftungen müssen ein Kontrastverhältnis von mindestens 4,5:1 gegenüber dem Hintergrund aufweisen (WCAG-Konformitätsstufe AA).
Fehlermeldungen: Fehler müssen in Textform beschrieben und dem betreffenden Feld programmatisch zugeordnet sein, nicht nur durch Farbe signalisiert werden.
Gruppenelemente: Zusammengehörige Felder wie Radiobutton-Gruppen müssen mit fieldset und legend oder gleichwertigen ARIA-Konstrukten gruppiert werden.
Zeitlimits: Wenn Formulare mit Zeitlimits arbeiten, müssen Nutzerinnen und Nutzer diese verlängern oder deaktivieren können.

Die BITV 2.0 übernimmt diese Anforderungen für den deutschen Rechtsraum und bildet die Grundlage für Prüfungen nach dem BFSG. Wer Formulare nach Konformitätsstufe AA prüft, deckt damit den gesetzlich geforderten Mindeststandard ab.

Wie testet man Formulare manuell auf Barrierefreiheit?

Formulare manuell auf Barrierefreiheit zu testen erfordert drei Kernmethoden: Tastaturnavigation, Screenreader-Test und visuelle Inspektion des Quellcodes. Kein automatisiertes Tool kann diese Kombination vollständig ersetzen, weil Aspekte wie die logische Tab-Reihenfolge oder die Verständlichkeit von Fehlermeldungen menschliches Urteilsvermögen erfordern.

Tastaturnavigation prüfen

Navigieren Sie das gesamte Formular ausschließlich mit der Tastatur: Tab zum Vorwärtsnavigieren, Shift+Tab zum Rückwärtsnavigieren, Enter und Leertaste zum Aktivieren. Achten Sie dabei auf folgende Punkte: Ist jedes Feld erreichbar? Ist der Fokusindikator (der sichtbare Rahmen um das aktive Element) zu jedem Zeitpunkt klar erkennbar? Kann das Formular vollständig abgeschickt werden, ohne die Maus zu nutzen? Springt der Fokus nach dem Absenden an eine sinnvolle Position, zum Beispiel zur Erfolgsmeldung oder zur ersten Fehlermeldung?

Screenreader-Test durchführen

Testen Sie das Formular mit einem Screenreader, zum Beispiel NVDA (Windows, kostenlos), JAWS (Windows, kostenpflichtig) oder VoiceOver (macOS und iOS, integriert). Prüfen Sie, ob Labels korrekt vorgelesen werden, ob Pflichtfelder als solche angekündigt werden und ob Fehlermeldungen nach dem Absenden automatisch oder per Fokus zugänglich sind. Besonderes Augenmerk gilt ARIA-Attributen wie aria-required, aria-describedby und aria-live, die häufig falsch oder gar nicht eingesetzt werden.

Code-Inspektion und visuelle Prüfung

Öffnen Sie die Browser-Entwicklertools und prüfen Sie, ob Labels über das for-Attribut mit dem entsprechenden id-Attribut des Eingabefelds verbunden sind. Kontrollieren Sie außerdem, ob Fehlermeldungen im DOM vorhanden und nicht nur visuell eingeblendet werden, und ob Farbkontraste auch bei deaktiviertem CSS noch erkennbar sind.

Welche automatisierten Tools eignen sich für Formular-Accessibility-Tests?

Automatisierte Tools für Barrierefreiheitstests können typischerweise zwischen 30 und 40 Prozent der WCAG-Probleme in Formularen zuverlässig erkennen, darunter fehlende Labels, unzureichende Farbkontraste und fehlende ARIA-Attribute. Sie sind ein unverzichtbarer erster Schritt, ersetzen aber keine manuelle Prüfung.

Zu den etablierten Tools für den Barrierefreiheits-Website-Test gehören:

Axe (Browser-Extension oder API): Weit verbreitet, gut dokumentiert, liefert präzise Fehlermeldungen mit Verweis auf das WCAG-Kriterium. Ideal für Entwicklerinnen und Entwickler, die während der Entwicklung testen.
WAVE (WebAIM): Visualisiert Barrierefreiheitsprobleme direkt auf der Seite. Gut geeignet für erste Einschätzungen, aber ohne Dokumentationsfunktion für größere Projekte.
Lighthouse (Google): Integriert in Chrome DevTools, liefert einen Accessibility-Score und konkrete Hinweise. Nützlich für schnelle Checks, aber nicht ausreichend für eine vollständige BITV-Prüfung.
Spezialisierte SaaS-Plattformen: Für Agenturen und Compliance-Teams, die mehrere Websites dauerhaft überwachen müssen, bieten sich Plattformen an, die seitenübergreifend scannen, Ergebnisse dokumentieren und Berichte automatisiert erstellen.

Wichtig: Automatisierte Tools prüfen zuverlässig technische Merkmale wie Label-Verknüpfungen oder Kontrastwerte. Inhaltliche Aspekte wie die Verständlichkeit von Fehlertexten oder die logische Reihenfolge von Formularfeldern lassen sich nur manuell beurteilen.

Was sind häufige Barrierefreiheitsfehler in Webformularen?

Die häufigsten Barrierefreiheitsfehler in Webformularen sind fehlende oder falsch verknüpfte Labels, unzureichende Farbkontraste, fehlende Tastaturzugänglichkeit und nicht programmatisch zugängliche Fehlermeldungen. Diese Fehler betreffen besonders Nutzerinnen und Nutzer, die auf Screenreader oder Tastaturnavigation angewiesen sind.

In der Praxis zeigen sich folgende Probleme besonders häufig:

Placeholder statt Label: Platzhaltertexte verschwinden beim Tippen und werden von Screenreadern nicht konsistent vorgelesen. Sie sind kein Ersatz für sichtbare Labels.
Fehlende Pflichtfeldkennzeichnung: Pflichtfelder werden nur durch ein Sternchen oder Farbe markiert, ohne dass dies programmatisch (zum Beispiel via aria-required="true" oder required) kommuniziert wird.
Fehler nur durch Farbe signalisiert: Rote Umrandungen ohne Texthinweis sind für Nutzerinnen und Nutzer mit Farbsehschwäche nicht erkennbar.
Fehlende oder falsche ARIA-Attribute: aria-describedby verweist auf nicht existierende IDs, oder role="form" wird ohne sinnvollen Namen verwendet.
Nicht erreichbare Schaltflächen: Buttons sind als div oder span umgesetzt und daher per Tastatur nicht aktivierbar.
Kein Fokusmanagement nach Formularabsendung: Nach dem Absenden landet der Fokus nicht auf der Erfolgsmeldung oder dem ersten Fehler, sodass Screenreader-Nutzende die Rückmeldung nicht mitbekommen.

Viele dieser Fehler entstehen, weil Formulare ohne Blick auf die Accessibility-Anforderungen entwickelt werden. Eine frühzeitige Prüfung im Entwicklungsprozess reduziert den Nachbesserungsaufwand erheblich.

Wie werden Fehlermeldungen in Formularen barrierefrei gestaltet?

Barrierefreie Fehlermeldungen in Formularen müssen in Textform vorliegen, dem verursachenden Feld programmatisch zugeordnet sein und für Screenreader automatisch oder per Fokus zugänglich werden. Farbe allein darf niemals das einzige Mittel sein, um einen Fehler zu kommunizieren.

Konkret bedeutet das für die technische Umsetzung:

Fehlermeldung im DOM platzieren: Die Fehlermeldung muss als echter Text im HTML vorhanden sein, nicht nur als visuelles CSS-Element.
Verknüpfung mit dem Feld: Verwenden Sie aria-describedby am Eingabefeld, das auf die ID der Fehlermeldung verweist. So liest der Screenreader die Fehlermeldung automatisch vor, wenn das Feld fokussiert wird.
Fokusmanagement: Nach dem Absenden des Formulars sollte der Fokus auf die erste Fehlermeldung oder eine zusammenfassende Fehlerliste gesetzt werden, damit Tastatur- und Screenreader-Nutzende sofort informiert werden.
Live-Regionen für dynamische Fehler: Wenn Fehler inline und ohne Seitenneuladen erscheinen, sollte aria-live="assertive" oder role="alert" verwendet werden, damit Screenreader die Änderung ankündigen.
Beschreibende Fehlertexte: Statt „Ungültige Eingabe“ sollte die Meldung konkret beschreiben, was erwartet wird, zum Beispiel „Bitte geben Sie eine gültige E-Mail-Adresse im Format name@beispiel.de ein.“

WCAG 3.3.1 fordert die Identifikation des Fehlers, 3.3.3 die Beschreibung des Fehlers und 3.3.4 die Fehlervermeidung bei wichtigen Aktionen. Alle drei Kriterien sind für Konformitätsstufe AA relevant und damit für die meisten gesetzlich verpflichteten Angebote bindend.

Wann ist ein Formular nach BFSG als barrierefrei einzustufen?

Ein Formular gilt nach BFSG als barrierefrei, wenn es die Anforderungen der WCAG 2.1 auf Konformitätsstufe AA erfüllt, da das BFSG auf die europäische Norm EN 301 549 verweist, die WCAG 2.1 AA als Maßstab zugrunde legt. Zu beachten ist: Auch wenn ein automatisierter Scan keine Probleme findet, bedeutet das nicht zwingend vollständige rechtliche Konformität.

Für eine fundierte Einschätzung sollten folgende Voraussetzungen erfüllt sein:

Alle automatisiert prüfbaren WCAG 2.1 AA-Kriterien zeigen keine Auffälligkeiten im Scan.
Manuelle Tests mit Tastatur und Screenreader bestätigen die Bedienbarkeit.
Eine Barrierefreiheitserklärung dokumentiert den Prüfstand, bekannte Ausnahmen und Kontaktmöglichkeiten für Rückmeldungen.
Die Prüfung wird regelmäßig wiederholt, da Website-Updates neue Barrieren einführen können.

Das BFSG gilt seit Juni 2025 für viele private Anbieter, insbesondere im E-Commerce und bei digitalen Dienstleistungen. Die Anforderungen beziehen sich auf das gesamte digitale Angebot, nicht nur auf einzelne Seiten oder Formulare. Eine einmalige Prüfung reicht daher nicht aus. Wichtig: Ob ein Angebot im konkreten Einzelfall die gesetzlichen Anforderungen erfüllt, kann nur durch rechtliche Beratung abschließend beurteilt werden.

Wie decareto Sie beim barrierefreien Testen von Formularen unterstützt

Wir bei decareto bieten eine spezialisierte Accessibility-Software, die den Einstieg in die systematische Barrierefreiheitsprüfung von Websites, einschließlich ihrer Formulare, deutlich erleichtert. Unsere Plattform kombiniert automatisierte Scans mit strukturierter Dokumentation, damit Agenturen, Datenschutzbeauftragte und Compliance-Teams effizient arbeiten können.

Was decareto konkret leistet:

Automatisierte Scans nach WCAG 2.1/2.2 und BITV: Wir scannen Unterseiten, erkennen typische Formularprobleme wie fehlende Labels, unzureichende Kontraste und fehlende ARIA-Attribute und priorisieren die Ergebnisse nach Schweregrad.
Konkrete Handlungsempfehlungen: Zu jedem gefundenen Problem liefern wir verständliche Hinweise zur Behebung, formuliert für Entwicklerinnen und Entwickler ebenso wie für Beraterinnen und Berater ohne tiefes technisches Vorwissen.
Dauerhaftes Monitoring: Wir überwachen Ihre Websites kontinuierlich und benachrichtigen Sie automatisch, wenn neue Barrieren nach Website-Updates auftreten, so bleibt der Prüfstand nachvollziehbar dokumentiert.
Teilbare Reports: Barrierefreiheits-Reports lassen sich direkt mit Kunden teilen, als PDF exportieren und optional unter eigenem Logo (Whitelabel) ausliefern.
Kombination mit Datenschutz: In einem einzigen Dashboard prüfen Sie sowohl Barrierefreiheit als auch DSGVO-Konformität, was doppelten Aufwand vermeidet.

Testen Sie jetzt, wie Ihre Website abschneidet: Starten Sie direkt mit unserem Barrierefreiheits-Test-Tool oder registrieren Sie sich für einen vollständigen Website-Scan.

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