` klickbar gemacht wurde, ist ein klassischer Accessibility- und Wartbarkeitsfehler. Ein echter `
` bringt Tastatur- und Screenreader-Verhalten gratis mit.Pflichtfelder, Hilfetexte und Erwartungen klar kommunizieren Pflichtfelder nur mit einem Sternchen zu markieren, ist nicht per se falsch, aber selten ausreichend. Wichtig ist, dass die Information auch programmatisch verfügbar ist und nicht nur über Farbe transportiert wird.
In der Praxis funktioniert es gut, Pflichtfelder in der Beschriftung eindeutig zu benennen, etwa „E-Mail (Pflicht)“. Wer es knapper will, kann „* Pflichtfeld“ zusätzlich oberhalb erklären, aber das Feld selbst sollte weiterhin verständlich bleiben. Für die technische Seite kann `required` gesetzt werden, und falls ihr zusätzlich mit ARIA arbeitet, dann gezielt und nicht als Ersatz für Semantik.
Hilfetexte wie „Bitte Telefonnummer im Format +43 …“ gehören direkt zum Feld und müssen für assistive Technologien erreichbar sein. Dafür eignet sich `aria-describedby`, das auf die ID des Hilfetextes zeigt. So liest ein Screenreader beim Fokus auf das Feld nicht nur das Label, sondern auch die relevante Anleitung.
Tastaturführung: Fokus ist kein Detail Viele Entscheider:innen testen Formulare mit der Maus und sagen „passt“. Barrierefreiheit scheitert aber oft beim Tabben.
Der Fokus muss sichtbar sein. Nicht „irgendwie“, sondern eindeutig. Ein dünner Outline in Markenfarbe ist okay, solange Kontrast und Sichtbarkeit stimmen. Den Browser-Outline komplett zu entfernen ist ein häufiger Fehler, der dann mit „wir machen später was Schönes“ endet – und später nie passiert.
Die Tab-Reihenfolge muss logisch sein und der visuellen Reihenfolge folgen. Das ist vor allem bei mehrspaltigen Layouts und „kreativen“ Grid-Setups relevant. Ein Input rechts oben, der beim Tabben erst nach fünf anderen Elementen kommt, fühlt sich kaputt an.
Autofokus kann helfen, kann aber auch stören. Bei Formularen in Modals oder Offcanvas-Panels ist es sinnvoll, den Fokus sauber in das Modal zu setzen und innerhalb zu „trappen“, bis geschlossen wird. Bei normalen Seiten ist ein aggressiver Autofokus auf das erste Feld nicht immer ideal, weil Screenreader-Nutzer:innen sonst Kontext verlieren.
Validierung und Fehlermeldungen: sofort, verständlich, anspringbar WCAG-konforme Formulare scheitern besonders häufig an Fehlermeldungen. Dabei ist die Logik klar: Fehler müssen erkannt, beschrieben und auffindbar sein.
„Dieses Feld ist ungültig“ ist zu wenig. Besser ist: „Bitte geben Sie eine gültige E-Mail-Adresse ein, z. B. name@domain.at.“ Wenn ein Mindestformat nötig ist, erklärt es. Wenn ein Feld leer ist, sagt „Bitte ausfüllen“. Wenn ein Wert zu kurz ist, nennt die Mindestlänge.
Ob ihr inline validiert oder erst beim Absenden, hängt vom Kontext ab. Inline-Validierung kann hilfreich sein, solange sie nicht hektisch ist und nicht bei jedem Tastendruck „Fehler“ schreit. Ein pragmatischer Weg ist: erst validieren, wenn ein Feld verlassen wurde (on blur) oder beim Submit. Wichtig ist, dass Fehlermeldungen programmatisch angekündigt werden, damit Screenreader sie mitbekommen.
Für Felder mit Fehlerstatus braucht es eine klare visuelle Markierung, aber nicht nur über Rot. Ergänzt Text und setzt den Fokus sinnvoll. Ideal ist ein Fehler-Summary am Formularanfang, der nach dem Absenden erscheint und auf die Felder verlinkt. Klickt man einen Fehler im Summary, springt der Fokus ins betreffende Feld. Das ist nicht nur barrierefrei, sondern reduziert auch Support-Anfragen.
ARIA kann hier unterstützen, etwa über `aria-invalid=“true“` am betroffenen Feld und eine verknüpfte Fehlermeldung via `aria-describedby`. Wichtig ist: ARIA ersetzt kein Label und kein strukturiertes HTML. Es ergänzt dort, wo HTML allein nicht reicht.
Auswahlfelder, Dateiuploads und Spezialfälle Dropdowns sind ein eigenes Minenfeld. Ein natives „ ist accessibility-technisch meist die stabilste Wahl. Custom Selects sehen oft „besser“ aus, kosten aber massiv in Umsetzung und Testing: Tastatursteuerung, Screenreader-Ansagen, Fokusmanagement, Scroll-Verhalten. Wenn der Business-Case nicht zwingend ist, bleibt beim nativen Element und gestaltet es über das Drumherum.
Checkboxen und Radios brauchen ausreichend große Klickflächen. Gerade mobil ist das relevant. Wer nur den kleinen Kasten anklickbar macht, produziert Frust. Am besten ist, das Label klickbar zu machen, was mit korrekt gesetztem `` automatisch passiert.
Dateiuploads sollten klar beschreiben, welche Formate erlaubt sind und wie groß Dateien sein dürfen. Diese Infos gehören wieder in einen Hilfetext, der mit dem Feld verknüpft ist. Wenn ihr Drag-and-drop anbietet, muss es weiterhin einen normalen Upload-Button geben, der per Tastatur bedienbar ist.
Mehrschritt-Formulare können barrierefrei sein, sind aber anfälliger. Fortschrittsanzeige, „Zurück“-Logik, persistierte Eingaben und klare Überschriften pro Schritt sind Pflicht. Wenn ein Schritt Fehler hat, muss der Nutzer exakt wissen, was im aktuellen Schritt zu tun ist, ohne dass Informationen aus vorherigen Schritten verloren gehen.
Captcha, Spam-Schutz und DSGVO: das echte Spannungsfeld Spam-Schutz ist legitim. Viele Captchas sind aber eine Barriere – und manchmal auch ein Datenschutzthema. Je nach Lösung werden Daten an Dritte übertragen oder es entstehen Tracking-Effekte. In Österreich kommt dazu der Anspruch vieler Organisationen, DSGVO-konform und möglichst datensparsam zu arbeiten.
Praktisch bewährt sind Alternativen wie Honeypots (unsichtbare Felder, die Bots ausfüllen), zeitbasierte Checks oder serverseitige Rate Limits. Diese Methoden sind für echte Nutzer:innen meist unsichtbar und verursachen keine zusätzlichen Hürden. Wenn ein klassisches Captcha unvermeidbar ist, sollte zumindest eine barriereärmere Variante angeboten werden, und die Einbindung muss sauber kommuniziert werden.
Auch beim Formular selbst gilt: Fragt nur ab, was ihr wirklich braucht. Jedes zusätzliche Feld erhöht Abbruchquote und Barrieren. Das ist nicht nur UX, sondern auch Datensparsamkeit.
Testing, das den Namen verdient Automatisierte Tools finden viele Probleme, aber nicht die entscheidenden. Ein Lighthouse-Score ist kein WCAG-Nachweis, und ein grünes Tool-Ergebnis heißt nicht, dass das Formular nutzbar ist.
Ein sinnvoller, realistischer Test umfasst mindestens: Tastatur-only (Tab, Shift-Tab, Enter, Space, Pfeiltasten bei Radios), Screenreader-Sanity-Check (zum Beispiel mit VoiceOver oder NVDA), Zoom auf 200 Prozent und mobile Nutzung. Dazu kommen Kontrastprüfungen für Fokus- und Fehlerzustände.
Und dann der Teil, der in Projekten gern vergessen wird: Regression. Formulare werden laufend erweitert, Felder werden umbenannt, Plugins werden upgedatet. Accessibility muss in die laufende Qualitätssicherung, sonst ist sie nach drei Releases wieder weg.
Wenn ihr WordPress nutzt , lohnt sich ein kritischer Blick auf Form-Plugins und deren Output. Viele können barrierefrei sein, aber nur, wenn Markup, Fehlermeldungen und Styles korrekt konfiguriert sind. „Plugin installiert“ ist kein Qualitätskriterium.
Was sich geschäftlich sofort auszahlt Barrierefreie Formulare sind nicht nur „Compliance“. Sie reduzieren Abbrüche, erhöhen Conversion und senken die Zahl der „Das Formular geht nicht“-Anrufe. Gleichzeitig sind sie wartbarer, weil weniger Sonderlogik und weniger „Workarounds“ im Code stecken.
Für Organisationen, die Sichtbarkeit ernst nehmen, kommt noch ein Punkt dazu: Qualitätssignale. Eine technisch saubere Website mit klarer Struktur, nachvollziehbaren Interaktionen und stabiler Performance zahlt auf Vertrauen ein – bei Nutzer:innen genauso wie in Such- und KI-Systemen, die Konsistenz und Klarheit bevorzugen. Barrierefreiheit ist damit kein Extra, sondern Teil einer zukunftssicheren Web-Basis.
Wer das in einem Relaunch oder einer Optimierung richtig aufsetzt, spart später Geld. Wir sehen in der Praxis oft, dass „schön gelöste“ Formulare am Ende teuer werden, weil sie nachträglich WCAG-tauglich gemacht werden müssen. Besser ist, die Anforderungen von Beginn an in Design, Komponenten und Testing zu verankern. Wenn ihr dafür einen technischen Partner sucht, der Barrierefreiheit, Performance und saubere Umsetzung zusammendenkt, ist XOXO Websolutions in Wien genau auf diese Art Arbeit spezialisiert: bauen, betreiben, messbar optimieren.
Ein hilfreicher Gedanke zum Schluss: Ein Formular ist erst dann „fertig“, wenn es auch unter Stress funktioniert – mit Tastatur, mit Screenreader, mit Fehlermeldung, am Handy bei Sonne, und ohne dass jemand raten muss, was als Nächstes passiert.
