NCA Social Media
Webformular mit Labels und Checkmarks, HTML-Code-Panel, grüne Rakete auf dunkelblauem Hintergrund

Was sind Accessible Forms? Definition 2026

Accessible Forms sind barrierefreie Webformulare, die von allen Menschen genutzt werden können, unabhängig von körperlichen oder kognitiven Einschränkungen. Das betrifft Kontaktformulare, Checkout-Prozesse, Login-Masken, Suchfelder und jede andere Art von Nutzereingabe. Barrierefreie Formulare sind nicht nur ethisch geboten, sondern seit dem 28. Juni 2025 durch das Barrierefreiheitsstärkungsgesetz (BFSG) für viele Unternehmen gesetzlich vorgeschrieben.

Die technischen Anforderungen an barrierefreie Formulare sind in den WCAG 2.1 auf Level AA definiert, insbesondere in den Kriterien 1.3.1 (Informationen und Beziehungen), 1.3.5 (Eingabezweck bestimmen), 3.3.1 (Fehlererkennung) und 3.3.2 (Beschriftungen oder Anweisungen). Kurz gesagt: Jedes Formularfeld muss beschriftet, jeder Fehler erklärt und jede Pflichtangabe klar kommuniziert sein.

Accessible Forms kommen nicht nur Menschen mit Behinderungen zugute: Klare Labels und hilfreiche Fehlermeldungen verbessern die allgemeine UX, reduzieren Abbruchquoten und erhöhen Conversion Rates. Barrierefreiheit und gutes Formular-Design sind kein Widerspruch, sondern dasselbe Ziel.

Inhaltsverzeichnis

CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.

Erreichen Sie unsere Spezialisten zu barrierefreien Webdesign

Wir sind hier, um Ihnen zu helfen. Gemeinsam meistern wir Ihre digitalen Herausforderungen und fördern die Inklusion im Internet. Lassen Sie uns Ihre Projekte mit barrierefreiem Webdesign erfolgreich machen.

Kostenlose Demo Jetzt anrufen

Die wichtigsten HTML-Attribute für barrierefreie Formulare

Barrierefreie Formulare beginnen mit korrektem HTML. Diese Attribute und Elemente sind die Grundlage jeder WCAG-konformen Formular-Implementierung:

  • label for / id: Jedes Eingabefeld braucht ein verknüpftes <label>. Die for-Attribut-Wert muss mit der id des Feldes übereinstimmen. Placeholder-Text ersetzt kein Label.
  • aria-required: Pflichtfelder mit aria-required="true" oder dem nativen required-Attribut kennzeichnen. Screenreader kündigen Pflichtfelder dann explizit an.
  • aria-describedby: Verbindet ein Feld mit ergänzenden Hinweistexten oder Fehlermeldungen. Screenreader lesen die verknüpfte Beschreibung nach dem Label vor.
  • aria-invalid: Wird auf true gesetzt, wenn ein Feld einen Validierungsfehler enthält. Kombiniert mit aria-describedby auf die Fehlermeldung.
  • autocomplete: WCAG 1.3.5 fordert sinnvolle autocomplete-Werte (z. B. email, name, tel), damit Browser und assistive Technologien Felder automatisch befüllen können.
  • fieldset / legend: Gruppierte Felder (z. B. Radiobuttons, Checkboxgruppen) müssen in einem <fieldset> mit <legend> stehen, damit der Gruppenkontext für Screenreader erkennbar ist.
Code: 
          
<!-- Barrierefreies Textfeld -->
<label for="email">E-Mail-Adresse *</label>
<input
  type="email"
  id="email"
  name="email"
  autocomplete="email"
  aria-required="true"
  aria-describedby="email-error"
  aria-invalid="false"
>
<span id="email-error" role="alert" hidden>
  Bitte geben Sie eine gültige E-Mail-Adresse ein.
</span>

Barrierefreie Fehlermeldungen: So geht es richtig

Fehlermeldungen sind einer der häufigsten Schwachpunkte in der Formular-Barrierefreiheit. WCAG 3.3.1 (Fehlererkennung) und 3.3.3 (Fehlerempfehlung) definieren klare Anforderungen:

  • Fehler müssen textuell beschrieben sein, nicht nur durch Farbe (WCAG 1.4.1)
  • Fehlermeldungen müssen programmatisch mit dem Feld verbunden sein (aria-describedby)
  • Bei Submit-Validierung sollte der Fokus auf die erste Fehlermeldung oder eine Zusammenfassung gesetzt werden
  • Fehlermeldungen müssen konkret und hilfreich sein: nicht nur „Ungültige Eingabe“, sondern „Bitte geben Sie eine E-Mail-Adresse im Format name@beispiel.de ein“
  • Inline-Validierung (während der Eingabe) sollte erst nach Verlassen des Feldes (onblur) ausgelöst werden, nicht bei jedem Tastendruck
Code: 
          
// Fokus auf erste Fehlermeldung nach Submit-Validierung
function handleSubmit(e) {
  e.preventDefault();
  const errors = validateForm();
  if (errors.length > 0) {
    const firstError = document.getElementById(errors[0].fieldId + '-error');
    firstError.removeAttribute('hidden');
    document.getElementById(errors[0].fieldId).setAttribute('aria-invalid', 'true');
    document.getElementById(errors[0].fieldId).focus();
  }
}

Accessible Forms in Symfony und Sulu CMS 2026

In Symfony-Projekten entstehen Barrierefreiheitsprobleme bei Formularen häufig automatisch, weil der Form Builder nicht von Haus aus alle WCAG-Anforderungen erfüllt. Die häufigsten Stolperstellen:

  • Fehlende label-for-Verknüpfung: Symfony generiert zwar IDs für Felder, verknüpft Labels aber nicht immer korrekt. Im Twig-Template explizit {{ form_label(form.email) }} und {{ form_widget(form.email) }} prüfen.
  • Fehlermeldungen ohne aria-describedby: {{ form_errors(form.email) }} rendert Fehler, aber ohne programmatische Verbindung zum Feld. Ein eigenes Form-Theme mit aria-describedby löst das.
  • Fehlende autocomplete-Attribute: Symfony setzt keine autocomplete-Werte automatisch. Im FormType via attr ergänzen: attr: [autocomplete: email].
  • Radiobutton- und Checkbox-Gruppen: Symfony rendert diese in <div>-Containern ohne <fieldset> und <legend>. Das Form-Theme muss angepasst werden.
Code: 
          
// FormType mit Accessibility-Attributen
$builder->add('email', EmailType::class, [
    'label' => 'E-Mail-Adresse',
    'attr' => [
        'autocomplete' => 'email',
        'aria-required' => 'true',
        'placeholder' => 'name@beispiel.de',
    ],
    'required' => true,
]);

Accessible Forms testen: Checkliste und Tools

Barrierefreie Formulare müssen sowohl automatisiert als auch manuell getestet werden. Die wichtigsten Prüfpunkte:

  • axe DevTools: Prüft automatisch auf fehlende Labels, falsche ARIA-Attribute und Kontrastprobleme in Formularen. Als Cypress-Plugin in CI/CD-Pipelines integrierbar.
  • Tastaturtest: Nur per Tab durch das Formular navigieren. Ist jedes Feld erreichbar? Ist die Reihenfolge logisch? Können Dropdowns und Datepicker per Tastatur bedient werden?
  • Screenreader-Test: Mit NVDA+Firefox oder VoiceOver+Safari das Formular durchgehen. Werden alle Labels korrekt vorgelesen? Werden Pflichtfelder angekündigt? Werden Fehlermeldungen nach Submit vorgelesen?
  • Zoom auf 200%: Bricht das Formular-Layout bei 200% Zoom? Überlagern sich Labels und Felder?
  • Farbkontrast: Placeholder-Text (oft zu hell) und Fehlermeldungen (oft nur rot ohne Texterklärung) sind typische Schwachstellen.

Formulare barrierefrei umsetzen lassen
Zum Barrierefreiheits-Glossar

Häufig gestellte Fragen (FAQ)

Die wichtigsten Fragen zu Accessible Forms, WCAG-Anforderungen und BFSG-Konformität 2026.

Was sind Accessible Forms 2026 und warum sind sie Pflicht?

Accessible Forms sind barrierefreie Webformulare, die von allen Menschen genutzt werden können. Seit dem 28. Juni 2025 verpflichtet das BFSG viele Unternehmen zur barrierefreien Gestaltung digitaler Dienste. Formulare sind dabei besonders kritisch, da Kontaktformulare, Checkouts und Logins für alle Nutzergruppen zugänglich sein müssen.

Welche WCAG-Kriterien gelten für Accessible Forms 2026?

Die relevantesten WCAG 2.1 Kriterien sind: 1.1.1 (Alt-Texte für Bilder in Formularen), 1.3.1 (Informationen und Beziehungen), 1.3.5 (Eingabezweck bestimmen, autocomplete), 1.4.3 (Farbkontrast), 3.3.1 (Fehlererkennung), 3.3.2 (Beschriftungen), 3.3.3 (Fehlerempfehlung) und 4.1.2 (Name, Rolle, Wert für alle Formularelemente).

Ersetzt ein Placeholder-Text ein Label bei Accessible Forms 2026?

Nein. Placeholder-Text verschwindet bei Eingabe und ist damit als einzige Beschriftung unzureichend. Screenreader lesen Placeholder oft nicht zuverlässig vor. Jedes Formularfeld braucht ein sichtbares, programmatisch verknüpftes Label-Element. Placeholder kann ergänzend als Hinweis auf das erwartete Format genutzt werden.

Wie verknüpfe ich Fehlermeldungen barrierefrei mit Formularfeldern?

Mit aria-describedby auf dem Eingabefeld, das auf die ID der Fehlermeldung zeigt. Bei Validierungsfehler aria-invalid auf true setzen und das hidden-Attribut der Fehlermeldung entfernen. Der Fokus sollte nach Submit auf das erste fehlerhafte Feld gesetzt werden, damit Screenreader-Nutzer direkt zur Korrektur geführt werden.

Wie mache ich Radiobutton- und Checkbox-Gruppen barrierefrei 2026?

Alle zusammengehörenden Felder müssen in einem fieldset-Element stehen. Die legend beschreibt die Gruppe. Einzelne Optionen brauchen jeweils ein eigenes label. Ohne fieldset und legend können Screenreader den Gruppenkontext nicht erkennen und lesen Optionen ohne Zusammenhang vor.

Was bedeutet autocomplete für Accessible Forms nach WCAG 1.3.5?

WCAG 1.3.5 fordert, dass Eingabefelder für persönliche Daten korrekte autocomplete-Werte haben, z. B. name, email, tel, street-address. Das ermöglicht Browsern und assistiven Technologien das automatische Befüllen von Feldern, was besonders für motorisch eingeschränkte Nutzer die Bedienung erheblich erleichtert.

Wie baue ich barrierefreie Formulare in Symfony 2026?

Im FormType autocomplete, aria-required und placeholder über das attr-Array setzen. Ein eigenes Form-Theme in Twig erstellen, das aria-describedby bei Fehlern automatisch ergänzt. Radiobutton- und Checkbox-Gruppen als fieldset mit legend rendern. NCA unterstützt bei der Erstellung barrierefreier Symfony Form-Themes.

Wie teste ich Accessible Forms automatisiert in CI/CD 2026?

axe-core als Cypress-Plugin prüft gerenderte Formulare automatisch auf WCAG-Verstöße nach jedem Deployment. Typische Befunde: fehlende Labels, falsche ARIA-Attribute, Kontrastprobleme bei Placeholder-Texten. NCA empfiehlt formular-spezifische Cypress-Tests, die alle Formular-States (leer, ausgefüllt, Fehler) abdecken.

Sind barrierefreie Formulare nur für Screenreader-Nutzer relevant?

Nein. Klare Labels und hilfreiche Fehlermeldungen verbessern die UX für alle Nutzer. Gute Tab-Reihenfolge hilft Power-Usern. Ausreichende Klickziele (WCAG 2.5.8, mindestens 24x24 CSS-Pixel) erleichtern die Bedienung auf Mobilgeräten. Accessible Forms sind gutes Formular-Design für alle.

Was ist der Unterschied zwischen aria-label und label-Element bei Formularen?

Ein sichtbares label-Element mit for-Attribut ist immer zu bevorzugen. aria-label ist eine Alternative für Fälle, wo ein sichtbares Label nicht möglich ist, z. B. bei Icon-Buttons oder Suchfeldern ohne sichtbare Beschriftung. aria-label überschreibt den sichtbaren Text für Screenreader, daher mit Bedacht einsetzen.

Wie hilft NCA bei der Umsetzung von Accessible Forms?

NCA prüft bestehende Formulare auf WCAG-Konformität, erstellt barrierefreie Symfony Form-Themes, integriert Accessibility Tests in CI/CD-Pipelines und schult Entwicklungsteams. Von der Gap-Analyse bis zur vollständigen BFSG-Konformität. Vereinbaren Sie eine kostenlose Erstberatung unter roland@nevercodealone.de.

Welche Anforderungen gelten für Accessible Forms nach BFSG 2026?

Das BFSG referenziert die EN 301 549, die auf WCAG 2.1 Level AA verweist. Für Formulare bedeutet das: alle Felder beschriftet, Fehler textuell erklärt, Pflichtfelder gekennzeichnet, Tastatur vollständig bedienbar und Screenreader-kompatibel. Wer E-Commerce-Dienste erbringt, muss den gesamten Checkout-Prozess barrierefrei gestalten.

A11Y

A11Y erklaert: Was Accessibility bedeutet, welche WCAG-Anforderungen gelten und wie das BFSG 2026 Unternehmen verpflichtet. Mit technischen Tipps und FAQ.

Accessibility Audit

Accessibility Audit erklärt: Ablauf, Tools, WCAG-Konformitätsstufen und BFSG-Pflichten 2026. Mit Praxis-Tipps für PHP und Symfony.

Accessibility Testing

Accessibility Testing erklärt: Drei Ebenen, axe-core in Cypress, manuelle Checkliste und BFSG-Konformität 2026 für PHP und Symfony.

Alternative Eingabegeräte

Entdecken Sie die Welt der alternativen Eingabegeräte und wie sie die Zugänglichkeit und Nutzbarkeit von Computern für Menschen mit Behinderungen verbessern.

Alternativtext (Alt-Text)

Erfahren Sie, wie Alternativtexte (Alt-Texte) digitale Inhalte für Menschen mit Sehbehinderungen zugänglich machen und wie Sie diese effektiv einsetzen.

Audiodeskription (AD)

Entdecken Sie, was Audio Description (AD) ist und wie es die Zugänglichkeit von visuellen Medien für Menschen mit Sehbehinderungen oder Blindheit verbessert.

Barrierefreie Icons im Webdesign

Barrierefreie Icons nach WCAG 2.1: Kontraststark, screenreader-optimiert und tastaturbedienbar. Steigern Sie Accessibility & UX – inklusives Design für alle Nutzergruppen!

Barrierefreiheits-stärkungsgesetz (BFSG)

Erfahren Sie alles über das Gesetz, das zur Umsetzung der EU-Richtlinie über Barrierefreiheitsanforderungen dient, einschließlich der Ziele, Anwendungen und Auswirkungen.

CAPTCHA

Verstehen Sie, was CAPTCHA ist und wie es die Sicherheit im Web verbessert, während gleichzeitig Herausforderungen für die Zugänglichkeit entstehen können.

Color Accessibility

Erfahren Sie, wie Color Accessibility die Zugänglichkeit von digitalen Inhalten durch bewusste Farbwahl und Kontraste verbessert.

Compliance (Konformität)

Erfahren Sie, was Compliance im Kontext der digitalen Barrierefreiheit bedeutet und wie Sie sicherstellen können, dass Ihre digitalen Produkte und konform sind.

Contrast Enhancement

Lernen Sie, was Contrast Enhancement bedeutet und wie es beiträgt, die Lesbarkeit von Texten für Menschen mit Sehbehinderungen zu verbessern.

Digitale Barrierefreiheit (DA)

Erfahren Sie, was digitale Barrierefreiheit bedeutet und wie Sie sicherstellen können, dass Ihre digitalen Inhalte für alle zugänglich sind.

Diktieren (Dictation)

Entdecken Sie, wie Diktieren die digitale Barrierefreiheit verbessert, indem es Nutzern ermöglicht, Text durch Spracheingabe zu generieren.

European Accessibility Act (EAA)

Der European Accessibility Act revolutioniert die digitale Barrierefreiheit in der EU. Erfahren Sie, wie Sie die gesetzlichen Anforderungen bis 2025 meistern.

Farbkontrast

Erfahre, was Farbkontrast ist, die Bedeutung für die digitale Barrierefreiheit und wie Sie sicherstellen können, dass Ihre digitalen Inhalte zugänglich sind.

Headless

Erfahren Sie, wie die Trennung von Backend und Frontend die Entwicklung agiler, anpassungsfähiger digitaler Erlebnisse ermöglicht.

Keyboard Navigation

Erfahren Sie, was Keyboard Navigation bedeutet und wie sie die Zugänglichkeit von Webseiten durch die reine Nutzung der Tastatur verbessert.

Konformität (Conformance)

Vertiefen Sie Ihr Verständnis von Konformität im Kontext der digitalen Barrierefreiheit, entdecken Sie, warum sie entscheidend ist.

Leichte Sprache und Einfache Sprache

Erfahren Sie mehr über Leichte und Einfache Sprache, zwei wichtige Formen der sprachlichen Vereinfachung, die darauf abzielen, Texte für Menschen zugänglicher zu machen.

Lupe (Magnification) und Digitale Barrierefreiheit

Erfahren Sie alles über die Nutzung von Lupenfunktionen zur Verbesserung der digitalen Barrierefreiheit, entdecken Sie, wie Vergrößerungswerkzeuge die Zugänglichkeit erhöhen, und lernen Sie Best Practices für die Implementierung in digitalen Inhalten kennen.

Offene Beschriftungen (Open Captions) und Digitale Barrierefreiheit

Entdecken Sie, wie offene Beschriftungen (Open Captions) die Zugänglichkeit von Videoinhalten verbessern, indem sie eine permanente Untertitelung bieten, die für alle Zuschauer sichtbar ist, und lernen Sie, wie Sie Open Captions effektiv in Ihren digitalen Medien einsetzen können.

Operabilität in der Digitalen Barrierefreiheit

Entdecken Sie, warum Operabilität ein Schlüsselaspekt der digitalen Barrierefreiheit ist, und lernen Sie, wie Sie sicherstellen können, dass Ihre digitalen Inhalte und Anwendungen für alle Nutzer bedienbar sind.

Responsive Design

Erfahren Sie, was Responsive Design ist und wie es durch flexible und adaptive Layouts die Zugänglichkeit von Webseiten verbessert.

Semantic HTML

Erfahren Sie, was Semantic HTML ist und wie es die Webzugänglichkeit durch verbesserte Strukturierung und Bedeutung von Webinhalten unterstützt.

Silktide Accessibility Checker

Entdecken Sie, wie der Silktide Accessibility Checker Ihre Website WCAG-konform und zugänglich für alle macht. Umfassende Prüfungen, einfache Lösungen.

Stark

Stark: Die All-in-One-Plattform für digitale Barrierefreiheit. Beschleunigen Sie Compliance und Workflows mit integrierten Tools für Designer und Entwickler.

Text-to-Speech

Erfahren Sie, was Text-to-Speech ist, wie es funktioniert und wie es digitale Zugänglichkeit für Menschen mit Sehbehinderungen oder Leseschwierigkeiten erhöht.

Universal Design

Entdecken Sie, wie Universal Design hilft, Produkte, Umgebungen und digitale Medien für alle Menschen nutzbar zu machen.

Untertitel für Hörgesschädigte

Erfahren Sie, was Closed Captions sind und wie sie die Zugänglichkeit von audiovisuellen Medien für Gehörlose und Schwerhörige verbessern.

Voice Recognition

Erfahren Sie mehr über Voice Recognition und wie sie die Interaktion mit digitalen Geräten für Menschen mit verschiedenen Behinderungen vereinfacht.