Accessibility
Barrierefreie Formulare: Labels, Fehler und mehrstufige Anfragen
Ein barrierefreies Formular macht bei jedem Schritt deutlich, welche Angaben benötigt werden, wie Fehler korrigiert werden können und ob die Übermittlung tatsächlich gelungen ist. Dafür müssen sichtbare Beschriftungen, programmatische Zuordnungen, Tastaturbedienung und Rückmeldungen zusammenpassen. Besonders bei mehrstufigen Anfragen reicht es nicht, einzelne Eingabefelder zu prüfen: Auch Zurücknavigation, Dateiupload, Sitzungsablauf und Bestätigung gehören zum vollständigen Nutzungsvorgang.
Dieser Beitrag zeigt die Umsetzung anhand einer ausdrücklich hypothetischen Projektanfrage: Kund:innen wählen eine Leistung, beschreiben ihr Vorhaben, hinterlegen Kontaktdaten und laden optional ein Briefing hoch. Die Beispiele sind keine dokumentierten Kund:innenergebnisse. Als technischer Maßstab dient WCAG 2.2 AA einschließlich aller anwendbaren Kriterien der Stufen A und AA. Ein technischer Test ersetzt jedoch keine vollständige rechtliche Bewertung.
1. Beginnen Sie mit dem Weg durch das Formular
Definieren Sie zuerst, welche Informationen wirklich erforderlich sind. Für die hypothetische Erstberatung könnten Name, E-Mail-Adresse und eine kurze Beschreibung genügen. Telefonnummer, Organisation und Projektunterlagen bleiben optional, sofern der tatsächliche Prozess sie nicht zwingend benötigt. Jedes zusätzliche Pflichtfeld schafft eine weitere mögliche Hürde. Fragen Sie deshalb nicht nur, ob ein Feld technisch zugänglich ist, sondern auch, ob sein Zweck für Nutzer:innen nachvollziehbar ist.
Beschreiben Sie anschließend den gesamten Ablauf einschließlich seiner Fehlerpfade. Eine Person öffnet das Formular per Tastatur, trägt eine internationale Telefonnummer ein, kehrt zum vorherigen Schritt zurück und sendet bei instabiler Verbindung ab. Was bleibt erhalten? Wo steht der Fokus? Welche Meldung erscheint? Solche konkreten Wege liefern bessere Anforderungen als die pauschale Vorgabe „Formular barrierefrei machen“. Halten Sie erwartete Zustände und beobachtbare Ergebnisse fest, bevor Design und Entwicklung beginnen.
2. Labels, Hinweise und Gruppen eindeutig verbinden
Jedes Eingabefeld braucht einen programmatisch bestimmbaren zugänglichen Namen. Verwenden Sie für die hier beschriebenen Formularfelder dauerhaft sichtbare Textbeschriftungen. In besonderen Kontexten können auch eindeutige sichtbare Symbole oder andere klare kontextuelle Hinweise den Zweck vermitteln; ein Platzhalter allein ist kein verlässlicher Ersatz. Bei nativen HTML-Feldern verbinden Sie ein label über sein for-Attribut mit der eindeutigen id des Eingabefelds. Ein Platzhalter ersetzt diese Beschriftung nicht: Er verschwindet beim Tippen und kann als Beispielwert missverstanden werden. Ein hypothetisches Feld heißt sichtbar „E-Mail-Adresse“, nicht nur intern „email“. Damit können auch Nutzer:innen einer Sprachsteuerung die sichtbare Bezeichnung verwenden.
Zusätzliche Hinweise gehören neben das Feld und werden bei Bedarf über aria-describedby zugeordnet. „Wir verwenden diese Adresse für die Antwort auf Ihre Anfrage“ erklärt den Zweck; ein zweiter Hinweis kann ein tatsächlich erforderliches Format erläutern. Vermeiden Sie widersprüchliche Namen durch zusätzliche ARIA-Beschriftungen. Native Semantik ist meist einfacher und robuster als ein nachträglich aufgebautes System aus Rollen und Attributen.
Zusammengehörige Auswahlfelder benötigen einen Gruppenkontext. Für die Auswahl „Welche Unterstützung benötigen Sie?“ eignen sich fieldset und legend mit verständlich beschrifteten Optionen. Pflichtangaben kennzeichnen Sie vorab und am jeweiligen Feld, nicht ausschließlich durch Farbe oder ein unerklärtes Sternchen. Die WAI Forms Tutorial erläutert diese Zusammenhänge zwischen Labels, Gruppen und Anweisungen.
3. Eingabezweck, Autocomplete und Formate abstimmen
Wählen Sie passende native Feldtypen, ohne ihnen die gesamte Validierung zu überlassen. type=email unterstützt die E-Mail-Eingabe, type=tel die Telefonnummer. inputmode kann eine geeignete Bildschirmtastatur anfordern, legt aber keine zulässigen Werte fest. Telefonnummern sind beispielsweise keine Rechenwerte: Ein Zahlenfeld kann führende Nullen oder internationale Schreibweisen erschweren. Akzeptieren Sie Leerzeichen und übliche Trennzeichen, wenn Ihr nachgelagerter Prozess diese sicher normalisieren kann.
Für Angaben über die ausfüllende Person helfen passende autocomplete-Tokens wie name, given-name, family-name, email oder tel. Nutzen Sie nur Werte, die zum tatsächlichen Zweck passen, und unterscheiden Sie mehrere Adresskontexte bei Bedarf durch entsprechende Abschnittskennungen. Autocomplete ersetzt weder Label noch Prüfung. Testen Sie den Ablauf mit ausgefülltem Browserprofil: Werden Werte richtig zugeordnet, bleiben sie beim Schrittwechsel erhalten und werden automatisch ausgefüllte Felder von Ihrer Formularlogik erkannt?
Verlangen Sie kein enges Format ohne fachlichen Grund. Ein hypothetisches Datumsfeld braucht eine vorab verständliche Formatangabe und eine zugängliche Eingabemöglichkeit; ein grafischer Kalender allein genügt nicht. Internationale Namen dürfen nicht an einer auf ASCII-Buchstaben beschränkten Prüfung scheitern. Dokumentieren Sie solche Regeln als Produktentscheidung, damit Frontend und Backend dieselben Eingaben akzeptieren.
4. Validieren, wenn eine Rückmeldung hilfreich ist
Eine Fehlermeldung während des ersten Buchstabens ist selten hilfreich. Prüfen Sie abhängig vom Feld nach abgeschlossener Eingabe oder beim Absenden. Während der Korrektur kann eine zurückhaltende Aktualisierung sinnvoll sein. Vermeiden Sie jedoch, bei jedem Tastendruck neue Meldungen auszugeben. Ein Screenreader soll nicht die laufende Eingabe ständig mit „ungültig“ unterbrechen. Definieren Sie ausdrücklich, wann ein unberührtes Feld, ein geprüftes Feld und ein korrigiertes Feld welche Darstellung erhalten.
Clientseitige Validierung verbessert die unmittelbare Rückmeldung; serverseitige Validierung bleibt für die Verarbeitung notwendig. Beide müssen dieselben fachlichen Regeln verständlich abbilden. Eine gültige Adresse kann beispielsweise dennoch an einem Serverproblem scheitern. Dann lautet die Nachricht nicht „E-Mail-Adresse ungültig“, sondern beschreibt das Übermittlungsproblem. Bewahren Sie bereits eingegebene Werte und unterscheiden Sie Eingabefehler, Verbindungsfehler und interne Fehler. Nutzer:innen dürfen nicht für technische Störungen zur Änderung korrekter Angaben aufgefordert werden.
5. Feldfehler und Fehlerübersicht gemeinsam einsetzen
Ein guter Feldfehler nennt das Problem und den nächsten sinnvollen Schritt: „Geben Sie eine E-Mail-Adresse mit einem @-Zeichen ein“ ist hilfreicher als „Ungültiger Wert“. Ordnen Sie die Meldung dem Feld programmatisch zu und setzen Sie bei festgestelltem Fehler aria-invalid=true. Entfernen oder aktualisieren Sie den Fehlerzustand nach erfolgreicher Korrektur. Ein roter Rahmen kann ergänzen, darf aber nicht das einzige Fehlersignal sein.
Bei mehreren Fehlern hilft nach dem Absenden eine Übersicht am Beginn des Formulars. Eine mögliche Umsetzung setzt den Fokus auf einen programmatisch fokussierbaren Übersichtscontainer mit der Überschrift „Bitte korrigieren Sie drei Angaben“. Darunter führen aussagekräftige Links zu den betroffenen Feldern. Beim Aktivieren muss tatsächlich das Eingabefeld den Fokus erhalten, nicht nur die Seite zu seiner Position scrollen. Die Anzahl wird bei Änderungen konsistent aktualisiert.
Entscheiden Sie bewusst zwischen Fokusversetzung und zusätzlichen Live-Ankündigungen, damit die gesamte Liste nicht doppelt vorgelesen wird. Die WAI Forms Tutorial: User Notifications beschreibt zugängliche Fehler- und Erfolgsmeldungen. Als Abnahmebeleg eignet sich ein protokollierter Durchlauf: absenden, Übersicht hören, Fehlerlink aktivieren, Feldbeschreibung verstehen, korrigieren und erneut absenden, ohne andere Eingaben zu verlieren.
6. Mehrstufige Anfragen als zusammenhängenden Vorgang bauen
Teilen Sie ein Formular nur dann auf, wenn die Gliederung eine echte Orientierungshilfe bietet. Unsere hypothetische Anfrage könnte aus „Vorhaben“, „Kontakt“ und „Prüfen und senden“ bestehen. Zeigen Sie den aktuellen Schritt als Text und kennzeichnen Sie ihn programmatisch, beispielsweise mit aria-current=step innerhalb einer geordneten Schrittübersicht. Farbe allein reicht nicht. Noch nicht verfügbare Schritte sollten nicht wie funktionierende Links erscheinen.
Nach „Weiter“ prüfen Sie den aktuellen Schritt. Bei Erfolg wechselt die Ansicht und der Fokus gelangt zu einer aussagekräftigen Überschrift des nächsten Schritts. Bei einem Seitenwechsel gehört auch ein passender Dokumenttitel dazu. „Zurück“ erhält bereits erfasste Werte und darf nicht an noch unvollständigen Pflichtangaben des aktuellen Schritts scheitern. Testen Sie zusätzlich die browserseitige Zurücknavigation, statt ausschließlich die eigene Schaltfläche zu berücksichtigen.
Bereits im selben Vorgang angegebene Informationen sollten nicht unnötig erneut verlangt werden. WCAG 2.2 behandelt dies unter „Redundant Entry“, mit definierten Ausnahmen. Ändert jemand die gewählte Leistung, erläutern Sie, welche Folgeangaben dadurch entfallen oder neu erforderlich werden. Die WAI-Übersicht zu WCAG 2.2 ordnet dieses und weitere hinzugekommene Kriterien ein.
7. Fokus, Tastatur und mobile Darstellung zusammen prüfen
Die Tab-Reihenfolge folgt der sichtbaren und logischen Reihenfolge. Verwenden Sie keine positiven tabindex-Werte, um ein ungeeignetes Layout nachträglich zu reparieren. Alle Aktionen benötigen passende bedienbare Elemente: „Weiter“ ist eine Schaltfläche, nicht eine klickbare Fläche ohne Tastaturverhalten. Der Fokus muss erkennbar bleiben. Eine fixierte Fußleiste darf das fokussierte Feld nicht vollständig verdecken; planen Sie möglichst eine vollständig sichtbare Arbeitsposition.
Prüfen Sie das Formular außerdem mit vergrößertem Text und bei einer Breite von 320 CSS-Pixeln. Labels, Hinweise und Fehlermeldungen dürfen nicht abgeschnitten werden oder unzugängliche Überlagerungen bilden. Lange Dateinamen und deutschsprachige Fehlermeldungen sind dafür nützliche Testdaten. Ausreichende Kontraste betreffen nicht nur Text, sondern unter den jeweiligen Bedingungen auch relevante Begrenzungen von Bedienelementen. Die normativen Anforderungen stehen in WCAG 2.2; eine bestimmte Schriftfamilie wird dort nicht vorgeschrieben.
8. Dateiuploads ohne Drag-and-drop-Zwang ermöglichen
Ein Uploadbereich braucht eine bedienbare Dateiauswahl, auch wenn zusätzlich Drag-and-drop angeboten wird. Nennen Sie erlaubte Formate, Größenbegrenzungen und die zulässige Anzahl vor der Auswahl. Beschriften Sie den Upload nach seinem Zweck, etwa „Projektbriefing hinzufügen, optional“. Ein nativer Dateieingang ist oft eine gute Grundlage; ein individuell gestalteter Ersatz muss dessen zugängliche Bedienung tatsächlich erhalten.
Zeigen Sie ausgewählte Dateien mit Namen, Zustand und eindeutig beschrifteter Entfernen-Aktion. „Briefing.pdf entfernen“ ist bei mehreren Dateien verständlicher als mehrfach „Entfernen“. Nach dem Löschen wandert der Fokus zu einem sinnvollen verbleibenden Element. Unterscheiden Sie „ausgewählt“, „wird hochgeladen“, „wird geprüft“ und „verfügbar“, wenn diese Zustände im System existieren. Ein abgeschlossener Datentransfer bedeutet nicht automatisch, dass die serverseitige Prüfung erfolgreich war.
Bei einer abgelehnten Datei erklären Sie den konkreten Grund und erhalten die restliche Anfrage. Bei einem Verbindungsabbruch bieten Sie eine verständliche Wiederholung an. Testen Sie hypothetisch eine nicht erlaubte Datei, einen doppelten Dateinamen und einen Abbruch während des Uploads. Die Abnahme umfasst dabei auch die Ausgabe über assistive Technik und die Frage, ob das Formular trotz optionalem, fehlgeschlagenem Upload sinnvoll fortgesetzt werden kann.
9. Statusmeldungen dosiert und technisch zuverlässig ausgeben
Nicht jede Änderung benötigt einen Fokuswechsel. „Datei hochgeladen“ oder „Entwurf gespeichert“ kann als Statusmeldung ausgegeben werden, während die Person am aktuellen Feld weiterarbeitet. Verwenden Sie dafür eine geeignete programmatische Kennzeichnung, häufig eine bereits vorhandene Region mit role=status. Dringliche Fehlermeldungen brauchen eine bewusst gewählte Behandlung; role=alert ist keine pauschale Lösung für alle Rückmeldungen.
Die Erläuterung Understanding SC 4.1.3: Status Messages erklärt, wann Statusmeldungen ohne Fokusverschiebung programmatisch erkennbar sein müssen. Geben Sie bei Uploads nicht jede kleine Fortschrittsänderung als neue Ansage aus. Testen Sie stattdessen verständliche Zustandswechsel und das Abschlussresultat. Auch eine vorhandene Live-Region garantiert noch keine brauchbare Ausgabe: Zeitpunkt, DOM-Aktualisierung und verwendete Browser-Screenreader-Kombination müssen zusammen funktionieren.
10. Prüfung, Absenden und Bestätigung klar unterscheiden
Vor dem endgültigen Absenden zeigt eine Zusammenfassung die wesentlichen Angaben mit gezielten Bearbeitungsmöglichkeiten. Ein Link „Kontaktdaten bearbeiten“ führt zurück zum passenden Schritt, ohne andere Daten zu löschen. Für rechtliche Verpflichtungen, finanzielle Transaktionen und bestimmte Datenänderungen verlangt WCAG 3.3.4 passende Schutzmechanismen: mindestens Umkehrbarkeit, Prüfung mit Korrekturmöglichkeit oder Überprüfung und Bestätigung mit Korrekturmöglichkeit. Eine gewöhnliche Anfrage ist nicht automatisch eine solche Transaktion.
Während der Übermittlung verhindern Sie unbeabsichtigte Doppelübermittlungen und kommunizieren den Wartezustand. Die Backend-Architektur sollte Wiederholungen ebenfalls berücksichtigen. Eine Erfolgsmeldung erscheint erst, wenn das System den Eingang verlässlich bestätigt hat. „Vielen Dank für Ihre Anfrage“ allein ist knapp: Ergänzen Sie, was eingegangen ist und welcher nächste Schritt tatsächlich vorgesehen ist, ohne eine nicht zugesagte Antwortzeit zu erfinden.
Eine Bestätigungsseite erhält einen eindeutigen Titel und eine passende Fokusführung; eine Bestätigung innerhalb derselben Ansicht eine geeignete Ankündigung. Eine E-Mail kann ergänzen, ersetzt aber nicht die unmittelbare Rückmeldung. Bei unklarem Übermittlungsstatus behaupten Sie weder Erfolg noch sicheren Misserfolg. Erklären Sie die Unsicherheit und bieten Sie eine sichere Möglichkeit zur Klärung, damit Nutzer:innen nicht blind erneut absenden.
11. Abnahme anhand reproduzierbarer Belege organisieren
Prüfen Sie mindestens einen erfolgreichen Durchlauf und gezielt die kritischen Fehlerpfade. Dokumentieren Sie Ausgangszustand, Eingaben, Schritte, erwartetes Verhalten und beobachtetes Ergebnis. Bei einem Fokusfehler gehört etwa dazu, welches Element nach „Weiter“ aktiv ist und welche Überschrift angesagt wird. Automatisierte Prüfungen können fehlende Zuordnungen entdecken, beurteilen aber nicht vollständig, ob die Korrekturhinweise oder der gesamte Ablauf verständlich sind.
Ergänzen Sie Tastaturtests, Screenreader-Durchläufe, Vergrößerung, mobile Eingabe und serverseitige Fehlersimulationen. Verwenden Sie synthetische statt echter personenbezogener Testdaten. Vereinbaren Sie Regressionstests für gemeinsam genutzte Formularbausteine: Eine Änderung an der Fehlerkomponente betrifft möglicherweise mehrere Anfragen. Auch redaktionell geänderte Labels, neue Pflichtfelder und Uploadregeln brauchen eine erneute Prüfung ihres jeweiligen Nutzungskontexts.
12. Häufige Fragen und der nächste sinnvolle Schritt
Reicht eine automatische Formularprüfung?
Nein. Sie unterstützt die technische Kontrolle, ersetzt aber nicht die Prüfung von Fokusführung, verständlichen Meldungen, Datenübernahme und vollständigen Nutzungsvorgängen mit Tastatur und assistiven Technologien.
Sind mehrstufige Formulare grundsätzlich besser?
Nein. Sie helfen bei sinnvoll gegliederten, umfangreicheren Abläufen. Für wenige Angaben ist eine einzelne übersichtliche Seite oft einfacher. Entscheidend sind Orientierung, erhaltene Eingaben und verlässliche Navigation.
Fällt jedes Kontaktformular unter das österreichische BaFG?
Nein. Das BaFG gilt seit 28. Juni 2025 für erfasste Dienstleistungen, nicht pauschal für alle Websites. Informationsangebote und ausschließliches B2B sind grundsätzlich kein Verbraucher-E-Commerce; die Einordnung eines Kontaktformulars allein ist laut WKO umstritten. Details und Ausnahmen finden Sie im Österreich-Leitfaden zur barrierefreien Website.
Wie kann Zensations bei einem bestehenden Formular helfen?
Ein Barrierefreiheit-Audit kann einen konkreten Anfrageweg samt Fehlerzuständen untersuchen und nachvollziehbare Umsetzungsschritte priorisieren. Zensations, 2010 in Wien gegründet, unterstützt über seine Accessibility-Leistungen auch die Weiterentwicklung. Bringen Sie Formularvarianten, bekannte Probleme und einen Testzugang mit. WCAG und EN 301 549 sind nicht austauschbar; ein Audit ist keine vollständige Rechtsprüfung und keine Konformitätsgarantie.
Quellen und Prüfstand
Inhaltlich geprüft am 7. November 2026. Die folgenden Primärquellen begründen die technischen Empfehlungen; der verlinkte Österreich-Leitfaden vertieft die rechtliche Einordnung.
