Formulare auf Barrierefreiheit zu testen bedeutet, sowohl automatisierte Scans als auch manuelle Pr\u00fcfmethoden zu kombinieren, um sicherzustellen, dass alle Nutzerinnen und Nutzer unabh\u00e4ngig von ihren F\u00e4higkeiten Formulare vollst\u00e4ndig bedienen k\u00f6nnen. Die relevanten Standards daf\u00fcr liefern die WCAG 2.1 und 2.2, erg\u00e4nzt durch die BITV 2.0 sowie das Barrierefreiheitsst\u00e4rkungsgesetz (BFSG), das seit Juni 2025 f\u00fcr viele digitale Angebote verbindlich gilt. Im Folgenden beantworten wir die wichtigsten Fragen rund um barrierefreie Webformulare.<\/p>\n
F\u00fcr Webformulare gelten eine Reihe spezifischer WCAG-Erfolgskriterien, die sicherstellen, dass Formularelemente erkennbar, bedienbar und verst\u00e4ndlich 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).<\/p>\n
Im Einzelnen bedeutet das f\u00fcr Formulare:<\/p>\n
fieldset<\/code> und legend<\/code> oder gleichwertigen ARIA-Konstrukten gruppiert werden.<\/li>\n- Zeitlimits:<\/strong> Wenn Formulare mit Zeitlimits arbeiten, m\u00fcssen Nutzerinnen und Nutzer diese verl\u00e4ngern oder deaktivieren k\u00f6nnen.<\/li>\n<\/ul>\n
Die BITV 2.0 \u00fcbernimmt diese Anforderungen f\u00fcr den deutschen Rechtsraum und bildet die Grundlage f\u00fcr Pr\u00fcfungen nach dem BFSG. Wer Formulare nach Konformit\u00e4tsstufe AA pr\u00fcft, deckt damit den gesetzlich geforderten Mindeststandard ab.<\/p>\n
Wie testet man Formulare manuell auf Barrierefreiheit?<\/h2>\n
Formulare manuell auf Barrierefreiheit zu testen erfordert drei Kernmethoden: Tastaturnavigation, Screenreader-Test und visuelle Inspektion des Quellcodes. Kein automatisiertes Tool kann diese Kombination vollst\u00e4ndig ersetzen, weil Aspekte wie die logische Tab-Reihenfolge oder die Verst\u00e4ndlichkeit von Fehlermeldungen menschliches Urteilsverm\u00f6gen erfordern.<\/p>\n
Tastaturnavigation pr\u00fcfen<\/h3>\n
Navigieren Sie das gesamte Formular ausschlie\u00dflich mit der Tastatur: Tab zum Vorw\u00e4rtsnavigieren, Shift+Tab zum R\u00fcckw\u00e4rtsnavigieren, 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\u00e4ndig 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?<\/p>\n
Screenreader-Test durchf\u00fchren<\/h3>\n
Testen Sie das Formular mit einem Screenreader, zum Beispiel NVDA (Windows, kostenlos), JAWS (Windows, kostenpflichtig) oder VoiceOver (macOS und iOS, integriert). Pr\u00fcfen Sie, ob Labels korrekt vorgelesen werden, ob Pflichtfelder als solche angek\u00fcndigt werden und ob Fehlermeldungen nach dem Absenden automatisch oder per Fokus zug\u00e4nglich sind. Besonderes Augenmerk gilt ARIA-Attributen wie aria-required<\/code>, aria-describedby<\/code> und aria-live<\/code>, die h\u00e4ufig falsch oder gar nicht eingesetzt werden.<\/p>\nCode-Inspektion und visuelle Pr\u00fcfung<\/h3>\n
\u00d6ffnen Sie die Browser-Entwicklertools und pr\u00fcfen Sie, ob Labels \u00fcber das for<\/code>-Attribut mit dem entsprechenden id<\/code>-Attribut des Eingabefelds verbunden sind. Kontrollieren Sie au\u00dferdem, ob Fehlermeldungen im DOM vorhanden und nicht nur visuell eingeblendet werden, und ob Farbkontraste auch bei deaktiviertem CSS noch erkennbar sind.<\/p>\nWelche automatisierten Tools eignen sich f\u00fcr Formular-Accessibility-Tests?<\/h2>\n
Automatisierte Tools f\u00fcr Barrierefreiheitstests k\u00f6nnen typischerweise zwischen 30 und 40 Prozent der WCAG-Probleme in Formularen zuverl\u00e4ssig erkennen, darunter fehlende Labels, unzureichende Farbkontraste und fehlende ARIA-Attribute. Sie sind ein unverzichtbarer erster Schritt, ersetzen aber keine manuelle Pr\u00fcfung.<\/p>\n
Zu den etablierten Tools f\u00fcr den Barrierefreiheits-Website-Test<\/a> geh\u00f6ren:<\/p>\n\n- Axe (Browser-Extension oder API):<\/strong> Weit verbreitet, gut dokumentiert, liefert pr\u00e4zise Fehlermeldungen mit Verweis auf das WCAG-Kriterium. Ideal f\u00fcr Entwicklerinnen und Entwickler, die w\u00e4hrend der Entwicklung testen.<\/li>\n
- WAVE (WebAIM):<\/strong> Visualisiert Barrierefreiheitsprobleme direkt auf der Seite. Gut geeignet f\u00fcr erste Einsch\u00e4tzungen, aber ohne Dokumentationsfunktion f\u00fcr gr\u00f6\u00dfere Projekte.<\/li>\n
- Lighthouse (Google):<\/strong> Integriert in Chrome DevTools, liefert einen Accessibility-Score und konkrete Hinweise. N\u00fctzlich f\u00fcr schnelle Checks, aber nicht ausreichend f\u00fcr eine vollst\u00e4ndige BITV-Pr\u00fcfung.<\/li>\n
- Spezialisierte SaaS-Plattformen:<\/strong> F\u00fcr Agenturen und Compliance-Teams, die mehrere Websites dauerhaft \u00fcberwachen m\u00fcssen, bieten sich Plattformen an, die seiten\u00fcbergreifend scannen, Ergebnisse dokumentieren und Berichte automatisiert erstellen.<\/li>\n<\/ul>\n
Wichtig: Automatisierte Tools pr\u00fcfen zuverl\u00e4ssig technische Merkmale wie Label-Verkn\u00fcpfungen oder Kontrastwerte. Inhaltliche Aspekte wie die Verst\u00e4ndlichkeit von Fehlertexten oder die logische Reihenfolge von Formularfeldern lassen sich nur manuell beurteilen.<\/p>\n
Was sind h\u00e4ufige Barrierefreiheitsfehler in Webformularen?<\/h2>\n
Die h\u00e4ufigsten Barrierefreiheitsfehler in Webformularen sind fehlende oder falsch verkn\u00fcpfte Labels, unzureichende Farbkontraste, fehlende Tastaturzug\u00e4nglichkeit und nicht programmatisch zug\u00e4ngliche Fehlermeldungen. Diese Fehler betreffen besonders Nutzerinnen und Nutzer, die auf Screenreader oder Tastaturnavigation angewiesen sind.<\/p>\n
In der Praxis zeigen sich folgende Probleme besonders h\u00e4ufig:<\/p>\n
\n- Placeholder statt Label:<\/strong> Platzhaltertexte verschwinden beim Tippen und werden von Screenreadern nicht konsistent vorgelesen. Sie sind kein Ersatz f\u00fcr sichtbare Labels.<\/li>\n
- Fehlende Pflichtfeldkennzeichnung:<\/strong> Pflichtfelder werden nur durch ein Sternchen oder Farbe markiert, ohne dass dies programmatisch (zum Beispiel via
aria-required=\"true\"<\/code> oder required<\/code>) kommuniziert wird.<\/li>\n- Fehler nur durch Farbe signalisiert:<\/strong> Rote Umrandungen ohne Texthinweis sind f\u00fcr Nutzerinnen und Nutzer mit Farbsehschw\u00e4che nicht erkennbar.<\/li>\n
- Fehlende oder falsche ARIA-Attribute:<\/strong>
aria-describedby<\/code> verweist auf nicht existierende IDs, oder role=\"form\"<\/code> wird ohne sinnvollen Namen verwendet.<\/li>\n- Nicht erreichbare Schaltfl\u00e4chen:<\/strong> Buttons sind als
div<\/code> oder span<\/code> umgesetzt und daher per Tastatur nicht aktivierbar.<\/li>\n- Kein Fokusmanagement nach Formularabsendung:<\/strong> Nach dem Absenden landet der Fokus nicht auf der Erfolgsmeldung oder dem ersten Fehler, sodass Screenreader-Nutzende die R\u00fcckmeldung nicht mitbekommen.<\/li>\n<\/ul>\n
Viele dieser Fehler entstehen, weil Formulare ohne Blick auf die Accessibility-Anforderungen<\/a> entwickelt werden. Eine fr\u00fchzeitige Pr\u00fcfung im Entwicklungsprozess reduziert den Nachbesserungsaufwand erheblich.<\/p>\nWie werden Fehlermeldungen in Formularen barrierefrei gestaltet?<\/h2>\n
Barrierefreie Fehlermeldungen in Formularen m\u00fcssen in Textform vorliegen, dem verursachenden Feld programmatisch zugeordnet sein und f\u00fcr Screenreader automatisch oder per Fokus zug\u00e4nglich werden. Farbe allein darf niemals das einzige Mittel sein, um einen Fehler zu kommunizieren.<\/p>\n
Konkret bedeutet das f\u00fcr die technische Umsetzung:<\/p>\n
\n- Fehlermeldung im DOM platzieren:<\/strong> Die Fehlermeldung muss als echter Text im HTML vorhanden sein, nicht nur als visuelles CSS-Element.<\/li>\n
- Verkn\u00fcpfung mit dem Feld:<\/strong> Verwenden Sie
aria-describedby<\/code> am Eingabefeld, das auf die ID der Fehlermeldung verweist. So liest der Screenreader die Fehlermeldung automatisch vor, wenn das Feld fokussiert wird.<\/li>\n- Fokusmanagement:<\/strong> 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.<\/li>\n
- Live-Regionen f\u00fcr dynamische Fehler:<\/strong> Wenn Fehler inline und ohne Seitenneuladen erscheinen, sollte
aria-live=\"assertive\"<\/code> oder role=\"alert\"<\/code> verwendet werden, damit Screenreader die \u00c4nderung ank\u00fcndigen.<\/li>\n- Beschreibende Fehlertexte:<\/strong> Statt \u201eUng\u00fcltige Eingabe“ sollte die Meldung konkret beschreiben, was erwartet wird, zum Beispiel \u201eBitte geben Sie eine g\u00fcltige E-Mail-Adresse im Format name@beispiel.de ein.“<\/li>\n<\/ul>\n
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\u00fcr Konformit\u00e4tsstufe AA relevant und damit f\u00fcr die meisten gesetzlich verpflichteten Angebote bindend.<\/p>\n
Wann ist ein Formular nach BFSG als barrierefrei einzustufen?<\/h2>\n
Ein Formular gilt nach BFSG als barrierefrei, wenn es die Anforderungen der WCAG 2.1 auf Konformit\u00e4tsstufe AA erf\u00fcllt, da das BFSG auf die europ\u00e4ische Norm EN 301 549 verweist, die WCAG 2.1 AA als Ma\u00dfstab zugrunde legt. Zu beachten ist: Auch wenn ein automatisierter Scan keine Probleme findet, bedeutet das nicht zwingend vollst\u00e4ndige rechtliche Konformit\u00e4t.<\/p>\n
F\u00fcr eine fundierte Einsch\u00e4tzung sollten folgende Voraussetzungen erf\u00fcllt sein:<\/p>\n
\n- Alle automatisiert pr\u00fcfbaren WCAG 2.1 AA-Kriterien zeigen keine Auff\u00e4lligkeiten im Scan.<\/li>\n
- Manuelle Tests mit Tastatur und Screenreader best\u00e4tigen die Bedienbarkeit.<\/li>\n
- Eine Barrierefreiheitserkl\u00e4rung dokumentiert den Pr\u00fcfstand, bekannte Ausnahmen und Kontaktm\u00f6glichkeiten f\u00fcr R\u00fcckmeldungen.<\/li>\n
- Die Pr\u00fcfung wird regelm\u00e4\u00dfig wiederholt, da Website-Updates neue Barrieren einf\u00fchren k\u00f6nnen.<\/li>\n<\/ul>\n
Das BFSG gilt seit Juni 2025 f\u00fcr 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\u00fcfung reicht daher nicht aus. Wichtig: Ob ein Angebot im konkreten Einzelfall die gesetzlichen Anforderungen erf\u00fcllt, kann nur durch rechtliche Beratung abschlie\u00dfend beurteilt werden.<\/p>\n
Wie decareto Sie beim barrierefreien Testen von Formularen unterst\u00fctzt<\/h2>\n
Wir bei decareto bieten eine spezialisierte Accessibility-Software, die den Einstieg in die systematische Barrierefreiheitspr\u00fcfung von Websites, einschlie\u00dflich ihrer Formulare, deutlich erleichtert. Unsere Plattform kombiniert automatisierte Scans mit strukturierter Dokumentation, damit Agenturen, Datenschutzbeauftragte und Compliance-Teams effizient arbeiten k\u00f6nnen.<\/p>\n
Was decareto konkret leistet:<\/p>\n
\n- Automatisierte Scans nach WCAG 2.1\/2.2 und BITV:<\/strong> Wir scannen Unterseiten, erkennen typische Formularprobleme wie fehlende Labels, unzureichende Kontraste und fehlende ARIA-Attribute und priorisieren die Ergebnisse nach Schweregrad.<\/li>\n
- Konkrete Handlungsempfehlungen:<\/strong> Zu jedem gefundenen Problem liefern wir verst\u00e4ndliche Hinweise zur Behebung, formuliert f\u00fcr Entwicklerinnen und Entwickler ebenso wie f\u00fcr Beraterinnen und Berater ohne tiefes technisches Vorwissen.<\/li>\n
- Dauerhaftes Monitoring:<\/strong> Wir \u00fcberwachen Ihre Websites kontinuierlich und benachrichtigen Sie automatisch, wenn neue Barrieren nach Website-Updates auftreten, so bleibt der Pr\u00fcfstand nachvollziehbar dokumentiert.<\/li>\n
- Teilbare Reports:<\/strong> Barrierefreiheits-Reports lassen sich direkt mit Kunden teilen, als PDF exportieren und optional unter eigenem Logo (Whitelabel) ausliefern.<\/li>\n
- Kombination mit Datenschutz:<\/strong> In einem einzigen Dashboard pr\u00fcfen Sie sowohl Barrierefreiheit als auch DSGVO-Konformit\u00e4t, was doppelten Aufwand vermeidet.<\/li>\n<\/ul>\n
Testen Sie jetzt, wie Ihre Website abschneidet: Starten Sie direkt mit unserem Barrierefreiheits-Test-Tool<\/a> oder registrieren Sie sich<\/a> f\u00fcr einen vollst\u00e4ndigen Website-Scan.<\/p>\nDieser Text wurde mit Hilfe von KI erstellt und k\u00f6nnte Fehler beinhalten.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"Barrierefreie Formulare testen: So kombinieren Sie automatisierte Tools und manuelle Pr\u00fcfmethoden WCAG- und BFSG-konform.<\/p>\n","protected":false},"author":6,"featured_media":9464,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_seopress_titles_title":"","_seopress_titles_desc":"","_seopress_robots_index":"","_seopress_robots_follow":"","_seopress_robots_imageindex":"","_seopress_robots_snippet":"","_seopress_robots_primary_cat":"","_seopress_robots_breadcrumbs":"","_seopress_robots_freeze_modified_date":"","_seopress_robots_custom_modified_date":"","_seopress_robots_canonical":"","_seopress_social_fb_title":"","_seopress_social_fb_desc":"","_seopress_social_fb_img":"","_seopress_social_fb_img_attachment_id":0,"_seopress_social_fb_img_width":0,"_seopress_social_fb_img_height":0,"_seopress_social_twitter_title":"","_seopress_social_twitter_desc":"","_seopress_social_twitter_img":"","_seopress_social_twitter_img_attachment_id":0,"_seopress_social_twitter_img_width":0,"_seopress_social_twitter_img_height":0,"_seopress_redirections_value":"","_seopress_redirections_enabled":"","_seopress_redirections_enabled_regex":"","_seopress_redirections_logged_status":"","_seopress_redirections_param":"","_seopress_redirections_type":0,"_seopress_analysis_target_kw":"","_seopress_news_disabled":"","_seopress_video_disabled":"","_seopress_video":[],"_seopress_pro_schemas_manual":[],"_seopress_pro_rich_snippets_disable_all":"","_seopress_pro_rich_snippets_disable":[],"_seopress_pro_schemas":[],"footnotes":""},"categories":[44],"tags":[],"class_list":["post-9248","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog"],"acf":[],"_links":{"self":[{"href":"https:\/\/decareto.com\/de\/wp-json\/wp\/v2\/posts\/9248","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/decareto.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/decareto.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/decareto.com\/de\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/decareto.com\/de\/wp-json\/wp\/v2\/comments?post=9248"}],"version-history":[{"count":1,"href":"https:\/\/decareto.com\/de\/wp-json\/wp\/v2\/posts\/9248\/revisions"}],"predecessor-version":[{"id":9377,"href":"https:\/\/decareto.com\/de\/wp-json\/wp\/v2\/posts\/9248\/revisions\/9377"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/decareto.com\/de\/wp-json\/wp\/v2\/media\/9464"}],"wp:attachment":[{"href":"https:\/\/decareto.com\/de\/wp-json\/wp\/v2\/media?parent=9248"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/decareto.com\/de\/wp-json\/wp\/v2\/categories?post=9248"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/decareto.com\/de\/wp-json\/wp\/v2\/tags?post=9248"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}