Formulare5 Min. Lesezeit
Barrierefreie Formulare: Beschriftungen, Fehler, Tastatur
Was ein Online-Formular für alle bedienbar macht: Beschriftungen, Gruppen, verständliche Fehlermeldungen, Tastatur, Fokus und Zielgrössen — nach WCAG 2.2.

Eine Spitex-Organisation im Emmental nimmt Anfragen über ein Online-Formular entgegen: Name, Adresse, gewünschte Leistungen, ein Feld für Bemerkungen. Eines Tages ruft die Tochter einer Klientin an. Ihre Mutter sieht schlecht und hat versucht, das Formular mit der Vergrösserungsfunktion auszufüllen. Nach dem Absenden war die Seite rot, aber sie fand nicht heraus, was falsch war — die Meldung stand oben, weit ausserhalb des vergrösserten Ausschnitts.
Für eine Spitex, deren Klientinnen und Klienten oft älter sind, ist das kein Randfall. Viele solcher Hürden lassen sich mit ein paar Grundsätzen vermeiden, die das W3C beschreibt.
Wer Formulare anders bedient
Nicht alle füllen ein Formular mit Maus und Blick aus. Manche Menschen hören den Bildschirm mit einer Sprachausgabe, andere bedienen alles mit der Tastatur, vergrössern die Anzeige stark oder brauchen mehr Zeit, um Anweisungen zu verstehen. Dazu kommen Situationen, die jede Person treffen können: ein gebrochener Arm, ein Telefon in grellem Sonnenlicht, eine Sprache, die man nicht gut kennt.
Die Web Content Accessibility Guidelines (WCAG) des W3C sind der internationale Massstab dafür. Die Version 2.2 wurde am 5. Oktober 2023 veröffentlicht. Das W3C hat dazu eine eigene Anleitung für Formulare herausgegeben, die zuletzt im März 2026 aktualisiert wurde.
Beschriftungen
Die W3C-Anleitung beginnt mit dem Grundsatz, jedes Formularfeld mit einer Beschriftung zu
kennzeichnen, in der Regel mit dem HTML-Element label. Die Beschriftung ist mit dem Feld
verbunden — eine Sprachausgabe liest sie vor, sobald das Feld erreicht wird, und ein Klick auf
die Beschriftung setzt den Cursor ins Feld. Die WCAG verlangen Beschriftungen oder Anweisungen,
wenn Eingaben erwartet werden (Erfolgskriterium 3.3.2).
Ein grauer Hinweistext im Feld, der beim Tippen verschwindet, ersetzt keine Beschriftung: Sobald jemand zu schreiben beginnt, ist nicht mehr zu sehen, wofür das Feld gedacht war.
Automatisch ausfüllen lassen
Browser können Name, Adresse oder E-Mail-Adresse aus gespeicherten Angaben einsetzen, wenn das Formular sagt, wofür ein Feld gedacht ist. Die WCAG verlangen, dass der Zweck von Feldern für Angaben zur eigenen Person maschinenlesbar bestimmt werden kann (Erfolgskriterium 1.3.5). Für Menschen, denen das Tippen schwerfällt, erspart das viel Arbeit — und Tippfehler in der Adresse gleich mit.
Gruppen
Manche Felder gehören zusammen, etwa die Auswahl der Leistungen — Grundpflege, Hauswirtschaft,
Mahlzeitendienst — oder die Frage «Wer füllt das Formular aus?». Die W3C-Anleitung empfiehlt, solche
Gruppen mit den Elementen fieldset und legend zusammenzufassen. Dann hört eine Person mit
Sprachausgabe nicht nur «Hauswirtschaft, Kontrollkästchen», sondern auch, zu welcher Frage es
gehört.
Anweisungen am richtigen Ort
Die W3C-Anleitung empfiehlt, Hinweise zu geben, die beim Ausfüllen helfen — für das ganze Formular und für einzelne Felder. Entscheidend ist der Ort: Ein Hinweis zum Format eines Datums gehört vor das Feld, nicht erst in die Fehlermeldung. Und Pflichtfelder sind so gekennzeichnet, dass es auch ohne Farbe erkennbar ist, etwa mit dem Wort «Pflichtfeld».
Fehlermeldungen, die weiterhelfen
Die Mutter der Anruferin ist an einer typischen Stelle gescheitert. Die WCAG verlangen, dass ein erkannter Eingabefehler angezeigt und in Textform beschrieben wird (Erfolgskriterium 3.3.1), und dass, wenn möglich, ein Vorschlag zur Korrektur gemacht wird (Erfolgskriterium 3.3.3). Dazu kommt: Information darf nicht allein durch Farbe vermittelt werden (Erfolgskriterium 1.4.1).
Für die Spitex heisst das praktisch:
- Die Meldung steht beim betroffenen Feld, nicht nur oben auf der Seite.
- Sie sagt, was fehlt oder falsch ist — «Bitte geben Sie eine Postleitzahl mit vier Ziffern ein» statt «Ungültige Eingabe».
- Bereits ausgefüllte Felder bleiben ausgefüllt.
- Ein roter Rahmen allein genügt nicht; ein Text oder ein Symbol mit Text gehört dazu.
Tastatur und Fokus
Ein Formular muss sich vollständig mit der Tastatur bedienen lassen (Erfolgskriterium 2.1.1): von Feld zu Feld mit der Tabulatortaste, Auswahlen mit den Pfeiltasten, Absenden mit der Eingabetaste. Wo sich der Fokus gerade befindet, muss sichtbar sein (Erfolgskriterium 2.4.7).
WCAG 2.2 ergänzt dazu ein neues Kriterium: Erhält ein Element den Tastaturfokus, soll es zumindest teilweise sichtbar sein und nicht von anderen Inhalten verdeckt werden (Erfolgskriterium 2.4.11) — etwa von einem Hinweisbalken zu Cookies oder einer fixierten Kopfzeile.
Genug Platz zum Tippen
Auch die Grösse der Bedienelemente zählt. WCAG 2.2 verlangt mit dem neuen Erfolgskriterium 2.5.8, dass Ziele eine Mindestgrösse haben — 24 × 24 CSS-Pixel — oder genug Abstand zu anderen Zielen. Kleine Auswahlkästchen dicht untereinander sind für Menschen mit zittrigen Händen oder auf einem kleinen Bildschirm schwer zu treffen.
Nicht zweimal fragen
Ein weiteres neues Kriterium von WCAG 2.2 betrifft Formulare direkt: Informationen, die jemand im selben Vorgang schon eingegeben hat, sollen nicht noch einmal verlangt werden (Erfolgskriterium 3.3.7). Wer die Adresse der Klientin schon angegeben hat, soll sie für die Rechnungsadresse nicht erneut tippen müssen — ein «gleich wie oben» genügt.
Und beim Anmelden soll niemand ein Rätsel lösen, sich etwas merken oder etwas abschreiben müssen (Erfolgskriterium 3.3.8). Wie sich Formulare ohne solche Hürden vor Spam schützen lassen, beschreibt der Beitrag Spam in Kontaktformularen.
Lange Formulare
Für lange Formulare empfiehlt die W3C-Anleitung, sie in mehrere kleinere Schritte aufzuteilen und über den Fortschritt zu informieren — «Schritt 2 von 4». Das hilft allen, besonders aber Menschen, die mehr Zeit brauchen oder zwischendurch unterbrechen müssen.
Was in der Schweiz gilt
Das Behindertengleichstellungsgesetz verlangt von Behörden, dass ihre Dienstleistungen im Internet für Sehbehinderte ohne erschwerende Bedingungen zugänglich sind (Art. 14 Abs. 2 BehiG), und verbietet Privaten, die Dienstleistungen öffentlich anbieten, Menschen mit Behinderungen aufgrund ihrer Behinderung zu diskriminieren (Art. 6 BehiG). Der E-Government-Standard eCH-0059 stützt sich in der Version 3.0 auf die WCAG 2.1 und findet primär beim Gemeinwesen und bei konzessionierten Unternehmen Anwendung. Welche Pflichten für eine bestimmte Organisation gelten, hängt von ihrer Rolle ab.
Für die Spitex im Emmental
Die Spitex lässt ihr Formular überarbeiten: Jedes Feld hat eine sichtbare Beschriftung, die Leistungen sind als Gruppe zusammengefasst, Fehlermeldungen stehen beim Feld und sagen, was zu tun ist. Das Formular lässt sich mit der Tastatur ausfüllen, der Fokus ist deutlich sichtbar, und die Rechnungsadresse lässt sich mit einem Häkchen übernehmen. Die Tochter der Klientin hat es mit ihrer Mutter noch einmal ausprobiert.
In der Formulare-App, die wir entwickeln, werden Antworten im Browser der antwortenden Person verschlüsselt und erst bei der Empfängerin wieder lesbar. Welche Kriterien der Barrierefreiheit die Formulare der App erfüllen, beschreiben wir auf ihrer Seite, sobald sie erscheint.
Quellen
- 1.W3C: Web Content Accessibility Guidelines (WCAG) 2.2 (geprüft am 25. September 2026)
- 2.W3C WAI: What’s New in WCAG 2.2 (geprüft am 25. September 2026)
- 3.W3C WAI: Forms Tutorial (aktualisiert 27. März 2026) (geprüft am 25. September 2026)
- 4.Behindertengleichstellungsgesetz (BehiG, SR 151.3) (geprüft am 25. September 2026)
- 5.eCH-0059 Accessibility Standard V3.0 (geprüft am 25. September 2026)
SchweizerformAus dieser Idee ist Schweizerform geworden.
Online-Formulare mit Ende-zu-Ende-Verschlüsselung, entwickelt und gehostet in der Schweiz.