So machen Sie Ihre Formulare barrierefrei: Beschriftungen, Fehler und Validierung

Laut WebAIM haben 48.6% der Website-Startseiten fehlende Formular-Eingabebeschriftungen — was unbeschriftete Eingabefelder zu einem der häufigsten Barrierefreiheitsfehler im gesamten Web macht. Überlege, was das in der Praxis bedeutet: Eine Screenreader-Nutzerin oder ein Screenreader-Nutzer landet auf deinem Kontaktformular, drückt Tab, um durch die Felder zu springen, und hört immer wieder nur „edit text“. Screenreader geben Formularfeld-Beschriftungen aus — ohne sie hören Nutzerinnen und Nutzer „edit text“ ohne Kontext und wissen nicht, welche Informationen sie eingeben sollen. Formulare sind oft der geschäftskritischste Teil einer Website — Checkout-Flows, Anmeldebildschirme, Kontaktseiten, Supportanfragen — und dennoch gehören sie zu den am konsequentesten fehlerhaften Erlebnissen für Menschen, die unterstützende Technologien verwenden.

Warum Formular-Barrierefreiheit wichtiger ist, als du denkst

Angesichts der Tatsache, dass 1 von 4 Erwachsenen in den USA mit einer Behinderung lebt, ist barrierefreie Formularvalidierung nicht optional; sie ist essenziell. Zu dieser Gruppe gehören blinde Menschen oder Menschen mit Sehbehinderungen, Menschen mit motorischen Einschränkungen, die auf Tastaturnavigation angewiesen sind, Menschen mit kognitiven Beeinträchtigungen, die klare Anweisungen benötigen, und Menschen, die Sprachsteuerungssoftware verwenden, um Formulare auszufüllen. Jedes unbeschriftete Feld, jede vage Fehlermeldung und jedes Validierungsmuster, das sich ausschließlich auf Farbe stützt, ist eine Tür, die sich leise vor einem erheblichen Teil deines Publikums schließt.

Die meisten Nutzerinnen und Nutzer mit Behinderungen stoßen beim Absenden von Informationen auf Fehler und erhalten keine klaren Anweisungen, wie sie diese beheben können — was ihnen zwei Optionen lässt: den Versuch abbrechen und nach einem barrierefreieren Formular suchen oder die Hilfe einer anderen Person in Anspruch nehmen, was beides keine idealen Erfahrungen sind. Aus geschäftlicher Perspektive verbessern barrierefreie Formulare die User Experience, senken Abbruchraten und erfüllen gesetzliche Anforderungen. Aus Compliance-Perspektive sind WCAG 1.3.1 (Info and Relationships) und 4.1.2 (Name, Role, Value) Level-A-Anforderungen, die seit dem Start von WCAG 2.0 im Jahr 2008 existieren. Das sind keine Randfälle oder fortgeschrittenen Techniken — es sind die grundlegenden Erwartungen des Standards.

Laut dem WebAIM Million Report gehören fehlende Formularbeschriftungen durchgängig zu den häufigsten Barrierefreiheitsfehlern im Web, und Forschung zu Implementierungsfehlern zeigt, warum: Organisationen konzentrieren sich auf komplexe Lösungen und ignorieren grundlegende Muster, die Menschen mit Behinderungen überhaupt erst die Nutzung ihrer Dienste ermöglichen würden. Die gute Nachricht ist, dass die Behebung der meisten dieser Probleme nichts Exotisches erfordert — nur bewusstes, fundiertes HTML.

Die WCAG-Erfolgskriterien, die Formulare regeln

Bevor du in die Implementierung einsteigst, ist es hilfreich zu wissen, welche konkreten WCAG-Erfolgskriterien für Formulare gelten. Die Web Content Accessibility Guidelines (WCAG) definieren vier zentrale Prinzipien — Perceivable (Wahrnehmbar), Operable (Bedienbar), Understandable (Verständlich) und Robust (Robust) (POUR) — die das Rückgrat inklusiver Validierungssysteme bilden. Innerhalb dieses Rahmens beziehen sich mehrere Erfolgskriterien direkt auf die Formulargestaltung.

Zu den relevantesten Kriterien gehören: 1.3.1 Info and Relationships (Level A), das verlangt, dass Informationen, Struktur und Beziehungen, die durch die Präsentation vermittelt werden, programmatisch ermittelbar sind; 2.4.6 Headings and Labels (Level AA), das festlegt, dass Überschriften und Beschriftungen Thema oder Zweck beschreiben; 3.3.2 Labels or Instructions (Level A), das verlangt, dass Beschriftungen oder Anweisungen bereitgestellt werden, wenn Inhalte eine Eingabe durch Nutzerinnen und Nutzer erfordern; und 4.1.2 Name, Role, Value (Level A), das verlangt, dass für alle Benutzeroberflächenkomponenten Name und Rolle programmatisch ermittelbar sind.

Indem du die WCAG-Richtlinien 3.3.1 bis 3.3.4 einhältst, die Fehleridentifikation, Anweisungen, Vorschläge und Fehlervermeidung abdecken, erstellst du Formulare, die für alle Nutzerinnen und Nutzer einfacher und intuitiver sind. Das sind keine willkürlichen Hürden — jedes Kriterium spiegelt ein reales Nutzerbedürfnis wider. Wenn du das „Warum“ hinter jeder Regel verstehst, wird die korrekte Implementierung deutlich einfacher, ebenso wie fundierte Entscheidungen in Randfällen.

Beschriftungen richtig setzen: Das Fundament barrierefreier Formulare

Eine Beschriftung ist nicht nur ein visueller Hinweis. Sie ist die programmatische Verbindung zwischen einer textlichen Beschreibung und einem Formularelement und der primäre Mechanismus, mit dem unterstützende Technologien erkennen, wofür ein Feld gedacht ist. Die robusteste Art, diese Verbindung herzustellen, ist das HTML-Element <label> und sein for-Attribut, das auf die id des entsprechenden Eingabefelds zeigt.

<!-- Falsch: Nur ein Placeholder ist keine barrierefreie Beschriftung -->
<input type='email' placeholder='Email address'>

<!-- Richtig: Explizite Beschriftung über for/id verknüpft -->
<label for='email'>Email address</label>
<input type='email' id='email' name='email'>

Beschriftungen sollten immer sichtbar sein — nicht nur Placeholder. Placeholder verschwinden, sobald Nutzerinnen und Nutzer tippen, und lassen keinen Kontext zurück. Das ist ein entscheidender Unterschied. Placeholder-Text war nie dafür gedacht, als Beschriftung zu dienen; er verschwindet in dem Moment, in dem eine Person zu tippen beginnt, er weist oft unzureichenden Farbkontrast auf, und viele Screenreader geben ihn nicht zuverlässig als zugänglichen Namen des Feldes aus. Sich ausschließlich auf Placeholder zu verlassen, schadet allen Nutzerinnen und Nutzern — nicht nur denen, die unterstützende Technologien verwenden.

Wenn du Gruppen verwandter Felder hast — etwa eine Gruppe von Radiobuttons oder einen Block von Checkboxen — ist das richtige Muster <fieldset> und <legend>. Gruppiere verwandte Optionen wie Checkboxen und Radiobuttons mit Fieldsets und Legends, um komplexe Formulare leichter verständlich zu machen.

<fieldset>
  <legend>Preferred contact method</legend>

  <input type='radio' id='contact-email' name='contact' value='email'>
  <label for='contact-email'>Email</label>

  <input type='radio' id='contact-phone' name='contact' value='phone'>
  <label for='contact-phone'>Phone</label>
</fieldset>

In Situationen, in denen eine sichtbare Beschriftung visuell redundant wäre — zum Beispiel ein einzelnes Suchfeld neben einem klar beschrifteten Search-Button — kannst du aria-label oder aria-labelledby verwenden, um einen zugänglichen Namen bereitzustellen, ohne sichtbaren Text anzuzeigen. Verwende dies jedoch sparsam. Menschen, die Screenreader verwenden, können Formularelemente leichter erkennen und verstehen, weil sie mit Beschriftungen, Fieldsets und anderen Strukturelementen verknüpft sind — und sichtbare Beschriftungen kommen allen zugute, einschließlich sehender Nutzerinnen und Nutzer mit kognitiven Beeinträchtigungen, Personen, die auf 400% heranzoomen, und allen, die in einem langen Formular kurz den Überblick verloren haben.

Außerdem müssen Pflichtfelder visuell und programmatisch gekennzeichnet werden, indem das Attribut required oder aria-required verwendet wird. Ein rotes Sternchen allein reicht nicht aus — füge oben im Formular einen kurzen Hinweis wie „Mit * markierte Felder sind Pflichtfelder“ ein und stelle sicher, dass das Attribut required im Markup vorhanden ist, damit unterstützende Technologien das Feld als Pflichtfeld ankündigen können, wenn eine Person den Fokus darauf setzt.

Fehlermeldungen schreiben, die wirklich helfen

Fehlermeldungen sind der Bereich, in dem die meisten Formulare Nutzerinnen und Nutzern auf eine zweite, verstärkende Weise schaden. Nachdem eine Person ein Formular abgeschickt hat, das Validierungsfehler auslöst, muss sie drei Dinge wissen: dass ein Fehler aufgetreten ist, welches Feld ihn verursacht hat und was sie tun muss, um ihn zu beheben. Die meisten Formularfehler beantworten nur die erste dieser Fragen — und selbst das schlecht.

Vage Fehlermeldungen wie „Ungültige Eingabe“ oder „Fehler“ sagen Nutzerinnen und Nutzern nicht, was schiefgelaufen ist oder wie sie es korrigieren können. Jede Fehlermeldung sollte das konkrete Problem benennen und eine konkrete Lösung vorschlagen.

Um die Kompatibilität mit Screenreadern sicherzustellen, sollten Fehlermeldungen mithilfe von ARIA-Attributen wie aria-invalid="true" und aria-describedby in den DOM integriert werden, die Fehlermeldungen direkt mit ihren entsprechenden Formularfeldern verknüpfen. So sieht ein korrekt ausgezeichnetes Fehlerzustand-Beispiel aus:

<label for='email'>Email address</label>
<input
  type='email'
  id='email'
  name='email'
  aria-invalid='true'
  aria-describedby='email-error'
>
<span id='email-error' role='alert'>
  Please enter a valid email address, for example: [email protected]
</span>

Das Attribut aria-invalid="true" teilt einem Screenreader mit, dass das Feld derzeit einen ungültigen Wert enthält. Das Attribut aria-describedby verweist auf das Element, das die Fehlermeldung enthält, die der Screenreader vorliest, wenn die Person den Fokus auf dieses Eingabefeld setzt. Die Angabe role="alert" am Fehler-Span sorgt dafür, dass die Meldung sofort angekündigt wird, wenn sie in den DOM eingefügt wird, ohne dass die Person zu ihr navigieren muss.

In einem minimalistischen Design ist es verlockend, nur eine rote Farbe zu verwenden, um auszudrücken, dass ein Feld ungültig ist — aber allein Farbe zu verwenden reicht nicht aus, wie WCAG 1.4.1 Use of Color festhält, weil Menschen Farbe auf unterschiedliche Weise wahrnehmen und diese rote Farbe nicht von allen bemerkt wird. Die Lösung besteht darin, den farbigen Fehlerzustand durch ein zusätzliches visuelles Element zu ergänzen — das kann ein Icon sein, aber selbst das reicht möglicherweise nicht aus, um zu verstehen, warum das Feld ungültig ist, daher ist die inklusivste Lösung, explizit eine Textmeldung anzuzeigen.

Konkrete Fehlermeldungen sind besonders hilfreich für Menschen mit kognitiven Herausforderungen, reduzierter Aufmerksamkeit oder für diejenigen, die Screenreader verwenden — denn schlecht formuliertes Feedback kann zu Frustration führen und sogar dazu, dass Nutzerinnen und Nutzer das Formular ganz aufgeben. Schreibe Fehlermeldungen aus der Perspektive der Person: Was hätte sie eingeben müssen und wie kann sie es jetzt sofort korrigieren?

Validierungszeitpunkt und Fokusmanagement

Wann du validierst, ist genauso wichtig wie die Art der Validierung. Löst du Fehler zu früh aus — etwa während die Person noch tippt —, riskierst du, ihren Flow mit verfrühten Beschwerden zu unterbrechen. Löst du Fehler nur beim Absenden aus, lässt du die Person möglicherweise durch ein langes Formular scrollen, um herauszufinden, welche Felder Aufmerksamkeit benötigen. Die richtige Antwort ist ein gestuftes Vorgehen.

Kombiniere Echtzeit-Feedback für kritische Felder, On-Blur-Prüfungen für formatierte Eingaben und On-Submit-Validierung für umfassende Fehlerüberprüfungen. In der Praxis bedeutet das: Validiere komplexe Formate wie Passwörter oder E-Mail-Adressen, wenn die Person das Feld verlässt (on blur); vermeide unterbrechende Inline-Validierung, die bei jedem Tastendruck ausgelöst wird; und führe beim Absenden des Formulars einen vollständigen Durchlauf durch und kommuniziere alle Fehler klar auf einmal.

Leite nach dem Absenden den Fokus automatisch auf den ersten Fehler, um Nutzerinnen und Nutzer effizient zu führen. Wenn es mehrere Fehler gibt, ist das barriereärmste Muster, den Fokus auf eine Zusammenfassung am oberen Rand des Formulars zu verschieben, die alle Fehler als Links auflistet, die zu den entsprechenden Feldern springen. So hört die Person die Fehlerzusammenfassung sofort nach dem Absenden, kann den gesamten Umfang der notwendigen Korrekturen verstehen und direkt zu jedem Problem navigieren.

<!-- Fehlerzusammenfassung am oberen Rand des Formulars, programmatisch fokussiert -->
<div id='error-summary' role='alert' tabindex='-1'>
  <h2>2 errors found. Please correct the following:</h2>
  <ul>
    <li><a href='#email'>Email address: Please enter a valid email</a></li>
    <li><a href='#phone'>Phone number: Please use the format (555) 555-5555</a></li>
  </ul>
</div>

Stelle sicher, dass Nutzerinnen und Nutzer Formulare ohne Maus mit logischer Tab-Reihenfolge und sichtbaren Fokusindikatoren bedienen können. Der standardmäßige Fokusrahmen des Browsers ist eine rechtliche und funktionale Basis — aber viele Designteams unterdrücken ihn mit outline: none in ihrem CSS, ohne einen Ersatz bereitzustellen. Dadurch wird das Formular für reine Tastaturnutzerinnen und -nutzer faktisch unbenutzbar. Ein klarer, kontrastreicher Fokusindikator ist nach WCAG 2.4.7 (Level AA) und dem strengeren 2.4.11 in WCAG 2.2 erforderlich. Wenn deine Brand-Guidelines mit dem Standard-Fokusrahmen kollidieren, ersetze ihn — entferne ihn nicht.

Anweisungen und Hinweise geben, bevor Fehler auftreten

Der beste Formularfehler ist der, der nie erscheinen muss. Gut platzierte Anweisungen und Hinweise verhindern Fehler von vornherein, was für alle Nutzerinnen und Nutzer besser ist. Pflichtfelder oder Felder, die ein bestimmtes Format, einen bestimmten Wert oder eine bestimmte Länge erfordern, sollten diese Informationen innerhalb der Beschriftung des Elements oder in seinen programmatisch verknüpften Anweisungen bereitstellen.

Die Feldbeschriftung ist die erste visuelle Anweisung dazu, was auszufüllen ist, gefolgt von einer Beschreibung, wenn nötig. So wie sehende Nutzerinnen und Nutzer eine Beschreibung sehen können, müssen Screenreader-Nutzerinnen und -Nutzer ebenfalls darüber informiert werden — und du kannst die Beschreibung mit dem Eingabefeld verbinden, indem du das Attribut aria-describedby verwendest, das eine ID akzeptiert, die auf das Beschreibungselement zeigt, sodass der Screenreader die Beschreibung automatisch vorliest, wenn die Person den Fokus auf das Feld setzt.

<label for='phone'>Phone number</label>
<input
  type='tel'
  id='phone'
  name='phone'
  aria-describedby='phone-hint'
>
<span id='phone-hint'>Format: (555) 555-5555</span>

Gib nach Möglichkeit Beispiele an, um Erwartungen zu verdeutlichen — wenn ein Datumsfeld beispielsweise das Format MM/DD/YYYY erfordert, füge ein Beispiel wie „Enter date as 12/25/2024.“ hinzu. Für Passwortfelder solltest du die Anforderungen im Voraus nennen, statt sie nacheinander offenzulegen, wenn die Person jeweils gegen eine Regel verstößt. Wenn möglich, sollten Formulare nicht zeitlich begrenzt sein, damit Nutzerinnen und Nutzer das Formular in ihrem eigenen Tempo ausfüllen können — und wenn eine Zeitbegrenzung notwendig ist, sollte die Person die Möglichkeit haben, sie zu deaktivieren oder zu verlängern.

Das Attribut autocomplete ist ein weiteres häufig übersehenes Barrierefreiheits-Feature. Das Setzen von Werten wie autocomplete="email", autocomplete="given-name" oder autocomplete="street-address" ermöglicht es Browsern und Passwortmanagern, Felder korrekt automatisch auszufüllen, was die Belastung für Menschen mit motorischen Einschränkungen, kognitiven Beeinträchtigungen oder alle, die wiederholtes Tippen als schwierig empfinden, drastisch reduziert. WCAG 1.3.5 (Identify Input Purpose, Level AA) verlangt dies für Felder, die personenbezogene Daten erfassen.

Deine Formulare auf Barrierefreiheit testen

Die Regeln zu kennen ist das eine; zu wissen, ob deine Formulare ihnen tatsächlich folgen, ist etwas anderes. Eine kombinierte Teststrategie ist der zuverlässigste Ansatz. Während Tools wie Lighthouse und WAVE helfen können, Probleme automatisch zu erkennen, ist manuelles Testen mit reiner Tastaturnavigation und Screenreadern unerlässlich, um reale Usability-Probleme zu erkennen.

Für Tastaturtests ziehst du einfach deine Maus ab und versuchst, das Formular auszufüllen. Du solltest jedes Feld erreichen, jeden Button aktivieren und jede Fehlermeldung erhalten können — nur mit Tab, Shift+Tab, Pfeiltasten und Enter/Leertaste. Wenn du steckenbleibst, ist das ein Fehler. Für Screenreader-Tests verwende NVDA mit Firefox unter Windows oder VoiceOver mit Safari unter macOS. Screenreader verhalten sich leicht unterschiedlich — unterschiedliche Shortcuts, unterschiedliche semantische Ausgaben und unterschiedliche Feature-Unterstützung; zum Beispiel funktioniert NVDA besser mit Firefox, während VoiceOver am besten mit Safari funktioniert. Tests mit mindestens zwei Kombinationen decken die größte Bandbreite an Problemen ab.

Tools wie WAVE und Axe eignen sich hervorragend, um Formulare auf fehlende Beschriftungen, falsche ARIA-Attribute und schlechten Farbkontrast zu scannen. Diese automatisierten Tools können direkt in deine CI/CD-Pipeline integriert werden, um Regressionen zu erkennen, bevor sie in die Produktion gelangen. Da Barrierefreiheitsrichtlinien nuanciert sind, können automatisierte Tools jedoch nur etwa 30% der WCAG-Probleme erkennen — weshalb die automatisierte Ebene durch manuelle Überprüfung und idealerweise Tests mit tatsächlichen Nutzerinnen und Nutzern, die auf unterstützende Technologien angewiesen sind, ergänzt werden muss.

Wenn du dein Markup manuell überprüfst, stelle dir für jedes Formularfeld folgende Fragen: Hat es eine sichtbare Beschriftung? Ist diese Beschriftung programmatisch über for/id oder ARIA verknüpft? Ist ein Hinweistext mit aria-describedby verbunden? Setzt jeder Fehlerzustand aria-invalid="true" und verweist über aria-describedby auf die Fehlermeldung? Ist das Attribut required bei Pflichtfeldern vorhanden? Kannst du jedes interaktive Element ausschließlich mit der Tastatur erreichen und bedienen?

Wichtigste Erkenntnisse

• Jede Eingabe braucht eine programmatische Beschriftung. Verwende <label for='...'> für alle Formularfelder — verlasse dich niemals allein auf Placeholder-Text. Jedes Formularfeld braucht eine programmatische Beschriftung, ohne Ausnahme — Placeholder-Text ist keine Beschriftung.
• Fehlermeldungen müssen das Problem benennen und eine Lösung vorschlagen. Fehlermeldungen müssen das Problem identifizieren und vorschlagen, wie es behoben werden kann, und sollten mithilfe von aria-describedby mit ihren Feldern verknüpft werden.
• Verlasse dich niemals allein auf Farbe. Verlasse dich bei keiner Statusanzeige allein auf Farbe — verwende Text, Icons und andere nicht-farbige Indikatoren zusätzlich zu Farbsignalen.
• Fokus nach dem Absenden steuern. Der Fehler sollte klar identifiziert werden, schneller Zugriff auf das problematische Element sollte bereitgestellt werden, und die Nutzerin oder der Nutzer sollte den Fehler leicht beheben und das Formular erneut absenden können. Den Fokus nach einem fehlgeschlagenen Absenden auf eine Fehlerzusammenfassung zu verschieben, ist der Goldstandard.
• Mit echten Tools testen, nicht nur mit Annahmen. Formulare barrierefrei zu halten, ist keine einmalige Aufgabe — es erfordert regelmäßige Tests und Updates, um sicherzustellen, dass sie konform und nutzerfreundlich bleiben. Kombiniere automatisiertes Scannen mit reiner Tastaturnavigation und Screenreader-Tests bei jedem bedeutenden Formular-Update.