Barrierefreie Formulare erstellen: Leitfaden mit Beispielen

Aktualisiert im Oktober 2026: jetzt mit den neuen Regeln aus WCAG 2.2, autocomplete, Fehlerzusammenfassung und einem vollständigen Beispiel-Formular.

Wenn ich ein Produkt auf Barrierefreiheit prüfe, schaue ich mir zuerst die Formulare an: Registrierung, Login, Onboarding. Nirgends zeigt sich schneller, ob ein Team an alle gedacht hat. Ein grauer Platzhalter statt Label. Ein ausgegrauter Button, der nicht verrät, was noch fehlt. Ein Fehler, der nur aus einem roten Rahmen besteht.

Das sind keine Einzelfälle. Auf 51 % der eine Million meistbesuchten Startseiten fehlt mindestens einem Formularfeld das Label, und jedes dritte Eingabefeld dort ist nicht richtig beschriftet (WebAIM Million 2026).

In SaaS-Produkten stecken Formulare überall, bis hin zu Einstellungen und Checkout. Dieser Leitfaden zeigt dir in acht Schritten, wie du barrierefreie Formulare erstellst, jeweils mit dem, was im Design zu klären ist, und dem passenden HTML.

Die Kurzfassung: Ein barrierefreies Formular hat für jedes Feld ein sichtbares Label, das technisch mit dem Feld verknüpft ist. Fehler stehen als verständlicher Text direkt am Feld, und alles lässt sich per Tastatur bedienen. Dazu kommen autocomplete für persönliche Daten und die neuen Regeln aus WCAG 2.2, zum Beispiel ausreichend große Klickflächen und ein Login ohne Gedächtnistest.

HTML oder PDF: Welches Formular solltest du erstellen?

Barrierefreie Formulare erstellst du am besten als HTML-Formular, direkt auf der Website oder in der App. HTML bringt Labels, Tastaturbedienung und Fehlermeldungen von Haus aus mit, und Screenreader kommen damit gut zurecht. Barrierefreie PDF-Formulare sind deutlich aufwendiger, weil jedes Feld nachträglich beschriftet und getaggt werden muss. Üblich sind sie vor allem dort, wo ein Dokument gedruckt oder abgelegt wird, etwa bei Behörden. Eine Gegenüberstellung beider Varianten findest du im Leitfaden „Barrierefreie Formulare“ des Bundes.

In einem SaaS-Produkt stellt sich die Frage selten: Dein Produkt ist HTML. Um HTML-Formulare geht es deshalb im Rest dieses Leitfadens.

Warum Formulare die kritischste Stelle in deinem Produkt sind

Ein Formular ist der Moment, in dem jemand etwas von dir will: ein Konto, einen Termin, ein Abo. Scheitert es, verlierst du nicht irgendeine Nutzerin, sondern genau die, die schon fast Kundin war.

Und es trifft nicht nur Menschen mit Behinderungen. Wer nach einem langen Arbeitstag an einem Formular hängen bleibt, gibt genauso auf. Wie du solche Abbrüche sichtbar machst, zeigt der Artikel UX-Erfolg messen. Warum Barrierefreiheit insgesamt eine Business-Chance ist, steht in Inklusive UX & Barrierefreiheit in SaaS.

Gilt das BFSG für dein Formular?

Das hängt nicht am Formular, sondern an deinem Angebot. Das Barrierefreiheitsstärkungsgesetz (BFSG) gilt für Produkte und Dienstleistungen für Verbraucher:innen. Websites und Apps fallen darunter, wenn über sie solche Dienstleistungen angeboten werden, zum Beispiel ein Online-Shop, Online-Banking oder eine Online-Terminbuchung (Bundesfachstelle Barrierefreiheit, FAQ Fragen 14 und 19).

• Dein Produkt richtet sich an Verbraucher:innen und man kann darüber etwas abschließen? Dann gilt das BFSG, auch für Registrierung, Login und Checkout.

• Reine Präsentationswebsite mit Kontaktformular? Laut Bundesfachstelle eher nicht betroffen.

• Reines B2B? Nicht betroffen.

• Kleinstunternehmen mit weniger als zehn Beschäftigten und höchstens 2 Millionen Euro Jahresumsatz sind bei Dienstleistungen ausgenommen.

Technisch verweist das Gesetz auf die Norm EN 301 549 und damit auf WCAG 2.1 AA. Die neue Fassung der Norm stellt auf WCAG 2.2 um. Wer jetzt Formulare baut, plant deshalb direkt mit 2.2. Die Details stehen in der WCAG-Checkliste. Das ist keine Rechtsberatung: Im Zweifel klärst du das mit einer Anwältin oder einem Anwalt.

Die 6 Grundregeln barrierefreier Formulare

Diese sechs Regeln gelten für jedes Formular, egal ob Newsletter-Anmeldung oder zehnstufiges Onboarding.

1. Logische Reihenfolge und Navigation

Wie im echten Leben gehst du im Formular von einfach zu komplex. Erst die Basics (Name, E-Mail), dann die Details. Verwende ein einspaltiges Layout, außer bei Feldern, die inhaltlich zusammengehören, wie Postleitzahl und Ort.

Gruppiere Abschnitte mit fieldset und legend. Das ist wie die Beschilderung in einem Gebäude:

• „Erdgeschoss: Persönliche Daten“

• „Erster Stock: Zahlungsinformationen“

2. Vollständige Tastaturbedienung

Dein Formular muss komplett ohne Maus funktionieren:

• Tab und Shift + Tab springen von Feld zu Feld

• Enter schickt das Formular aus einem Textfeld heraus ab

• Leertaste setzt Checkboxen und löst Buttons aus

• Pfeiltasten wechseln innerhalb einer Gruppe von Radio-Buttons

• Escape schließt Dialoge und aufgeklappte Auswahllisten

Das fokussierte Element muss jederzeit deutlich sichtbar sein. Bewährt hat sich ein Rahmen von mindestens 2 px mit 3:1 Kontrast zur Umgebung, wie ihn WCAG 2.2 in der strengsten Stufe AAA beschreibt.

3. Screenreader-Kompatibilität

Screenreader sind Programme, die Inhalte vorlesen und bedienbar machen. Damit sie dein Formular verstehen, brauchst du die richtigen HTML-Bausteine:

• Native Elemente zuerst: <label>, <input>, <select>, <textarea>, <fieldset>, <legend>, <button>. Echte Buttons statt div-Elementen mit Klick-Event.

• ARIA nur als Ergänzung: ARIA-Attribute liefern Zusatzinfos, wo HTML nicht reicht. Sie ersetzen kein natives Element.

• Labels vollständig ausschreiben: „E-Mail-Adresse“ statt „E-Mail“. Wer nur das Label hört, muss es ohne Zusammenhang verstehen. Auch die Lesbarkeit zählt, dazu mehr im Artikel über lesbare, barrierefreie Schriftarten.

4. Klare Hinweise

Sag genau, was du brauchst, bevor jemand einen Fehler macht:

• „TT.MM.JJJJ, zum Beispiel 15.03.1990“ statt „Datum eingeben“

• „Telefonnummer mit Vorwahl“ statt nur „Telefon“

• Formatregeln für Passwörter sichtbar unter dem Feld, nicht erst in der Fehlermeldung

5. Ausreichende Kontraste und Größen

• Text: Labels, Hinweise und Fehlermeldungen brauchen einen Kontrast von mindestens 4,5:1.

• Feldrahmen und Icons: mindestens 3:1 zum Hintergrund. Ein hellgrauer Rahmen auf Weiß ist oft unsichtbar.

• Klickflächen: WCAG 2.2 verlangt auf Stufe AA mindestens 24 × 24 CSS-Pixel oder genug Abstand. Für Touch empfehle ich 44 × 44, so wie es auch Apple vorgibt. Gerade Checkboxen und Radio-Buttons sind oft zu klein: Mach das Label klickbar, dann wächst die Fläche mit.

• Nie nur Farbe: Ein Fehler braucht Farbe, Icon und Text.

Mehr dazu in den Guides zu Farben und Farbkontrasten und zu motorischer Barrierefreiheit.

6. Alternativen anbieten

Du musst nicht alles für jeden perfekt machen. Aber jeder sollte einen Weg durch dein Formular finden:

• Keine harten Zeitlimits: Wenn es eins geben muss, warne vorher und biete eine Verlängerung an (WCAG 2.2.1: mindestens 20 Sekunden).

• Ein zweiter Weg: Bei komplizierten Anträgen hilft schon eine Telefonnummer als Alternative.

• Solide Grundversion: Das Formular bleibt absendbar, auch wenn ein Zusatz-Skript hakt.

Barrierefreie Formulare erstellen in 8 Schritten

Schritt 1: Labels sichtbar setzen und verknüpfen

Jedes Feld braucht ein sichtbares Label, das über for und id mit dem Feld verknüpft ist. Dann liest der Screenreader beim Fokus den Namen vor, und ein Klick aufs Label setzt den Cursor ins Feld.

<input type="email" placeholder="E-Mail eingeben">

<label for="email">E-Mail-Adresse</label>
<input type="email" id="email" name="email" autocomplete="email">

<input type="email" placeholder="E-Mail eingeben">

<label for="email">E-Mail-Adresse</label>
<input type="email" id="email" name="email" autocomplete="email">

<input type="email" placeholder="E-Mail eingeben">

<label for="email">E-Mail-Adresse</label>
<input type="email" id="email" name="email" autocomplete="email">

Warum Platzhalter als Label nicht reichen: Sie verschwinden beim Tippen, haben meist zu wenig Kontrast, und nicht jeder Screenreader liest sie zuverlässig vor. Ein Platzhalter darf ein Beispiel zeigen, aber nie das Label ersetzen.

Schritt 2: Persönliche Daten mit autocomplete auszeichnen

Mit autocomplete sagst du dem Browser, welche Information ein Feld erwartet. Dann füllt er Name, E-Mail oder Adresse auf Wunsch selbst aus. Das hilft allen, besonders aber Menschen mit motorischen oder kognitiven Einschränkungen, die sonst jede Angabe neu tippen müssten. WCAG verlangt das auf Stufe AA für alle Felder, die Daten über die Person selbst abfragen (WCAG 1.3.5).

<label for="vorname">Vorname</label>
<input type="text" id="vorname" name="vorname" autocomplete="given-name">

<label for="nachname">Nachname</label>
<input type="text" id="nachname" name="nachname" autocomplete="family-name">

<label for="telefon">Telefonnummer (optional)</label>
<input type="tel" id="telefon" name="telefon" autocomplete="tel">

<label for="vorname">Vorname</label>
<input type="text" id="vorname" name="vorname" autocomplete="given-name">

<label for="nachname">Nachname</label>
<input type="text" id="nachname" name="nachname" autocomplete="family-name">

<label for="telefon">Telefonnummer (optional)</label>
<input type="tel" id="telefon" name="telefon" autocomplete="tel">

<label for="vorname">Vorname</label>
<input type="text" id="vorname" name="vorname" autocomplete="given-name">

<label for="nachname">Nachname</label>
<input type="text" id="nachname" name="nachname" autocomplete="family-name">

<label for="telefon">Telefonnummer (optional)</label>
<input type="tel" id="telefon" name="telefon" autocomplete="tel">

Die wichtigsten Werte für SaaS: email, given-name, family-name, organization, tel, street-address, postal-code, current-password (Login), new-password (Registrierung) und one-time-code (Bestätigungscodes).

Schritt 3: Pflichtfelder kennzeichnen

Ein Sternchen allein versteht nicht jeder. Es gibt zwei saubere Wege:

• Die meisten Felder sind Pflicht: Schreib über das Formular „Alle Felder sind Pflicht, außer sie sind als ‚optional‘ markiert.“ und markiere nur die optionalen Felder.

• Die meisten Felder sind optional: Markiere die Pflichtfelder mit „(Pflichtfeld)“ im Label. Wenn du ein Sternchen nutzt, erkläre es über dem Formular.

Im Code bekommt jedes Pflichtfeld zusätzlich required. Dann sagt der Screenreader „erforderlich“ an.

<p>Alle Felder sind Pflicht, außer sie sind als „optional“ markiert.</p>

<label for="email">E-Mail-Adresse</label>
<input type="email" id="email" name="email" autocomplete="email" required>

<label for="firma">Firma (optional)</label>
<input type="text" id="firma" name="firma" autocomplete="organization">

<p>Alle Felder sind Pflicht, außer sie sind als „optional“ markiert.</p>

<label for="email">E-Mail-Adresse</label>
<input type="email" id="email" name="email" autocomplete="email" required>

<label for="firma">Firma (optional)</label>
<input type="text" id="firma" name="firma" autocomplete="organization">

<p>Alle Felder sind Pflicht, außer sie sind als „optional“ markiert.</p>

<label for="email">E-Mail-Adresse</label>
<input type="email" id="email" name="email" autocomplete="email" required>

<label for="firma">Firma (optional)</label>
<input type="text" id="firma" name="firma" autocomplete="organization">

Nutzt du eigene Fehlermeldungen, setz novalidate an das <form>-Element. Dann funken die Fehlerblasen des Browsers nicht dazwischen, und required wird trotzdem vorgelesen.

Schritt 4: Zusammengehöriges gruppieren

Radio-Buttons, Checkbox-Gruppen und Adressblöcke gehören in ein fieldset mit legend. Die Legende ist die Frage, die Optionen sind die Antworten. Der Screenreader liest beim ersten Feld die Frage mit vor.

<fieldset>
  <legend>Wie sollen wir dich erreichen?</legend>
  <input type="radio" id="kontakt-mail" name="kontaktweg" value="mail">
  <label for="kontakt-mail">Per E-Mail</label>
  <input type="radio" id="kontakt-telefon" name="kontaktweg" value="telefon">
  <label for="kontakt-telefon">Per Telefon</label>
</fieldset>

<fieldset>
  <legend>Wie sollen wir dich erreichen?</legend>
  <input type="radio" id="kontakt-mail" name="kontaktweg" value="mail">
  <label for="kontakt-mail">Per E-Mail</label>
  <input type="radio" id="kontakt-telefon" name="kontaktweg" value="telefon">
  <label for="kontakt-telefon">Per Telefon</label>
</fieldset>

<fieldset>
  <legend>Wie sollen wir dich erreichen?</legend>
  <input type="radio" id="kontakt-mail" name="kontaktweg" value="mail">
  <label for="kontakt-mail">Per E-Mail</label>
  <input type="radio" id="kontakt-telefon" name="kontaktweg" value="telefon">
  <label for="kontakt-telefon">Per Telefon</label>
</fieldset>

Schritt 5: Fehlermeldungen barrierefrei gestalten

Drei Fragen musst du klären: wann, was und wo.

Wann du Fehler anzeigst

• Beim Verlassen des Feldes: der Standard. Sobald jemand weiterspringt, prüfst du den Inhalt. Nicht aufdringlich, aber rechtzeitig.

• Während des Tippens: nur bei klaren Regeln wie Passwortstärke, und erst, wenn jemand fertig getippt hat.

• Beim Absenden: immer, als Sicherheitsnetz für alles, was übrig ist.

Was in der Fehlermeldung steht

Eine gute Fehlermeldung sagt, wie es richtig geht:

Wo die Fehlermeldung hingehört

Direkt am Feld, zwischen Label und Eingabefeld. Dort sieht man sie auch dann, wenn die Bildschirmtastatur auf dem Smartphone den unteren Teil verdeckt. Und nie nur als roter Rahmen: Icon, Text und Farbe gehören zusammen.

Im Code verknüpfst du die Meldung über aria-describedby mit dem Feld und markierst das Feld mit aria-invalid="true". Das unsichtbare Wort „Fehler:“ sorgt dafür, dass der Screenreader die Meldung eindeutig ansagt:

<label for="email">E-Mail-Adresse</label>
<p id="email-fehler" class="fehler">
  <span class="visually-hidden">Fehler:</span>
  Die E-Mail-Adresse braucht ein @-Zeichen, zum Beispiel name@firma.de
</p>
<input type="email" id="email" name="email" autocomplete="email"
       aria-invalid="true" aria-describedby="email-fehler">

<label for="email">E-Mail-Adresse</label>
<p id="email-fehler" class="fehler">
  <span class="visually-hidden">Fehler:</span>
  Die E-Mail-Adresse braucht ein @-Zeichen, zum Beispiel name@firma.de
</p>
<input type="email" id="email" name="email" autocomplete="email"
       aria-invalid="true" aria-describedby="email-fehler">

<label for="email">E-Mail-Adresse</label>
<p id="email-fehler" class="fehler">
  <span class="visually-hidden">Fehler:</span>
  Die E-Mail-Adresse braucht ein @-Zeichen, zum Beispiel name@firma.de
</p>
<input type="email" id="email" name="email" autocomplete="email"
       aria-invalid="true" aria-describedby="email-fehler">

Die Fehlerzusammenfassung beim Absenden

Wer auf „Absenden“ klickt und Fehler hat, bekommt ganz oben eine Liste aller Fehler. Jeder Eintrag ist ein Link, der direkt zum Feld springt. Der Fokus springt nach dem Absenden auf diese Box, damit der Screenreader sie sofort vorliest. So macht es zum Beispiel das Design-System der britischen Regierung (GOV.UK):

<div class="fehler-zusammenfassung" id="fehler" tabindex="-1">
  <h2>Bitte korrigiere 2 Angaben</h2>
  <ul>
    <li><a href="#email">Die E-Mail-Adresse braucht ein @-Zeichen, zum Beispiel name@firma.de</a></li>
    <li><a href="#nachricht">Bitte schreib eine Nachricht</a></li>
  </ul>
</div>

<div class="fehler-zusammenfassung" id="fehler" tabindex="-1">
  <h2>Bitte korrigiere 2 Angaben</h2>
  <ul>
    <li><a href="#email">Die E-Mail-Adresse braucht ein @-Zeichen, zum Beispiel name@firma.de</a></li>
    <li><a href="#nachricht">Bitte schreib eine Nachricht</a></li>
  </ul>
</div>

<div class="fehler-zusammenfassung" id="fehler" tabindex="-1">
  <h2>Bitte korrigiere 2 Angaben</h2>
  <ul>
    <li><a href="#email">Die E-Mail-Adresse braucht ein @-Zeichen, zum Beispiel name@firma.de</a></li>
    <li><a href="#nachricht">Bitte schreib eine Nachricht</a></li>
  </ul>
</div>

Nach dem Absenden setzt ein Skript den Fokus mit document.getElementById('fehler').focus() auf die Box. Zusätzlich setzt du „Fehler:“ vor den Seitentitel. Dann hört man das Problem schon beim Laden der Seite.

Schritt 6: Buttons verständlich und immer aktiv

Lass den Absende-Button aktiv. Ein ausgegrauter Button sagt nicht, was fehlt. Wer nur die Tastatur nutzt, erreicht ihn per Tab gar nicht, und viele übersehen ihn ganz. Besser: Button aktiv lassen und beim Klick die Fehlerzusammenfassung zeigen.

<button type="submit" disabled>Weiter</button>

<button type="submit">Weiter</button>

<button type="submit" disabled>Weiter</button>

<button type="submit">Weiter</button>

<button type="submit" disabled>Weiter</button>

<button type="submit">Weiter</button>

Beschrifte, was passiert. „Weiter“, „OK“ und „Absenden“ sind unspezifisch. Besser: „Konto erstellen“, „Bestellung abschließen“ oder „Nachricht senden“.

Schritt 7: Wichtige Hinweise sichtbar machen, nicht verstecken

Vorsicht bei allem, was ein- und ausblendet. Tooltips verschwinden beim Zoomen oft aus dem sichtbaren Bereich, und auf dem Smartphone gibt es kein Hover. Toast-Meldungen sind schnell wieder weg, weit vom eigentlichen Feld entfernt, und Screenreader bekommen sie oft nicht mit.

Die Regel: Was man zum Ausfüllen braucht, steht dauerhaft sichtbar am Feld. Tooltips nur für Zusatzinfos, ohne die man auch zurechtkommt.

Schritt 8: Den Erfolg bestätigen

Nach dem Absenden muss klar sein, dass es geklappt hat. Zeig eine Bestätigung als Text auf der Seite, zum Beispiel mit einer Überschrift „Danke, deine Nachricht ist angekommen“ und dem, was als Nächstes passiert. Setz den Fokus auf diese Überschrift, damit auch Screenreader-Nutzer:innen die Bestätigung sofort hören. Ein Toast, der nach drei Sekunden verschwindet, reicht nicht.

Alles zusammen: ein Formularfeld im Überblick

Nach den acht Schritten kommt jetzt das Ergebnis. An einem einzelnen Feld kommen fünf Dinge zusammen:

1. ein sichtbares Label über dem Feld, das technisch mit dem Eingabefeld verknüpft ist (Schritt 1)

2. ein Hinweis, der schon vor dem Tippen sagt, was erwartet wird (Schritt 7)

3. eine Fehlermeldung aus Text und Icon, die sagt, wie es richtig geht (Schritt 5)

4. ein deutlicher Fokus-Rahmen mit mindestens 3:1 Kontrast (Grundregel 2)

5. „optional“ in Worten statt eines unerklärten Sternchens (Schritt 3)

Die Grafik zeigt diese fünf Teile an einem Beispielfeld für die E-Mail-Adresse.

Was WCAG 2.2 für Formulare ändert

WCAG 2.2 bringt fünf neue Kriterien auf den Stufen A und AA, die Formulare direkt betreffen (W3C: Neu in WCAG 2.2):

Bei 3.3.8 zählen laut W3C ausdrücklich Passwort-Manager und Kopieren und Einfügen als Hilfe. Blockiere das also nie. Alle neuen Kriterien mit Beispielen und Schnelltests findest du in der WCAG-Checkliste.

Beispiel: Ein barrierefreies Kontaktformular in HTML

Hier kommen die Schritte in einem vollständigen Kontaktformular zusammen:

<form action="/kontakt" method="post" novalidate>
  <p>Alle Felder sind Pflicht, außer sie sind als „optional“ markiert.</p>

  <label for="name">Name</label>
  <input type="text" id="name" name="name" autocomplete="name" required>

  <label for="email">E-Mail-Adresse</label>
  <p id="email-hinweis">Hierhin schicken wir die Antwort.</p>
  <input type="email" id="email" name="email" autocomplete="email" required
         aria-describedby="email-hinweis">

  <label for="firma">Firma (optional)</label>
  <input type="text" id="firma" name="firma" autocomplete="organization">

  <fieldset>
    <legend>Worum geht es?</legend>
    <input type="radio" id="thema-audit" name="thema" value="audit" required>
    <label for="thema-audit">UX-Audit</label>
    <input type="radio" id="thema-projekt" name="thema" value="projekt">
    <label for="thema-projekt">Neues Projekt</label>
    <input type="radio" id="thema-sonstiges" name="thema" value="sonstiges">
    <label for="thema-sonstiges">Etwas anderes</label>
  </fieldset>

  <label for="nachricht">Deine Nachricht</label>
  <textarea id="nachricht" name="nachricht" rows="6" required></textarea>

  <input type="checkbox" id="datenschutz" name="datenschutz" required>
  <label for="datenschutz">
    Ich habe die <a href="/legal/datenschutz">Datenschutzerklärung</a> gelesen.
  </label>

  <button type="submit">Nachricht senden</button>
</form>

<form action="/kontakt" method="post" novalidate>
  <p>Alle Felder sind Pflicht, außer sie sind als „optional“ markiert.</p>

  <label for="name">Name</label>
  <input type="text" id="name" name="name" autocomplete="name" required>

  <label for="email">E-Mail-Adresse</label>
  <p id="email-hinweis">Hierhin schicken wir die Antwort.</p>
  <input type="email" id="email" name="email" autocomplete="email" required
         aria-describedby="email-hinweis">

  <label for="firma">Firma (optional)</label>
  <input type="text" id="firma" name="firma" autocomplete="organization">

  <fieldset>
    <legend>Worum geht es?</legend>
    <input type="radio" id="thema-audit" name="thema" value="audit" required>
    <label for="thema-audit">UX-Audit</label>
    <input type="radio" id="thema-projekt" name="thema" value="projekt">
    <label for="thema-projekt">Neues Projekt</label>
    <input type="radio" id="thema-sonstiges" name="thema" value="sonstiges">
    <label for="thema-sonstiges">Etwas anderes</label>
  </fieldset>

  <label for="nachricht">Deine Nachricht</label>
  <textarea id="nachricht" name="nachricht" rows="6" required></textarea>

  <input type="checkbox" id="datenschutz" name="datenschutz" required>
  <label for="datenschutz">
    Ich habe die <a href="/legal/datenschutz">Datenschutzerklärung</a> gelesen.
  </label>

  <button type="submit">Nachricht senden</button>
</form>

<form action="/kontakt" method="post" novalidate>
  <p>Alle Felder sind Pflicht, außer sie sind als „optional“ markiert.</p>

  <label for="name">Name</label>
  <input type="text" id="name" name="name" autocomplete="name" required>

  <label for="email">E-Mail-Adresse</label>
  <p id="email-hinweis">Hierhin schicken wir die Antwort.</p>
  <input type="email" id="email" name="email" autocomplete="email" required
         aria-describedby="email-hinweis">

  <label for="firma">Firma (optional)</label>
  <input type="text" id="firma" name="firma" autocomplete="organization">

  <fieldset>
    <legend>Worum geht es?</legend>
    <input type="radio" id="thema-audit" name="thema" value="audit" required>
    <label for="thema-audit">UX-Audit</label>
    <input type="radio" id="thema-projekt" name="thema" value="projekt">
    <label for="thema-projekt">Neues Projekt</label>
    <input type="radio" id="thema-sonstiges" name="thema" value="sonstiges">
    <label for="thema-sonstiges">Etwas anderes</label>
  </fieldset>

  <label for="nachricht">Deine Nachricht</label>
  <textarea id="nachricht" name="nachricht" rows="6" required></textarea>

  <input type="checkbox" id="datenschutz" name="datenschutz" required>
  <label for="datenschutz">
    Ich habe die <a href="/legal/datenschutz">Datenschutzerklärung</a> gelesen.
  </label>

  <button type="submit">Nachricht senden</button>
</form>

Dazu kommen noch CSS für sichtbaren Fokus und ausreichend große Klickflächen, die Fehlermeldungen aus Schritt 5 und die Erfolgsmeldung aus Schritt 8. Geprüft mit dem Testtool axe-core: Alle Labels, Hinweise und Gruppen werden korrekt erkannt.

Sonderfälle in SaaS: Login, Onboarding, Einstellungen

Login und Registrierung: Erlaube Passwort-Manager (autocomplete="current-password" bzw. "new-password") und Einfügen. Biete einen Button „Passwort anzeigen“ an. Login per E-Mail-Link oder Passkey ist eine gute Alternative zum Passwort. Für Bestätigungscodes hilft autocomplete="one-time-code": Dann schlägt das Smartphone den Code aus der SMS direkt vor.

Spam-Schutz ohne Rätsel: Rätsel-CAPTCHAs sind für viele eine Hürde, und auch eine „einfache“ Rechenaufgabe ist ein kognitiver Test. Besser: ein Honeypot-Feld, das nur Bots ausfüllen, plus eine Prüfung auf dem Server. Bei unsichtbaren Diensten wie reCAPTCHA klärst du zusätzlich den Datenschutz.

Mehrstufige Formulare und Onboarding: Zeig nicht nur „Schritt 2 von 4“, sondern auch, worum es geht: „Schritt 2 von 4: Team einladen“. Prüfe Fehler auf jeder Seite, nicht erst am Ende. Wenn ein neuer Schritt lädt, setz den Fokus auf dessen Überschrift. Und frag nichts doppelt ab, was im ersten Schritt schon da war (WCAG 3.3.7).

<ol aria-label="Fortschritt">
  <li aria-current="step">Schritt 1 von 3: Adresse</li>
  <li>Schritt 2 von 3: Zahlungsart</li>
  <li>Schritt 3 von 3: Prüfen und bestellen</li>
</ol>

<ol aria-label="Fortschritt">
  <li aria-current="step">Schritt 1 von 3: Adresse</li>
  <li>Schritt 2 von 3: Zahlungsart</li>
  <li>Schritt 3 von 3: Prüfen und bestellen</li>
</ol>

<ol aria-label="Fortschritt">
  <li aria-current="step">Schritt 1 von 3: Adresse</li>
  <li>Schritt 2 von 3: Zahlungsart</li>
  <li>Schritt 3 von 3: Prüfen und bestellen</li>
</ol>

Einstellungen mit Schaltern: Ein Toggle ist technisch eine Checkbox. Nimm <input type="checkbox"> mit Label und gestalte sie als Schalter. Dann bekommt der Screenreader Name und Zustand („aktiviert“, „nicht aktiviert“) ohne Zusatzaufwand.

Datumsfelder: Für Daten, die man kennt, etwa das Geburtsdatum, sind drei einzelne Felder für Tag, Monat und Jahr am einfachsten. So empfiehlt es auch das GOV.UK Design System. Für Termine in der Zukunft passt ein Kalender, aber immer mit der Möglichkeit, das Datum auch zu tippen.

Eigene Dropdowns: Das native <select> funktioniert überall. Eine selbst gebaute Auswahlliste mit Suche braucht das Muster aus den ARIA Authoring Practices des W3C und Tests mit Screenreadern. Sonst lieber eine getestete Komponenten-Bibliothek nehmen.

Mobil: Wichtige Buttons gehören in den Daumenbereich. Hinweise und Fehler stehen über dem Feld besser als darunter, weil die Bildschirmtastatur den unteren Teil verdeckt.

So testest du dein Formular in 10 Minuten

Nimm dein wichtigstes Formular, zum Beispiel die Registrierung, und geh diese Liste durch:

Tastatur (3 Minuten)

• Maus weglegen. Kommst du mit Tab durch alle Felder, in einer logischen Reihenfolge?

• Siehst du immer, wo der Fokus gerade ist? Wird er von einem Banner oder einer Leiste verdeckt?

• Lassen sich Checkboxen mit der Leertaste setzen und Radio-Buttons mit den Pfeiltasten wechseln?

• Kannst du absenden und den Fehler danach direkt ansteuern?

Zoom (1 Minute)

• Auf 200 % zoomen. Schneidet etwas ab? Überlappen Labels und Felder?

Screenreader (4 Minuten)

• Werden alle Labels vorgelesen, auch bei Checkboxen und Radio-Buttons?

• Hörst du, welche Felder Pflicht sind?

• Wird die Fehlermeldung vorgelesen, wenn du ins Feld zurückspringst?

• Hörst du nach dem Absenden die Fehlerzusammenfassung oder die Bestätigung?

Automatischer Test (2 Minuten)

• WAVE, axe DevTools oder Lighthouse im Browser laufen lassen. Für die Build-Pipeline gibt es Pa11y und axe-core.

Die ganze WCAG-Checkliste kannst du dir auch als PDF herunterladen und mit deinem Team durchgehen.

Welcher Screenreader? Am Desktop nutzen die meisten Screenreader-Nutzer:innen JAWS (40,5 %) oder NVDA (37,7 %), VoiceOver liegt bei 9,7 %. Mobil dominiert VoiceOver auf dem iPhone (WebAIM Screen Reader Survey 2024). Für den Selbsttest reichen NVDA (Windows, kostenlos) und VoiceOver (Mac und iPhone, eingebaut, am Mac mit Cmd + F5).

Was Tools nicht finden: Automatische Tests finden nur einen Teil der Probleme, je nach Studie etwa 40 bis 60 % (Deque). Ob eine Fehlermeldung verständlich ist oder die Reihenfolge Sinn ergibt, sagt dir kein Tool.

Tests mit Betroffenen: Am meisten lernst du, wenn Menschen mit Behinderungen dein Formular ausfüllen, zum Beispiel über das Test.Labor der Pfennigparade oder Fable. Bezahl fair: Die Tester:innen sind Expert:innen für ihre eigenen Bedürfnisse.

Fazit & nächste Schritte

Barrierefreie Formulare sind weniger kompliziert, als es klingt. Das meiste lösen native HTML-Elemente, sichtbare Labels und verständliche Fehlermeldungen. WCAG 2.2 legt bei Klickflächen, Fokus und Login nach, und genau dort hakt es in vielen SaaS-Produkten. Fang bei dem Formular an, an dem dein Umsatz hängt. Und bei neuen Features planst du Labels, Reihenfolge und Fehlerfälle am besten schon im Wireframe, wie im Leitfaden Barrierefreiheit im UX-Prozess beschrieben.

So startest du:

1. Dein wichtigstes Formular mit der 10-Minuten-Liste oben testen.

2. Alle Platzhalter-Labels durch sichtbare Labels ersetzen und autocomplete ergänzen.

3. Deaktivierte Absende-Buttons aktivieren und eine Fehlerzusammenfassung einbauen.

4. Login prüfen: Einfügen erlaubt, Passwort-Manager funktionieren, kein Rätsel-CAPTCHA.

Wenn du dir Unterstützung holen willst: Ich schau mir gern deine wichtigsten Formulare an und zeige dir konkret, wo es hakt. Schreib mir über das Kontaktformular.

Häufig gestellte Fragen zu barrierefreien Formularen

Wie erstelle ich ein barrierefreies Formular?

Gib jedem Feld ein sichtbares Label, das über for und id mit dem Feld verknüpft ist. Nutze native HTML-Elemente, kennzeichne Pflichtfelder in Textform und zeig Fehler als verständlichen Text direkt am Feld. Ergänze autocomplete für persönliche Daten und teste alles einmal nur mit der Tastatur.

Was muss ein barrierefreies Formular nach WCAG erfüllen?

Die wichtigsten Kriterien sind Labels und Anweisungen (3.3.2), Fehlererkennung und Korrekturvorschläge (3.3.1, 3.3.3), Bedienbarkeit per Tastatur (2.1.1), sichtbarer Fokus (2.4.7), ausreichender Kontrast (1.4.3, 1.4.11) und autocomplete für persönliche Daten (1.3.5). Mit WCAG 2.2 kommen Zielgröße, nicht verdeckter Fokus, redundante Eingabe, konsistente Hilfe und barrierefreie Authentifizierung dazu.

Reicht ein Placeholder als Label?

Nein. Ein Placeholder verschwindet beim Tippen, hat meist zu wenig Kontrast und wird nicht von jedem Screenreader zuverlässig vorgelesen. Er darf ein Beispiel zeigen, aber das Label braucht es trotzdem.

Wie zeige ich Fehlermeldungen barrierefrei an?

Direkt am Feld, als Text mit Icon und Farbe, und so formuliert, dass klar wird, wie es richtig geht. Im Code wird die Meldung über aria-describedby mit dem Feld verknüpft und das Feld mit aria-invalid="true" markiert. Beim Absenden zeigt eine Fehlerzusammenfassung alle Fehler mit Links zu den Feldern.

Wie kennzeichne ich Pflichtfelder barrierefrei?

In Textform, nicht nur mit Farbe oder einem unerklärten Sternchen. Sind fast alle Felder Pflicht, markierst du die optionalen mit „(optional)“ und erklärst das über dem Formular. Im Code bekommt jedes Pflichtfeld zusätzlich das Attribut required.

Was ist neu für Formulare in WCAG 2.2?

Fünf Kriterien auf Stufe A und AA betreffen Formulare direkt: Fokus nicht verdeckt (2.4.11), Zielgröße von mindestens 24 × 24 Pixeln (2.5.8), konsistente Hilfe (3.2.6), keine doppelte Eingabe (3.3.7) und ein Login ohne Gedächtnistest (3.3.8). Bei Letzterem gelten Passwort-Manager und Einfügen ausdrücklich als Hilfe.

Gilt das BFSG für mein Kontaktformular?

Das hängt vom Angebot ab, nicht vom Formular. Das BFSG gilt für Dienstleistungen für Verbraucher:innen, etwa Online-Shops oder Online-Terminbuchungen. Eine reine Präsentationswebsite mit Kontaktformular fällt laut Bundesfachstelle Barrierefreiheit eher nicht darunter, reines B2B ebenfalls nicht. Das ist keine Rechtsberatung.

Soll ich ein HTML- oder PDF-Formular erstellen?

In fast allen Fällen ein HTML-Formular. Es ist einfacher barrierefrei umzusetzen, funktioniert auf allen Geräten und lässt sich mit Screenreadern gut bedienen. PDF-Formulare lohnen sich nur, wenn ein Dokument gedruckt oder archiviert werden muss, und brauchen dann eine aufwendige Nachbearbeitung.

Wie teste ich mein Formular auf Barrierefreiheit?

Mit vier kurzen Tests: das Formular nur per Tastatur ausfüllen, auf 200 % zoomen, mit einem Screenreader wie NVDA oder VoiceOver durchgehen und ein automatisches Tool wie WAVE oder axe laufen lassen. Automatische Tools finden nur einen Teil der Probleme, die manuellen Tests sind deshalb Pflicht.