Kontakt-Formular BFSG-konform: eine Checkliste für Web-Entwickler

Die Formulare sind die wichtigsten Stellen der Interaktion auf Deiner Website. Daher ist es essenziell, dass sie für alle Nutzer zugänglich sind – unabhängig von ihren Fähigkeiten oder den verwendeten Technologien. Diese Checkliste aus meinem vollständigen Leitfaden zu barrierefreien Formularen hilft Dir dabei, die wichtigsten Aspekte der Barrierefreiheit in Deinen Formularen zu überprüfen.

Checkliste für Grundstruktur & Anweisungen

• Hat jedes Formularfeld ein permanent sichtbares <label>-Element? [1]
• Ist das <label>-Element vor dem zugehörigen Eingabefeld positioniert? [2]
• Ist jedes <label> über das for-Attribut mit der id des zugehörigen Feldes verknüpft? [3]
• Sind die IDs aller Formular-Elemente auf der Seite einzigartig? [4]
• Gibt es vor dem Formular allgemeine Anweisungen (z.B. zur Kennzeichnung von Pflichtfeldern) und/oder eine Fehlerübersicht? [5]
• Sind Pflichtfelder visuell (z.B. *) UND programmatisch (required, aria-required="true") gekennzeichnet? [6]
• Haben alle interaktiven Elemente (Buttons, Links, Radio-Buttons, Checkboxen) eine Mindest-Klickfläche von 24x24 CSS-Pixeln? [7]
• Gibt es kein horizontales Scrollen bei kleinen Bildschirmgrößen (z.B. 320px Breite)? [8]

Tastaturbedienbarkeit

• Ist die Fokus-Reihenfolge beim Navigieren mit der Tab-Taste logisch und intuitiv? [9]
• Ist der Tastaturfokus (z.B. der outline) jederzeit deutlich sichtbar und hat ausreichend Kontrast? [10]

Gruppierung der Eingabefelder

• Sind alle Gruppen von Radio-Buttons und Checkboxen zwingend in einem <fieldset> zusammengefasst? [11]
• Haben diese <fieldset>-Gruppen eine aussagekräftige <legend>, welche die "Frage" an die Gruppe stellt? [12]
• Werden thematisch stark verwandte Textfelder (z.B. "Name & Vorname" oder eine "Rechnungsadresse") ebenfalls (als Best Practice) in einem <fieldset> mit <legend> gruppiert?

Hilfetexte & Eingabe-Unterstützung

• Haben Felder mit speziellen Formatanforderungen einen sichtbaren Hilfetext? [1]
• Ist dieser Hilfetext über aria-describedby mit dem Feld verknüpft? [13]
• Haben alle Felder, die persönliche oder bekannte Daten abfragen (Name, E-Mail, Telefon, Adresse), das korrekte autocomplete-Attribut? [14], [15]
• Werden placeholder-Attribute nur ergänzend verwendet und enthalten keine essenziellen Informationen? [16]
• Haben alle placeholder-Attribute ausreichenden Kontrast (mindestens 4.5:1) und sind sie als Hilfetext erkennbar (z.B. durch Kursivschrift)? [17]

Fehlerbehandlung

• Wird die Standard-Validierung des Browsers mit novalidate unterdrückt?
• Erscheint bei einem Fehler eine Fehlerzusammenfassung am Anfang des Formulars? [6]
• Hat der Container der Zusammenfassung role="alert" und tabindex="-1"? [18]
• Wird der Fokus bei einem Fehler programmgesteuert auf die Zusammenfassung gesetzt? [6]
• Enthält die Zusammenfassung klickbare Links, die korrekt zum jeweiligen Feld (bzw. zum ersten Element einer Gruppe wie Radio-Buttons) springen? [19]
• Sind die Link-Texte in der Zusammenfassung präzise und hilfreich (z.B. durch Nutzung von data-errorsummary-label bei langen Checkbox-Texten)?
• Wird für jedes fehlerhafte Feld eine spezifische Inline-Fehlermeldung angezeigt? [20]
• Erhält jedes fehlerhafte Feld dynamisch das Attribut aria-invalid="true"? [21]
• Wird das <label> oder die <legend> eines fehlerhaften Feldes sowohl mit Farbe als auch mit einem textlichen Präfix (z.B. "Fehler: ") markiert? [22]
• Werden alle Fehlermeldungen, aria-invalid-Attribute und Label-Fehlerzustände (Präfix/Farbe) bei einer erneuten Prüfung (z.B. resetErrors()) entfernt? [20]

Nach dem Absenden

Sobald der Nutzer das Formular absendet, sollte er über den Status des Absendevorgangs informiert werden – sei es durch eine Weiterleitung, eine Erfolgsmeldung oder eine Fehlermeldung.

Absendestatus

• Wird der "Senden"-Button sofort nach dem Klick (und erfolgreicher Validierung) deaktiviert, um doppeltes Absenden zu verhindern? [23]
• Wird der "Beschäftigt"-Zustand visuell angezeigt (z.B. "Wird gesendet...", Spinner)?
• Wird der "Beschäftigt"-Zustand programmatisch über eine aria-live-Region (role="status") angesagt? [24]

Finale Status (falls keine Weiterleitung erfolgt)

• Wird eine Erfolgs- oder Server-Fehlermeldung in einer role="alert"-Region angezeigt? [18]
• Wird der Tastaturfokus programmatisch auf den Beginn dieser Meldung gesetzt (.focus()), sobald sie erscheint?
• Wird bei einem Erfolg das Formular ausgeblendet, um Verwirrung zu vermeiden?
• Enthält die finale Statusmeldung einen sichtbaren Button (z.B. "Erneut ausfüllen" / "Erneut versuchen"), um das Formular zurückzusetzen?
• Wird nach dem Klick auf den Reset-Button das Formular zurückgesetzt, die Statusmeldung ausgeblendet und das Formular wieder angezeigt?
• Wird der Fokus nach dem Zurücksetzen programmatisch auf das erste Feld des Formulars gesetzt?
• Wird bei einem Server-Fehler der Sende-Button wieder aktiviert (oder bleibt aktiv), damit der Nutzer es erneut versuchen kann? [23]

Schlusswort

Die Barrierefreiheit von Formularen ist entscheidend, um sicherzustellen, dass alle Nutzer problemlos mit Deiner Website interagieren können. Nutze diese Checkliste, um Deine Formulare zu überprüfen und sicherzustellen, dass sie den besten Praktiken der Barrierefreiheit entsprechen. Für eine detaillierte Erklärung und weitere Tipps empfehle ich Dir, meinen vollständigen Leitfaden zu barrierefreien Formularen zu lesen.

Haftungsausschluss

Der Inhalt dieser Checkliste dient ausschließlich zu Informationszwecken und stellt keine Rechtsberatung dar. Obwohl ich mich bemühe, genaue und aktuelle Informationen bereitzustellen, übernehme ich keine Gewähr für die Vollständigkeit, Richtigkeit oder Aktualität der bereitgestellten Informationen. Die Einhaltung der Barrierefreiheitsstandards kann je nach spezifischem Kontext und Anwendungsfall variieren. Es wird empfohlen, bei der Implementierung von barrierefreien Formularen professionelle Beratung in Anspruch zu nehmen und regelmäßige Tests mit echten Benutzern durchzuführen, um sicherzustellen, dass die Anforderungen der WCAG-2.2-Richtlinien erfüllt werden. Ich hafte nicht für Schäden oder Verluste, die sich aus der Nutzung oder dem Vertrauen auf die in diesem Leitfaden enthaltenen Informationen ergeben.

1. W3C, „Success Criterion 3.3.2 Labels or Instructions“, 2023, [Online]. Verfügbar unter: https://www.w3.org/TR/WCAG22/#labels-or-instructions ⤴
2. W3C, „G162: Positioning labels to maximize predictability of relationships“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G162 ⤴
3. W3C, „H44: Using label elements to associate text labels with form controls“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/html/H44 ⤴
4. W3C, „H93: Ensuring that id attributes are unique on a web page“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/html/H93 ⤴
5. W3C, „G93: Providing open (always visible) captions“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G93 ⤴
6. W3C, „G83: Providing text descriptions to identify required fields that were not completed“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G83 ⤴
7. W3C, „Success Criterion 2.5.8 Target Size (Minimum)“, 2023, [Online]. Verfügbar unter: https://www.w3.org/TR/WCAG22/#target-size-minimum ⤴
8. W3C, „Success Criterion 1.4.10 Reflow“, 2023, [Online]. Verfügbar unter: https://www.w3.org/TR/WCAG22/#reflow ⤴
9. W3C, „Success Criterion 2.4.3 Focus Order“, 2023, [Online]. Verfügbar unter: https://www.w3.org/TR/WCAG22/#focus-order ⤴
10. W3C, „Success Criterion 2.4.7 Focus Visible“, 2023, [Online]. Verfügbar unter: https://www.w3.org/TR/WCAG22/#focus-visible ⤴
11. W3C, „Success Criterion 1.3.1 Info and Relationships“, 2023, [Online]. Verfügbar unter: https://www.w3.org/TR/WCAG22/#info-and-relationships ⤴
12. W3C, „H71: Providing a description for groups of form controls using fieldset and legend elements“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/html/H71 ⤴
13. W3C, „ARIA1: Using the aria-describedby property to provide a descriptive label for user interface controls“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA1 ⤴
14. W3C, „H98: Using HTML autocomplete attributes“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/html/H98 ⤴
15. W3C, „Success Criterion 1.3.5 Identify Input Purpose“, 2023, [Online]. Verfügbar unter: https://www.w3.org/TR/WCAG22/#identify-input-purpose ⤴
16. W3C, „F82: Failure of Success Criterion 3.3.2 by visually formatting a set of phone number fields but not including a text label“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/failures/F82 ⤴
17. W3C, „Success Criterion 1.4.3 Contrast (Minimum)“, 2023, [Online]. Verfügbar unter: https://www.w3.org/TR/WCAG22/#contrast-minimum ⤴
18. W3C, „ARIA19: Using ARIA role=alert or Live Regions to Identify Errors“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA19 ⤴
19. W3C, „G139: Creating a mechanism that allows users to jump to errors“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G139 ⤴
20. W3C, „G85: Providing a text description when user input falls outside the required format or values“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G85 ⤴
21. W3C, „ARIA21: Using aria-invalid to Indicate An Error Field“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA21 ⤴
22. W3C, „Success Criterion 1.4.1 Use of Color“, 2023, [Online]. Verfügbar unter: https://www.w3.org/TR/WCAG22/#use-of-color ⤴
23. W3C, „Success Criterion 3.3.4 Error Prevention (Legal, Financial, Data)“, 2023, [Online]. Verfügbar unter: https://www.w3.org/TR/WCAG22/#error-prevention-legal-financial-data ⤴
24. W3C, „Success Criterion 4.1.3 Status Messages“, 2023, [Online]. Verfügbar unter: https://www.w3.org/TR/WCAG22/#status-messages ⤴