Zum Hauptinhalt springen

Kontakt-Formular BFSG-konform: eine Schritt-für-Schritt-Anleitung für Web-Entwickler

Porträtfoto von Dmitry Dugarev

Dmitry Dugarev

Berater für digitale Barrierefreiheit & IT-Compliance

Das Barrierefreiheitsstärkungsgesetz (BFSG) [1] ist in Kraft und rückt die digitale Barrierefreiheit in den Fokus. Für Dich als Entwickler heißt das: Jedes Element, besonders ein Kontaktformular, muss für absolut jeden bedienbar sein. Ein unzugängliches Formular ist nicht nur ein rechtliches Risiko, sondern auch eine verpasste Chance, mit potenziellen Kunden in Kontakt zu treten [2].

In dieser Anleitung bauen wir Schritt für Schritt ein Formular, das den aktuellen gesetzlichen Anforderungen entspricht. Ich erkläre Dir nicht nur, was zu tun ist, sondern auch, warum und mit entsprechenden Quellangaben auf offizielle Richtlinien. Am Ende hast Du ein robustes, barrierefreies Kontaktformular, das Du in Deinen Projekten einsetzen kannst.

Hier ist die Live-Demo des fertigen, barrierefreien Kontakt-Formulars:

Demo-Kontakt­formular

Alle mit einem Sternchen () markierten Felder sind Pflicht­felder. Wenn eine Nachricht abgeschickt wird, falls keine Fehler vorliegen, erscheint eine Erfolgsmeldung, aber es passiert nichts weiter.

Deine persön­lichen Daten
Eine gültige E-Mail-Adresse besteht aus Namen, dem "@"-Zeichen und einer Domain (z.B. max.muster­mann@example.tld).
Für eventuelle Rückfragen. Nur gültige deutsche Handynummern aus 7-11 Zeichen (z.B. 01701234567).
Bevorzugte Kontakt­methode

Grundstruktur & Anweisungen​

Die Basis jedes barrierefreien Formulars ist sauberes, semantisches HTML. Das fängt bei der korrekten Verknüpfung von Beschriftungen (<label>) mit ihren Eingabefeldern (<input>) an.

Jedes Feld braucht ein permanent sichtbares <label> [3], das über das for-Attribut mit der id des Feldes verbunden ist [4]. Platzhalter, die bei der Eingabe verschwinden, sind kein Ersatz für ein Label [5]. Auf der Abbildung 1.1 siehst Du die Beispielstruktur eines barrierefreien Formulars, den wir im Folgenden aufbauen werden.

Außerdem solltest Du allgemeine Anweisungen, wie die Kennzeichnung von Pflichtfeldern, vor dem Formular platzieren, damit Nutzer wissen, was sie erwartet [6]. Die Labels der Eingabefelder sollen ebenfalls vor dem Feld stehen [7].

Textbeschreibung für "Schematische Grundstruktur eines barrierefreien Formulars" öffnen

Dieses Diagramm zeigt die Grundbausteine eines Formulars.

  1. Kontakt-Formular: Das äußerste Element, das alles umschließt. Es enthält Anweisungen, eine Fehlerübersicht, Fieldsets und einen Sende-Button.
  2. Feldgruppen (<fieldset>): Dient zur Gruppierung der verwandten Eingabefelder. Es enthält eine Beschriftung (<legend>) und die eigentlichen Eingabefelder.
  3. Eingabefelder: Jedes Feld besteht aus einer Beschriftung (<label>), die mit einem Eingabefeld (<input>) verknüpft ist. Zusätzlich kann es eine Eingabehilfe geben, die weitere Informationen zum Feld bereitstellt.

Hier ist ein Codebeispiel für die Grundstruktur:

HTML: Grundstruktur des Formulars
<p id="form-instructions-demo">
  Alle mit einem Sternchen (*) markierten Felder sind Pflichtfelder.
</p>

<div
  id="error-summary-demo"
  class="contact-form__error-summary"
  role="alert"
  tabIndex="-1"
  hidden
  aria-labelledby="error-summary-title-demo"
>
  <h2 id="error-summary-title-demo">Ihre Eingaben sind fehlerhaft</h2>
  <p id="error-summary-intro"></p>
  <ul class="contact-form__error-summary-list">
    </ul>
</div>

<form id="contact-form-demo" class="contact-form__form" novalidate>
  <div class="contact-form__group">
    <label for="fname-demo" class="contact-form__label">
      <span class="contact-form__error-prefix" hidden>Fehler: </span>
      Vorname*
    </label>
    <input
      type="text"
      id="fname-demo"
      name="fname"
      required
      aria-required="true"
      aria-invalid="false"
      aria-describedby="fname-error-demo"
      class="contact-form__input"
    />
    <div
      id="fname-error-demo"
      class="contact-form__error-message"
      hidden
    ></div>
  </div>
  <button type="submit" class="contact-form__submit-button">
    Nachricht senden
  </button>
</form>

Wir verwenden novalidate im <form>-Tag, um die unzugängliche Standard-Validierung des Browsers zu deaktivieren und die Fehlerbehandlung selbst zu steuern.

Fokus-Reihenfolge und Sichtbarkeit für Tastaturbedienbarkeit​

Ein Formular, das man nicht ohne Maus bedienen kann, ist nicht barrierefrei. Zwei Kriterien sind hier essenziell:

  1. Logische Fokus-Reihenfolge: Nutzer, die mit der Tab-Taste navigieren, müssen sich in einer logischen und intuitiven Reihenfolge durch das Formular bewegen können [9]. Bei einer sauberen HTML-Struktur (von oben nach unten) ist dies meist automatisch gegeben. Komplexere Layouts (z.B. mit CSS Grid oder Flexbox) müssen daraufhin geprüft werden.

  2. Sichtbarer Fokus: Jedes interaktive Element (Input, Button, Link) muss einen deutlich sichtbaren Indikator zeigen, wenn es den Fokus erhält [10]. Dies ist der "Sie sind hier"-Indikator für Tastaturnutzer. Verstecke niemals den outline-Stil, ohne einen besseren, deutlich sichtbaren Ersatz zu bieten.

Logische Gruppierung der Eingabefelder​

Zusammengehörige Informationen (wie "Vorname" und "Nachname" oder eine Gruppe von Radio-Buttons) müssen auch programmatisch als Gruppe erkennbar sein [11]. Dafür nutzt Du <fieldset> und <legend> [12] oder alternativ ARIA-Rollen wie role="group" [13].

Das <fieldset> umschließt die Gruppe, und die <legend> gibt ihr einen Namen, den Screenreader vorlesen [12]. Ohne diese Struktur müssen Nutzer assistiver Technologien raten, welche Felder einen thematischen Block bilden.

HTML: Felder mit <fieldset> gruppieren
<fieldset class="contact-form__fieldset">
  <legend class="contact-form__legend">Ihre persönlichen Daten</legend>

  <div class="contact-form__group">
    <label for="fname-demo" class="contact-form__label">
      <span class="contact-form__error-prefix" hidden>Fehler: </span>
      Vorname*
    </label>
    <input
      type="text"
      id="fname-demo"
      name="fname"
      required
      aria-required="true"
      aria-invalid="false"
      aria-describedby="fname-error-demo"
      class="contact-form__input"
    />
    <div id="fname-error-demo" class="contact-form__error-message" hidden></div>
  </div>

  <div class="contact-form__group">
    <label for="lname-demo" class="contact-form__label">
      <span class="contact-form__error-prefix" hidden>Fehler: </span>
      Nachname*
    </label>
    <input
      type="text"
      id="lname-demo"
      name="lname"
      required
      aria-required="true"
      aria-invalid="false"
      aria-describedby="lname-error-demo"
      class="contact-form__input"
    />
    <div id="lname-error-demo" class="contact-form__error-message" hidden></div>
  </div>
</fieldset>

<fieldset
  class="contact-form__fieldset"
  aria-describedby="contactMethod-group-error-demo"
>
  <legend id="contactMethod-legend" class="contact-form__legend">
    <span class="contact-form__error-prefix" hidden>Fehler: </span>
    Bevorzugte Kontaktmethode*
  </legend>
  <div class="contact-form__radio-group">
    <label for="contact-pref-email-demo" class="contact-form__radio-label">
      <input
        type="radio"
        id="contact-pref-email-demo"
        name="contactMethod"
        value="email"
        required
        aria-required="true"
        class="contact-form__radio-input"
      />
      Per E-Mail
    </label>
    <label for="contact-pref-phone-demo" class="contact-form__radio-label">
      <input
        type="radio"
        id="contact-pref-phone-demo"
        name="contactMethod"
        value="phone"
        required
        aria-required="true"
        class="contact-form__radio-input"
      />
      Per Telefon
    </label>
  </div>
  <div
    id="contactMethod-group-error-demo"
    class="contact-form__error-message"
    hidden
  ></div>
</fieldset>

Hilfetexte & Eingabe-Unterstützung​

Manchmal brauchen Felder zusätzliche Erklärungen, z.B. zu einem bestimmten Format. Diese Hilfetexte müssen programmatisch mit dem Feld verknüpft werden.

Dafür bekommt der Hilfetext eine id und das <input>-Element ein aria-describedby-Attribut, das auf diese id verweist [14]. Ein Screenreader liest dann zuerst das Label und anschließend den Hilfetext vor.

Um die Eingabe weiter zu erleichtern, solltest Du das autocomplete-Attribut verwenden [15]. Es erlaubt dem Browser, bekannte Daten (Name, E-Mail, etc.) automatisch vorzuschlagen. Das ist nicht nur komfortabel, sondern eine explizite Anforderung [16].

HTML: Hilfetexte und Autocomplete
<div class="contact-form__group">
  <label for="phone-demo" class="contact-form__label">
    <span class="contact-form__error-prefix" hidden>Fehler: </span>
    Handynummer (Optional)
  </label>
  <input
    type="tel"
    id="phone-demo"
    name="phone"
    autocomplete="tel"
    aria-invalid="false"
    aria-describedby="phone-hint-demo phone-error-demo"
    class="contact-form__input"
    placeholder="z.B.: 01701234567"
  />
  <span id="phone-hint-demo" class="contact-form__help-text">
    Für eventuelle Rückfragen. Nur gültige deutsche Handynummern.
  </span>
  <div id="phone-error-demo" class="contact-form__error-message" hidden></div>
</div>

<div class="contact-form__group">
  <label for="email-demo" class="contact-form__label">
    <span class="contact-form__error-prefix" hidden>Fehler: </span>
    E-Mail-Adresse*
  </label>
  <input
    type="email"
    id="email-demo"
    name="email"
    autocomplete="email"
    required
    aria-required="true"
    aria-invalid="false"
    aria-describedby="email-hint-demo email-error-demo"
    class="contact-form__input"
  />
  <span id="email-hint-demo" class="contact-form__help-text">
    Eine gültige E-Mail-Adresse (z.B. max.mustermann@example.com).
  </span>
  <div id="email-error-demo" class="contact-form__error-message" hidden></div>
</div>

Fehlerbehandlung & Validierung​

Fehler passieren. Ein barrierefreies Formular leitet den Nutzer präzise zur Korrektur an [18]. Die Standard-Validierung des Browsers (die wir mit novalidate deaktiviert haben) ist hierfür ungeeignet, da ihre Meldungen oft nicht fokussierbar sind oder von Screenreadern nicht wahrgenommen werden [19].

Unser Ansatz besteht aus drei Teilen:

  1. Fehlerzusammenfassung: Ein <div> am Anfang des Formulars, das alle Fehler auflistet [6]. Das hilft Nutzern, schnell zu sehen, was korrigiert werden muss und ermöglicht es, direkt zu den fehlerhaften Feldern zu springen [20].
  2. Inline-Fehler: Eine Textmeldung direkt unter dem fehlerhaften Feld, um dem Nutzer ausführliche Informationen zur Verfügung zu stellen [21]. Das Eingabefeld selbst wird mit aria-invalid="true" markiert, damit Screenreader den Fehler erkennen [22].
  3. Fokusmanagement: Der Fokus wird bei einem Fehler per JavaScript aktiv auf die Fehlerzusammenfassung gesetzt.
  4. Wir passen das <label> (oder die <legend>) jedes fehlerhaften Feldes an, indem wir ein "Fehler: "-Präfix hinzufügen. Dies ist entscheidend, um WCAG-Erfolgskriterium 1.4.1 [23] zu erfüllen. Wenn wir nur die Farbe ändern würden, wäre der Fehler für farbenblinde Nutzer nicht erkennbar.

Auf der Abbildung 4.1 siehst Du die Logik der Validierung und Fehlerbehandlung, die wir im Folgenden implementieren werden.

Textbeschreibung für "Logik der barrierefreien Fehlerbehandlung" öffnen

Dieses Ablaufdiagramm zeigt den Validierungsprozess:

  1. Der Benutzer klickt auf "Senden".
  2. JavaScript verhindert das Standard-Senden.
  3. Die resetErrors()-Funktion löscht alle alten Fehlermeldungen.
  4. Die validateForm()-Funktion prüft alle Felder.
  5. Eine Entscheidung prüft: "Fehler gefunden?".
  6. Wenn Ja: Die showErrorSummary()-Funktion füllt die Fehlerzusammenfassung, showInlineError() markiert die Felder, und der Fokus wird per errorSummary.focus() auf die Fehlerzusammenfassung gesetzt.
  7. Wenn Nein: Das Formular wird abgesendet.

Jetzt bauen wir die Logik und die HTML-Struktur für die Fehlerbehandlung.

Die Fehlerzusammenfassung müssen im HTML vorbereitet sein. Die Zusammenfassung erhält role="alert", damit Screenreader sie bei Einblendung sofort vorlesen [25], und tabindex="-1", damit wir sie per JavaScript fokussieren können [26].

HTML: Fehlerzusammenfassung vorbereiten
<div
  id="error-summary-demo"
  class="contact-form__error-summary"
  role="alert"
  tabindex="-1"
  hidden
  aria-labelledby="error-summary-title-demo"
>
  <h2 id="error-summary-title-demo">Ihre Eingaben sind fehlerhaft</h2>
  <p id="error-summary-intro"></p>
  <ul class="contact-form__error-summary-list"></ul>
</div>

<!-- Formularfelder -->

In diesem Beispiel ist die Fehlerzusammenfassung zunächst mit hidden und aria-hidden="true" ausgeblendet. Sobald ein Fehler auftritt, wird sie per JavaScript sichtbar gemacht.

Damit ist die barrierefreie Fehlerbehandlung implementiert!

Absendestatus (Loading) barrierefrei gestalten​

Nachdem ein Nutzer auf "Senden" klickt und das Formular valide ist, beginnt der Sendevorgang. Dieser Netzwerk-Request dauert einen Moment. Wenn Du hier kein Feedback gibst, ist der Nutzer unsicher:

  • "Ist etwas passiert?"
  • "Muss ich nochmal klicken?"

Dieses unsichere "Dazwischen" müssen wir barrierefrei überbrücken. Die beste Methode ist, den Button zu deaktivieren, um doppeltes Absenden zu verhindern [27], und einen "Beschäftigt"-Status zu kommunizieren.

Wir passen dafür den else-Block in unserem submit-Event-Listener an.

JavaScript: Submit-Button deaktivieren und Status ansagen
// ... im submit-Event-Listener ...

// ... (Variablen-Definitionen)
const submitButton = form.querySelector('button[type="submit"]');

if (Object.keys(newErrors).length > 0) {
  // ... (Fehlerbehandlung wie oben) ...
} else {
  // KEINE FEHLER: Formular absenden

  // 1. UI-Status auf 'submitting' setzen
  // Diese Funktion steuert den Button, Spinner und Live-Region
  updateUIforStatusChange('submitting');

  // 2. Hier kommt Deine echte Sende-Logik (z.B. fetch)
  // In diesem Beispiel simulieren wir es:
  simulateFormSend() // Diese Funktion gibt ein Promise zurück
    .then((response) => {
      // Erfolgsfall behandeln
      updateUIforStatusChange('success');
    })
    .catch((error) => {
      // Fehlerfall behandeln
      updateUIforStatusChange('error');
    });
}
// ...

/**
 * Simuliert das Senden (dauert 3 Sek.)
 */
function simulateFormSend() {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve({ success: true });
    }, 3000);
  });
}

Für die Statusansage (statusRegion.textContent = ...) brauchen wir eine Live-Region. Diese kannst Du direkt neben Deiner Fehlerzusammenfassung im HTML platzieren. Wichtig ist role="status" und aria-live="polite", damit die Ansage die aktuelle Screenreader-Ausgabe nicht unterbricht [28].

HTML: Live-Region für Lade- und Erfolgsstatus
<div
  id="form-status-message"
  role="status"
  aria-live="polite"
  class="visually-hidden"
>
  <!-- Hier wird der Status angezeigt -->
</div>

Status nach dem Absenden (Erfolg/Fehler)​

Nach dem Ladevorgang gibt es zwei Ergebnisse: Erfolg (HTTP 200) oder Fehler (z.B. Server-Fehler, HTTP 500). Beides musst Du dem Nutzer unmissverständlich mitteilen. Hier gibt es zwei gängige, barrierefreie Szenarien.

Das ist die robusteste und einfachste Methode.

  1. Bei Erfolg: Leite den Nutzer auf eine "Danke"-Seite (z.B. /kontakt/danke).
  2. Bei Fehler: Leite den Nutzer auf eine "Fehler"-Seite (z.B. /kontakt/fehler).

Hier ein Beispiel für die Erfolgs-Weiterleitung im handleSuccess():

JavaScript: Erfolgs-Weiterleitung
function handleSuccess(response) {
  // 1. Erfolgs-Weiterleitung
  window.location.href = '/kontakt/danke';
}

Damit das barrierefrei ist, muss die neue Seite:

  • Einen klaren, beschreibenden <title>-Tag haben (z.B. "Danke für Ihre Nachricht - Meine Webseite").
  • Eine klare <h1>-Überschrift haben (z.B. "Vielen Dank!").
  • Der Fokus wird beim Laden der neuen Seite automatisch an den Anfang des Dokuments gesetzt, wodurch der Screenreader den neuen Seitentitel und die <h1> vorliest.

Du brauchst hierfür kein aria-live oder Fokusmanagement, da der Browser-Seitenwechsel den Kontextwechsel bereits klar kommuniziert.

Fazit​

Ein barrierefreies Formular zu erstellen, ist kein Hexenwerk, sondern solides Handwerk. Es erfordert Sorgfalt und ein Verständnis dafür, wie unterschiedliche Menschen mit dem Web interagieren.

Indem Du semantisches HTML verwendest (label, fieldset), klare Strukturen schaffst und eine fehlertolerante, unterstützende Benutzerführung implementierst, erfüllst Du nicht nur die gesetzlichen Anforderungen des BFSG [1]. Du baust ein besseres, benutzerfreundlicheres Produkt für alle Deine Nutzer [29]. Die hier gezeigten Techniken sind universell einsetzbar und ein entscheidender Schritt hin zu einem wirklich inklusiven Internet.

Eine zusammengefasste Checkliste aller Punkte aus dieser Anleitung findest Du in meiner Formular-Checkliste für Web-Entwickler.

Häufig gestellte Fragen (FAQ) zu barrierefreien Formularen​

Warum novalidate im <form>-Tag verwenden?​

Das Attribut novalidate schaltet die Standard-Fehlermeldungen des Browsers ab. Diese sind oft nicht barrierefrei (z.B. nur als kleine Tooltips sichtbar, die nach kurzer Zeit verschwinden) und nicht einheitlich gestaltet [19]. Mit novalidate übernehmen wir die volle Kontrolle und können eine robuste, für alle zugängliche Fehlerbehandlung mit JavaScript implementieren.

Reicht ein roter Rahmen für Fehlermeldungen nicht aus?​

Nein. Ein roter Rahmen ist eine rein visuelle Information und für Nutzer mit Sehbehinderungen (z.B. Farbenblindheit) oder bei Nutzung eines Screenreaders nicht wahrnehmbar [23]. Barrierefreie Fehlerbehandlung erfordert programmatische Zustände (wie aria-invalid="true") [22] und Text-Alternativen, die von assistiven Technologien ausgelesen werden können [18].

Muss ich WCAG 2.1 oder 2.2 befolgen?​

Das BFSG bezieht sich über die EU-Norm EN 301 549 [30] derzeit auf die WCAG 2.1 [31]. Allerdings ist WCAG 2.2 [32] der neuere, empfohlene Standard. Es ist eine bewährte Praxis (Best Practice), sich bereits an WCAG 2.2 zu orientieren, da dies zukunftssicher ist und die Anforderungen von 2.1 vollständig abdeckt. Mehr dazu findest Du in meinem Bereich "Gesetzeslage rund um digitale Barrierefreiheit".

Was ist der Unterschied zwischen required und aria-required="true"?​

required ist ein HTML5-Attribut, das dem Browser mitteilt, dass ein Feld ausgefüllt werden muss (und löst die native Validierung aus, wenn novalidate fehlt). aria-required="true" ist ein ARIA-Attribut, das assistiven Technologien (wie Screenreadern) explizit und auf die robusteste Weise mitteilt, dass ein Feld ein Pflichtfeld ist. Es ist am besten, beide zu verwenden, um eine maximale Kompatibilität und semantische Klarheit zu gewährleisten, weil in manchen Fällen required allein nicht von allen Technologien korrekt interpretiert wird oder ARIA nicht unterstützt wird.

Was ist mit der Klick-Größe von Buttons (Target Size)?​

Eine wichtige Neuerung in WCAG 2.2 ist das Kriterium 2.5.8 Target Size (Minimum) (Level AA) [33]. Es besagt, dass interaktive Elemente (Buttons, Links, Radio-Buttons, Checkboxen) eine Mindestgröße von 24x24 CSS-Pixeln nicht unterschreiten sollten.

Dies ist entscheidend für Nutzer mit motorischen Einschränkungen, z.B. auf Touch-Geräten oder bei zittrigen Händen, da es das versehentliche Klicken auf das falsche Element reduziert. Achte bei deinem CSS darauf, dass deine Klick-Ziele (insbesondere die oft zu kleinen Radio-Buttons und Checkboxen) diese Anforderung erfüllen.

Haftungsausschluss​

Der Inhalt dieses Leitfadens dient ausschließlich zu Informationszwecken und stellt keine Rechtsberatung dar. Obwohl ich mich bemühe, genaue und aktuelle Informationen bereitzustellen, übernehme ich keine Gewähr für die Vollständigkeit, Richtigkeit oder Aktualität der bereitgestellten Informationen. Die Einhaltung der Barrierefreiheitsstandards kann je nach spezifischem Kontext und Anwendungsfall variieren. Es wird empfohlen, bei der Implementierung von barrierefreien Formularen professionelle Beratung in Anspruch zu nehmen und regelmäßige Tests mit echten Benutzern durchzuführen, um sicherzustellen, dass die Anforderungen der WCAG-2.2-Richtlinien erfüllt werden. Ich hafte nicht für Schäden oder Verluste, die sich aus der Nutzung oder dem Vertrauen auf die in diesem Leitfaden enthaltenen Informationen ergeben.

​

  1. Bundesministerium der Justiz und für Verbraucherschutz, „Gesetz zur Umsetzung der Richtlinie (EU) 2019/882 des Europäischen Parlaments und des Rates über die Barrierefreiheitsanforderungen für Produkte und Dienstleistungen (Barrierefreiheitsstärkungsgesetz – BFSG)“. 2023. [Online]. Verfügbar unter: https://www.gesetze-im-internet.de/bfsg/ ⤴
  2. Forrester Research, „Accessibility Is Still Vital For Businesses“. 3. Februar 2025. [Online]. Verfügbar unter: https://www.forrester.com/blogs/accessibility-is-still-vital-for-businesses/ ⤴
  3. W3C, „Success Criterion 3.3.2 Labels or Instructions“, 2023, [Online]. Verfügbar unter: https://www.w3.org/TR/WCAG22/#labels-or-instructions ⤴
  4. W3C, „H44: Using label elements to associate text labels with form controls“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/html/H44 ⤴
  5. W3C, „F82: Failure of Success Criterion 3.3.2 by visually formatting a set of phone number fields but not including a text label“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/failures/F82 ⤴
  6. W3C, „G83: Providing text descriptions to identify required fields that were not completed“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G83 ⤴
  7. W3C, „G162: Positioning labels to maximize predictability of relationships“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G162 ⤴
  8. W3C, „Success Criterion 1.4.10 Reflow“, 2023, [Online]. Verfügbar unter: https://www.w3.org/TR/WCAG22/#reflow ⤴
  9. W3C, „Success Criterion 2.4.3 Focus Order“, 2023, [Online]. Verfügbar unter: https://www.w3.org/TR/WCAG22/#focus-order ⤴
  10. W3C, „Success Criterion 2.4.7 Focus Visible“, 2023, [Online]. Verfügbar unter: https://www.w3.org/TR/WCAG22/#focus-visible ⤴
  11. W3C, „Success Criterion 1.3.1 Info and Relationships“, 2023, [Online]. Verfügbar unter: https://www.w3.org/TR/WCAG22/#info-and-relationships ⤴
  12. W3C, „H71: Providing a description for groups of form controls using fieldset and legend elements“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/html/H71 ⤴
  13. W3C, „ARIA17: Using grouping roles to identify related form controls“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA17 ⤴
  14. W3C, „ARIA1: Using the aria-describedby property to provide a descriptive label for user interface controls“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA1 ⤴
  15. W3C, „H98: Using HTML autocomplete attributes“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/html/H98 ⤴
  16. W3C, „Success Criterion 1.3.5 Identify Input Purpose“, 2023, [Online]. Verfügbar unter: https://www.w3.org/TR/WCAG22/#identify-input-purpose ⤴
  17. W3C, „Success Criterion 1.4.3 Contrast (Minimum)“, 2023, [Online]. Verfügbar unter: https://www.w3.org/TR/WCAG22/#contrast-minimum ⤴
  18. W3C, „Success Criterion 3.3.1 Error Identification“, 2023, [Online]. Verfügbar unter: https://www.w3.org/TR/WCAG22/#error-identification ⤴
  19. E. Smith, „Accessible form validation with examples and code“, Pope Tech, Okt. 2025, [Online]. Verfügbar unter: https://blog.pope.tech/2025/09/30/accessible-form-validation-with-examples-and-code/ ⤴
  20. W3C, „G139: Creating a mechanism that allows users to jump to errors“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G139 ⤴
  21. W3C, „G85: Providing a text description when user input falls outside the required format or values“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G85 ⤴
  22. W3C, „ARIA21: Using aria-invalid to Indicate An Error Field“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA21 ⤴
  23. W3C, „Success Criterion 1.4.1 Use of Color“, 2023, [Online]. Verfügbar unter: https://www.w3.org/TR/WCAG22/#use-of-color ⤴
  24. W3C Web Accessibility Initiative (WAI), „W3C Forms Tutorial: User Notifications“. 2023. [Online]. Verfügbar unter: https://www.w3.org/WAI/tutorials/forms/notifications/ ⤴
  25. W3C, „ARIA19: Using ARIA role=alert or Live Regions to Identify Errors“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA19 ⤴
  26. WHATWG, „HTML Living Standard“. 2024. [Online]. Verfügbar unter: https://html.spec.whatwg.org/ ⤴
  27. W3C, „Success Criterion 3.3.4 Error Prevention (Legal, Financial, Data)“, 2023, [Online]. Verfügbar unter: https://www.w3.org/TR/WCAG22/#error-prevention-legal-financial-data ⤴
  28. W3C, „Success Criterion 4.1.3 Status Messages“, 2023, [Online]. Verfügbar unter: https://www.w3.org/TR/WCAG22/#status-messages ⤴
  29. W3C Web Accessibility Initiative, „The Case for Digital Accessibility“. 2022. [Online]. Verfügbar unter: https://www.w3.org/WAI/business-case/ ⤴
  30. ETSI, „ETSI EN 301 549 V3.2.1 (2021-03) - Accessibility requirements for ICT products and services“. 2021. [Online]. Verfügbar unter: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/03.02.01_60/en_301549v030201p.pdf ⤴
  31. W3C, „Web Content Accessibility Guidelines (WCAG) 2.1“. 2021. [Online]. Verfügbar unter: https://www.w3.org/TR/WCAG21/ ⤴
  32. W3C, „Web Content Accessibility Guidelines (WCAG) 2.2“. 2023. [Online]. Verfügbar unter: https://www.w3.org/TR/WCAG22/ ⤴
  33. W3C, „Success Criterion 2.5.8 Target Size (Minimum)“, 2023, [Online]. Verfügbar unter: https://www.w3.org/TR/WCAG22/#target-size-minimum ⤴
Porträtfoto von Dmitry Dugarev

Beste Grüße

Dmitry Dugarev

Gründer von Barrierenlos℠ und Entwickler des Semanticality™ Plugins. Mit einem Masterabschluss, über 8 Jahren Erfahrung in Web-Entwicklung & IT-Compliance bei Big-Four, Banken und Konzernen und mehr als 1.000 auf Barrierefreiheit geprüften Seiten für über 50 Kunden helfe ich Web-Teams, Barrierefreiheit planbar umzusetzen – ohne monatelange Umbauten.

Werde selbst zum BFSG-Profi-Entwickler. In nur 4 Tagen.

Lerne in unserem 4-Tage-Workshop, wie Du komplexe Audits selbst durchführst und barrierefreie Komponenten entwickelst. Erhalte einen individuellen Lernplan, 1:1-Strategie-Gespräch und ein Zertifikat.

Jetzt zum Workshop anmelden

Auf dieser Seite

Deine Privatsphäre ist uns wichtig

Wir verwenden Cookies, um Dein Surferlebnis zu verbessern und den Website-Traffic zu analysieren. Wähle aus, welche Cookies wir verwenden dürfen. Weitere Informationen findest Du in unserer Datenschutzerklärung.

Diese Cookies sind für die Grundfunktionalität der Website erforderlich und können nicht deaktiviert werden.

Diese Cookies helfen uns zu verstehen, wie Besucher mit unserer Website interagieren, indem sie Informationen anonym sammeln und melden.

  • Google Analytics: Sammelt anonyme Statistiken zur Seitennutzung.
  • Hotjar: Analysiert das Klick- und Scrollverhalten zur Verbesserung der Nutzerfreundlichkeit (anonymisiert).

Diese Cookies werden verwendet, um Dir relevante Werbung auf anderen Plattformen anzuzeigen und Inhalte basierend auf Deinen Interessen bereitzustellen.

  • Google Ads & Microsoft Ads: Messen den Erfolg von Werbeanzeigen und ermöglichen personalisierte Werbung.
  • Meta Pixel: Ermöglicht zielgerichtete Werbung auf Facebook und Instagram.
  • Affiliate-Tracking (Freemius): Ordnet Käufe einem vermittelnden Partner zur Provisionsabrechnung zu (30 Tage Speicherdauer) - falls Du über einen Affiliate-Link zu uns gekommen bist, müssen diese Cookies aktiviert sein, damit der Partner seine Provision erhält.