Barrierefreie Formulare mit TYPO3

So bekommst Du Deine Webformulare mit TYPO3 durch die nächsten BITV-Test und WCAG konform.

0 Kommentare

Auf dem TYPO3 Camp Berlin 2025 hatte ich einen Talk zu "Barrierefreie Webformulare mit TYPO3". Zu meiner Freude wurde ich dafür sogar mit dem Titel "Bester Talk" aller 42 Präsentationen des T3Camp Berlin" geadelt. Danke!

Hier gibt es die   Präsentation "Barrierefreie Formulare mit TYPO3" zum herunterladen (PDF). Ich habe auch angefangen diesen Blogpost zu schreiben und werde ich Schritt für Schritt erweitern, bis er mehr oder weniger der Präsentation entspricht.

Was HTML-Formulartypen gibt es auf Websites? 

Wenn wir an barrierefreie Formulare danke, haben wir oft nur Kontaktformulare im Sinn und vergessen die Barrierefreieheit der anderen, weniger offensichtlichen Formulare und rasseln dafür durch den BITV-Test. Darum – HTML- oder Webformulare gibt es in sehr verschiedenen Ausprägungen auf Websites:

  • Kontaktformular, Bestellformular
  • Suchformular
  • Newsletter-Anmelde-Formulare
  • Login-Formulare
  • Filter-Formular (z.B. Shop Produktfilter)
  • Ein Schalter/Switch - z.B. Darkmode/Lightmode
Screenshots nicht-barrierefreier Web-Formulare (z.B. Suchformular, Cookie-Banner, Filter-Funktion)
Fast all diese TYPO3-Formulare sind nicht barrierefrei.

Relevante WCAG-Kriterien für Formulare?

Die vier WCAG-Prinzipien – Wahrnehmbar (1), Bedienbar (2), Verständlich (3) und Robust (4) – stellen das technische und konzeptionelle Fundament dar, um sicherzustellen, dass digitale Inhalte von allen Nutzern, unabhängig von ihren Fähigkeiten, erfasst, navigiert, interpretiert und mit deren Technologien verarbeitet werden können. In allen vier Bereichen finden sich Anforderungen an HTML-Formulare / TYPO3-Formulare.

1. Wahrnehmbar

Das Prinzip Wahrnehmbar stellt bei Formularen sicher, dass alle Informationen (Texte, Fehler, Feldgrenzen) ausreichende Kontraste aufweisen, Farbe nicht das einzige Mittel zur Informationsvermittlung ist und für alle nicht-textuellen Inhalte (wie Captchas) geeignete Text-Alternativen vorhanden sind, damit der Inhalt von assistierenden Technologien korrekt erfasst werden kann. 

Folgende WCAG-Kriterien sind relevant:

2. Bedienbar

Das Prinzip Bedienbar stellt bei Formularen sicher, dass alle Funktionen und interaktiven Elemente (Eingabefelder, Buttons, Links) vollständig über die Tastatur zugänglich sind, dass eine klare Fokus-Reihenfolge eingehalten wird und die Fokusanzeige stets sichtbar ist, um eine reibungslose Navigation zu gewährleisten.

Folgende WCAG-Kriterien sind relevant:

  • Tastaturbedienung (WCAG Kriterium 2.1.1, Level A)
  • Fokus sichtbar: Logische Reihenfolge
  • beim Tabbing (WCAG Kriterium 2.4.7 , Level AA)
  • Section Headings (WCAG Kriterium 2.4.10, Level A)
  • Fokus nicht verdeckt z.B. durch Sticky-Elemtente (WCAG Kriterium 2.4.11, Level AA, neu in WCAG 2.2)
  • Zielgröße mind. 44 px für Buttons (WCAG Kriterium 2.5.5, Level AA)
  • Ziehbewegungen: Alternativen für Drag-and-Drop, Slider (WCAG Kriterium 2.5.7, AA, neu in WCAG 2.2.)

3. Verständlich

Das Prinzip Verständlich stellt bei Formularen sicher, dass alle Eingabefelder und Anweisungen klar, logisch und programmatisch verknüpft sind und Nutzer bei Fehlern präzise, textbasierte Korrekturhilfen erhalten, um die Aufgabe erfolgreich und vorhersehbar abzuschließen.

Folgende WCAG-Kriterien sind relevant:

  • Eingabe ändert nichts: keine Änderung ohne Abschicken (WCAG Kriterium 3.2.2, Level A)
  • Fehler-Identifikation: Fehlermeldungen als Text (WCAG Kriterium 3.3.1, Level A)
  • Beschriftungen oder Anweisungen: jedes Eingabefeld hat programmatisch verknüpfte Beschreibung (WCAG Kriterium 3.3.2, Level A)
  • Korrektur-Vorschläge: Korrekturhilfen in der Fehlermeldung (WCAG Kriterium 3.3.3, Level AA)
  • Fehler-Vermeidung bei rechtlich, finanziell relevanten Daten, z.B. Rückgängig oder Überprüfen (WCAG Kriterium 3.3.4, Level AA)

4. Robust

Das Prinzip Robust stellt bei Formularen sicher, dass das technische Fundament des Codes (HTML, ARIA) solide ist, damit die Inhalte zuverlässig von einer großen Bandbreite an Benutzeragenten – insbesondere assistierenden Technologien wie Screenreadern – interpretiert werden können und Informationen über den Zustand (z.B. Fehler- oder Erfolgsmeldungen) mithilfe von ARIA-Live-Regionen dynamisch übermittelt werden.

Folgende WCAG-Kriterien sind relevant:

  • Name, Rolle, Wert: Semantik (type, rolle, checked, required) und ARIA (WCAG Kriterium 4.1.2, A)
  • Status Messages: Aria-Live  (WCAG Kriterium 4.1.3, AA)
  • Entfällt in WCAG 2.2: Kriterium 4.1.1 Parsing (Level A): Website ist HTML/XML Standardkonform

TYPO3 Fluid für Formulafeld mit Validation 

<f:form.validationResults for="bday">
  <f:variable name="errorDescribedBy"><f:if condition="{validationResult.flattenedErrors}">bday-error</f:if></f:variable>
<f:form.textfield
   property="date"
   placeholder="TT/MM/YYYY"
   autocomplete="bday"
   required="{settings.bday.required as boolean}"
   aria="{
     'required':'true',
     'describedby':'bday-help {errorDescribedBy}'
   }"
/>

Kontakt, Fragen, Support?

Bei Fragen, Supportwünschen bitte melden bei Tom @LinkdedIn oder ab in die Kommentare damit!

Kommentieren Alle Blogposts

Kommentare

Keine Kommentare

Kommentar schreiben

* Diese Felder sind erforderlich