Barrierefreie Formulare: Labels und Eingaben prüfen
Barrierefreie Formulare erklären, welche Eingabe erwartet wird, und machen diese Information auch für Hilfsmittel verfügbar. Eine sichtbare Beschriftung, der technische Name eines Feldes und eine Formatvorgabe erfüllen dabei unterschiedliche Aufgaben.
Wenn „Telefonnummer“ beim Tippen verschwindet oder ein Screenreader nur „Eingabefeld“ meldet, fehlt Menschen die Orientierung. Die folgenden HTML-Beispiele helfen Dir, solche Ursachen in Kontaktformularen, Kontoeinstellungen und Checkouts zu unterscheiden. Sie behandeln HTML-Formulare im Browser, keine PDF-Formulare.
Was braucht ein verständlich beschriftetes Formularfeld?
Ein Label sagt, wofür das Feld da ist. Bei einer expliziten HTML-Verknüpfung zeigt for im Label auf die id des Feldes. name bestimmt dagegen den Schlüssel für die Formularübermittlung; es ersetzt kein Label. Auch ein umschließendes <label> kann das Feld verknüpfen. Die HTML-Spezifikation beschreibt beide Möglichkeiten.
Der zugängliche Name ist die Bezeichnung, die der Browser an Hilfsmittel weitergibt. Ein zusätzlicher Hinweis erklärt etwa ein Eingabeformat. WCAG 3.3.2 verlangt Labels oder Anleitungen für Eingaben. Die technische Zuordnung und der zugängliche Name werden zusätzlich durch 1.3.1 und 4.1.2 abgedeckt. Ein vorhandener Name allein belegt deshalb noch kein gut nutzbares Feld.
Barrierefreie Formulare: sechs typische Fälle im HTML
Die schlechten und verbesserten Fassungen sind isolierte Lehrbeispiele. Teste jede Fassung einzeln, damit ihre IDs nicht mit denen anderer Beispiele kollidieren. Die Ergebnistabelle bezieht sich auf genau diese Ausschnitte, nicht auf ein vollständiges Formular.
1. Dem Feld fehlt eine Beschriftung
Schlecht: Das Feld hat eine technische Kennung, aber keinen Namen für Menschen.
<input id="email" name="email" type="email">
Verbessert: Eine sichtbare Beschriftung bleibt beim Tippen erhalten und ist mit dem Feld verbunden.
<label for="email">E-Mail-Adresse</label>
<input id="email" name="email" type="email">
2. Label und Feld verwenden unterschiedliche IDs
Schlecht: Die Wörter stehen sichtbar vor dem Feld, doch for="email" findet kein passendes Element.
<label for="email">E-Mail-Adresse</label>
<input id="contact-email" name="email" type="email">
Verbessert: for und id stimmen überein. Ein Klick auf das Label erreicht nun das zugehörige Feld.
<label for="contact-email">E-Mail-Adresse</label>
<input id="contact-email" name="email" type="email">
3. Eine wiederverwendete Komponente erzeugt doppelte IDs
Schlecht: Zwei Felder heißen email. Beide Labels verweisen dadurch auf dasselbe erste Feld; dem zweiten fehlt die Zuordnung.
<label for="email">E-Mail für Lieferung</label>
<input id="email" name="shippingEmail" type="email">
<label for="email">E-Mail für Rechnung</label>
<input id="email" name="billingEmail" type="email">
Verbessert: Jede Instanz erhält eine eigene ID. Unterscheidbare Labels erklären zusätzlich, welche Adresse erwartet wird.
<label for="shipping-email">E-Mail für Lieferung</label>
<input id="shipping-email" name="shippingEmail" type="email">
<label for="billing-email">E-Mail für Rechnung</label>
<input id="billing-email" name="billingEmail" type="email">
Prüfe wiederverwendete Komponenten gemeinsam auf einer Seite. Eine einzelne Instanz zeigt die Kollision nicht. Die HTML-Regel für for erklärt, warum die erste passende ID entscheidend ist.
4. Ein Platzhalter verschwindet beim Tippen
Schlecht: Der Platzhalter übernimmt die gesamte sichtbare Beschriftung.
<input id="phone" name="phone" type="tel" placeholder="Telefonnummer">
Verbessert: Das Label benennt das Feld dauerhaft. Der optionale Platzhalter zeigt ein Beispiel.
<label for="phone">Telefonnummer</label>
<input id="phone" name="phone" type="tel" autocomplete="tel"
placeholder="z. B. +49 30 123456">
Im getesteten Browser hatte auch die schlechte Fassung den zugänglichen Namen „Telefonnummer“. Die axe-Regel label meldete deshalb keinen Fehler. Nach einer Eingabe war die sichtbare Beschriftung trotzdem weg. W3C erläutert diesen Nachteil von Platzhaltern. Kontrolliere das Feld mit eingetipptem Text und nach automatischem Ausfüllen.
5. Ein ausgeblendetes Label ist nicht automatisch zugänglich
Eine kompakte Suche kann ihren Zweck durch ein direkt benachbartes, sichtbares „Suchen“ vermitteln. In diesem Kontext kann ein nur visuell verborgenes Label sinnvoll sein. Bei gewöhnlichen Kontakt- oder Adressfeldern behältst Du die sichtbare Beschriftung bei. W3C zeigt diese Ausnahme am Suchfeld.
Schlecht: hidden entfernt die Beschriftung aus der üblichen Darstellung und dem zugänglichen Namen dieses Beispiels.
<form role="search">
<label for="site-search" hidden>Website durchsuchen</label>
<input id="site-search" name="q" type="search">
<button type="submit">Suchen</button>
</form>
Verbessert: sr-only verbirgt den Text nur visuell. Hier ist damit die vorhandene Tailwind-Hilfsklasse gemeint, nicht display: none, visibility: hidden oder ein frei gewählter Klassenname ohne CSS.
<form role="search">
<label for="site-search" class="sr-only">Website durchsuchen</label>
<input id="site-search" name="q" type="search">
<button type="submit">Suchen</button>
</form>
Ein zusätzliches aria-label ist bei einem passend verknüpften Label normalerweise unnötig. Es kann den sichtbaren Text als Namensquelle verdrängen. Enthält der Name andere Wörter als die sichtbare Beschriftung, kann auch die Sprachsteuerung scheitern; siehe WCAG 2.5.3.
6. Autocomplete beschreibt den Zweck der Eingabe
Ein Label hilft Menschen, autocomplete macht bestimmte Eingabezwecke maschinell erkennbar. WCAG 1.3.5 (AA) betrifft Informationen über die nutzende Person, deren Zweck in der festgelegten Liste steht und mit der verwendeten Technik erkennbar gemacht werden kann. Die Anforderung gilt nicht pauschal für jedes Textfeld, etwa eine freie Nachricht.
Schlecht: firstname ist kein gültiger Autocomplete-Wert.
<label for="given">Vorname</label>
<input id="given" name="givenName" autocomplete="firstname">
Verbessert: given-name bezeichnet den Vornamen der Person, die das Formular ausfüllt.
<label for="given">Vorname</label>
<input id="given" name="givenName" autocomplete="given-name">
Die HTML-Autofill-Liste enthält weitere passende Werte wie family-name, email und postal-code. Wähle sie nach der tatsächlich abgefragten Information. type="email" beschreibt nur eine Art von Eingabe; es sagt nicht, wessen Adresse gemeint ist. Ob der Browser im Test wirklich Daten einfügt, entscheidet nicht über die Erfüllung von 1.3.5.
Was ergab die Prüfung dieser Beispiele?
Wir haben die HTML-Ausschnitte mit Chromium 149 und axe-core 4.13.0 geprüft. „Bestanden“ bedeutet hier nur, dass die genannte Zuordnung beziehungsweise Eigenschaft im Beispiel funktioniert. Es bedeutet keine vollständige WCAG-Konformität. Die Browser-Namen wurden über den Accessibility Tree ausgelesen, also die vom Browser bereitgestellte Darstellung für Hilfsmittel.
axe meldete label beim fehlenden Label, beim falschen for und beim mit hidden versteckten Suchlabel. Für firstname meldete es autocomplete-valid. Bei den verbesserten Fassungen blieben diese Befunde aus. Die korrigierten E-Mail-Felder hatten den Browser-Namen „E-Mail-Adresse“, das Suchfeld „Website durchsuchen“.
Bei den doppelten IDs gab axe in diesem Lauf einen Prüfhinweis (incomplete) für duplicate-id-aria aus, keinen automatischen Verstoß. Der Browser zeigte dennoch die falsche Zuordnung und das namenlose zweite Feld. Ein Prüfhinweis braucht eine eigene Bewertung.
Auch das vollständige Weglassen von autocomplete löste in unserem Zusatztest keinen Befund der Regel autocomplete-valid aus. Die Regel prüft vorhandene Werte; sie entscheidet nicht für Dich, welche personenbezogenen Felder einen erkennbaren Zweck brauchen. Prüfe das anhand des Formularinhalts und der W3C-Eingabezwecke.
Hinweise und Fehlermeldungen ergänzen
Ein Hinweis erklärt die Eingabe, ohne das Label zu ersetzen. Verbinde ihn mit aria-describedby. Wenn eine Prüfung einen Fehler festgestellt hat, zeigt aria-invalid="true" den ungültigen Zustand an. Die Fehlermeldung muss sichtbar erklären, was zu korrigieren ist. W3C beschreibt die Zuordnung von Fehlertexten.
<label for="contact">E-Mail-Adresse (Pflichtfeld)</label>
<p id="contact-hint">Wir antworten an diese Adresse.</p>
<input id="contact" name="email" type="email" autocomplete="email"
required value="anna" aria-invalid="true" aria-describedby="contact-hint contact-error">
<p id="contact-error">Bitte ergänze die Domain, zum Beispiel name@example.org.</p>
Dieser Ausschnitt zeigt einen bereits erkannten Fehler. Setze den Fehlerzustand nicht vorsorglich beim ersten Laden und entferne oder aktualisiere ihn nach der Korrektur. aria-describedby macht den Text zu einer Beschreibung; es garantiert keine sofortige Ansage bei jeder dynamischen Änderung. Prüfe den tatsächlichen Ablauf mit einem Screenreader. Eine Fehlerübersicht, gezielte Fokusführung oder eine passende Live-Region können je nach Ablauf erforderlich sein.
Wie Du die Rückmeldung nach dem Absenden gestaltest, kannst Du im Beitrag Fehlermeldungen in Formularen verständlich und barrierefrei gestalten mit zwei interaktiven Formularen ausprobieren.
So prüfst Du das vollständige Formular
- Fülle die Felder aus. Bleiben Labels, Pflichtfeldhinweise und Formatvorgaben verständlich? Prüfe auch die automatisch ausgefüllte Fassung.
- Klicke auf jedes sichtbare Label. Erreicht es das richtige Feld, auch wenn dieselbe Komponente mehrfach vorkommt?
- Gehe mit Tab und Umschalt+Tab durch den Ablauf. Prüfe sichtbaren Fokus, sinnvolle Reihenfolge und die Bedienung aller Schaltflächen.
- Kontrolliere im Accessibility Tree des Browsers den Namen jedes Feldes. Gleiche ihn mit dem sichtbaren Zweck ab. Ein vorhandener Name kann inhaltlich falsch sein.
- Teste mit dem Screenreader eine leere, ausgefüllte und fehlerhafte Abgabe. Sind Label, Hinweise und Fehler an der richtigen Stelle verständlich? Bleiben Eingaben bei einer Korrektur erhalten?
- Scanne erneut nach dem Öffnen zusätzlicher Felder und nach Validierungsfehlern. Dokumentiere erreichte Zustände und manuelle Ergebnisse getrennt.
Die Browser-Prüfung unserer Ausschnitte ersetzt keinen Screenreader-Test des fertigen Formulars. Prüfe außerdem Rahmen und Auswahlzustände, Textvergrößerung und mobile Darstellung. Für CAPTCHA und Sicherheitsabfragen nutze den Leitfaden zu Pop-ups und CAPTCHAs: Eine Rechenaufgabe ist keine allgemeingültige barrierefreie Alternative zu einem Bildrätsel. WCAG 3.3.8 begrenzt kognitive Funktionstests bei der Anmeldung und nennt Ausnahmen und unterstützende Mechanismen.
Der WCAG-Hub mit kompaktem Label-Beispiel ordnet die weiteren Prüfbereiche ein. Mit dem navable Audit kannst Du maschinell prüfbare Befunde sammeln und nach einer Korrektur erneut prüfen. Die Bewertung von Verständlichkeit und der gesamte Eingabeablauf brauchen zusätzliche manuelle Tests.