NCA Social Media
Erstellt:
Aktualisiert:
Autor:
Roland Golla
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.