WCAG 3.3.2: Beschriftungen oder Anweisungen

WCAG 3.3.2 verlangt, dass Beschriftungen oder Anweisungen bereitgestellt werden, wenn Inhalte eine Eingabe durch die Nutzer erfordern, um sicherzustellen, dass alle Nutzer – unabhängig von ihren Fähigkeiten – verstehen können, was von ihnen erwartet wird, bevor sie Formulardaten absenden. Das Versäumnis, Formularfelder zu beschriften, ist eine der häufigsten und folgenreichsten Barrieren für Barrierefreiheit im Web.

Was diese Regel bedeutet

Das WCAG-Erfolgskriterium 3.3.2 — Beschriftungen oder Anweisungen (Level A) besagt: „Beschriftungen oder Anweisungen werden bereitgestellt, wenn Inhalte eine Eingabe durch den Benutzer erfordern.“ Praktisch bedeutet das: Jedes Formularfeld, jedes Eingabesteuerelement, jedes Textfeld und jedes Auswahl-Element, das von einem Benutzer verlangt, Informationen einzugeben oder auszuwählen, muss eine sichtbare, aussagekräftige Beschriftung oder eine Reihe von Anweisungen haben, die den Zweck des Feldes klar machen, bevor der Benutzer damit interagiert.

Das Kriterium ist bewusst breit gefasst. Es umfasst jeden Mechanismus, über den ein Benutzer Daten bereitstellt: <input>-Elemente aller Typen (text, email, password, number, date, checkbox, radio, file upload), <textarea>-Elemente für mehrzeiligen Text und <select>-Dropdowns. Es gilt auch für benutzerdefinierte interaktive Steuerelemente, die mit ARIA-Rollen wie role='combobox' oder role='listbox' erstellt wurden.

Eine Beschriftung kann auf mehrere Arten bereitgestellt werden, die dieses Kriterium erfüllen. Am robustesten ist ein programmatisch verknüpftes <label>-Element, das visuell vorhanden ist und über ein übereinstimmendes for/id-Paar mit dem Steuerelement verbunden ist. Alternativ kann ein sichtbarer Beschriftungstext mit aria-labelledby einem vorhandenen Element zugeordnet werden, oder ergänzende Anweisungen können mit aria-describedby verknüpft werden. Die zentrale Anforderung ist, dass die Beschriftung oder Anweisung bereitgestellt wird – sie muss in einer Form existieren, die der Benutzer wahrnehmen kann. Platzhaltertext allein erfüllt dieses Kriterium nicht, da er verschwindet, sobald der Benutzer zu tippen beginnt, und nicht von allen unterstützenden Technologien zuverlässig als persistente Beschriftung vermittelt wird.

Ein Bestanden setzt voraus, dass jede Eingabe eine Beschriftung hat, die sichtbar ist (oder mindestens programmatisch ermittelbar), vorhanden ist, bevor der Benutzer das Feld ausfüllt, und ausreichend beschreibend ist, um zu vermitteln, welche Daten erwartet werden. Ein Nicht bestanden liegt vor, wenn ein Feld überhaupt keine Beschriftung hat, wenn der einzige „Label“-Text ein Platzhalter-Attribut ist, wenn die Beschriftung zwar visuell vorhanden, aber nicht programmatisch verknüpft ist, oder wenn Anweisungen zum erforderlichen Format (z. B. „Datum im Format TT/MM/JJJJ eingeben“) vollständig fehlen.

Die WCAG nennt eine enge Ausnahme: Wenn ein Formular nur ein einziges, offensichtliches Feld enthält – etwa eine seitenweite Suchleiste mit einem klar beschrifteten Senden-Button direkt daneben – kann der Kontext selbst ausreichende Anweisungen liefern. Diese Ausnahme ist jedoch eng gefasst und sollte nicht als allgemeine Rechtfertigung dafür dienen, Beschriftungen in Formularen mit mehreren Feldern wegzulassen.

Warum das wichtig ist

Formularbeschriftungen sind das mit Abstand wirkungsvollste Barrierefreiheitsmerkmal für ein breites Spektrum von Nutzern. Ihr Fehlen schafft Barrieren, die es vielen Menschen unmöglich machen können, Transaktionen abzuschließen, sich für Dienste zu registrieren oder eine Organisation zu kontaktieren.

Für blinde und sehbehinderte Nutzer, die auf Screenreader angewiesen sind, wird ein unbeschriftetes Feld einfach als „edit text“ oder „blank“ ohne Kontext angesagt. Der Nutzer hat keine Möglichkeit zu wissen, ob er seinen Namen, seine E‑Mail-Adresse oder seine Kreditkartennummer eingeben soll. Laut Weltgesundheitsorganisation haben weltweit etwa 2,2 Milliarden Menschen irgendeine Form von Sehbeeinträchtigung, und Millionen von ihnen nutzen Screenreader als primäres Mittel zur Interaktion mit dem Web.

Für Nutzer mit kognitiven und Lernbehinderungen – einschließlich Dyslexie, ADHS und gedächtnisbezogenen Beeinträchtigungen – ist Platzhaltertext besonders problematisch. Da Platzhalter bei Fokus oder Eingabe verschwinden, hat ein Nutzer, der mitten im Formular innehält, keine Referenz mehr dafür, was in einem Feld erwartet wurde, das er bereits zu ausfüllen begonnen hat. Er ist gezwungen, das Feld zu leeren, um die Anweisung erneut zu lesen, was zu Verwirrung und Frustration führt. Persistente, sichtbare Beschriftungen beseitigen diese kognitive Belastung vollständig.

Für motorisch beeinträchtigte Nutzer, die per Tastatur, Schaltgerät oder Sprachsteuerung navigieren, erfüllen Beschriftungen eine zusätzliche Funktion: Sie liefern die gesprochenen Wörter, mit denen ein Feld über Sprachsteuerungssoftware wie Dragon NaturallySpeaking aktiviert wird. Wenn der sichtbare Beschriftungstext nicht mit dem programmatischen zugänglichen Namen übereinstimmt, schlägt der Sprachbefehl stillschweigend fehl.

Betrachten wir ein konkretes Szenario aus der Praxis: Eine Nutzerin mit Sehbehinderung beantragt eine staatliche Leistung über das Portal einer türkischen öffentlichen Institution. Das Formular verwendet Platzhaltertext statt Beschriftungen. Wenn die Nutzerin auf 200 % zoomt, um den Bildschirm lesen zu können, verschwinden die Platzhalter, bevor sie gelesen werden können. Die Nutzerin füllt die Felder durch Raten aus und sendet ein Formular mit Fehlern ab, erhält jedoch nur eine generische Fehlermeldung ohne Hinweis darauf, welche Felder falsch sind. Dieses Szenario führt zum Ausschluss von einem kritischen öffentlichen Dienst – und ist vollständig vermeidbar.

Über die Barrierefreiheit hinaus verbessern beschriftete Formulare die SEO, weil Suchmaschinen-Crawler den Zweck von Formularen besser verstehen können, und sie verbessern die Benutzbarkeit für alle Nutzer, einschließlich derjenigen auf Mobilgeräten, bei denen kleine Touch-Ziele von antippbaren Beschriftungsbereichen profitieren, die die Aktivierungszone des zugehörigen Eingabefelds vergrößern.

Wie man testet

Automatischer Scan mit axe DevTools oder Lighthouse: Öffnen Sie die Seite mit dem Formular in Chrome oder Firefox. Führen Sie die axe DevTools Browser-Erweiterung aus und filtern Sie die Ergebnisse nach den Regeln label, select-name und textarea-label. Notieren Sie jedes markierte Element. Führen Sie Google Lighthouse (Accessibility Audit) als sekundäre Prüfung aus. Exportieren oder fotografieren Sie alle Verstöße. Denken Sie daran, dass ein sauberer automatisierter Bericht keine Konformität garantiert – fahren Sie mit den manuellen Schritten fort.
Visuelle Inspektion: Überprüfen Sie ohne Einsatz unterstützender Technologien jedes Formularfeld auf der Seite. Stellen Sie sicher, dass jedes Feld eine sichtbare, statische Beschriftung hat – nicht nur einen Platzhalter – die klar in der Nähe des Feldes positioniert ist (typischerweise darüber oder links davon). Stellen Sie sicher, dass Format-Anforderungen (z. B. „Passwort muss mindestens 8 Zeichen lang sein“) vor oder zum Zeitpunkt der Eingabe angezeigt werden, nicht erst nach einer fehlgeschlagenen Übermittlung. Stellen Sie sicher, dass Pflichtfelder nicht nur durch Farbe gekennzeichnet sind.
Tastaturnavigationstest: Navigieren Sie mit der Tabulatortaste durch jedes Formularfeld. Stellen Sie sicher, dass der Zweck jedes Feldes, sobald es den Fokus erhält, aus der sichtbaren Beschriftung sofort ersichtlich ist. Kein Feld sollte per Tastatur erreichbar sein, ohne dass in diesem Moment eine angrenzende, persistente Beschriftung sichtbar ist.
Screenreader-Test mit NVDA und Firefox: Öffnen Sie das Formular mit laufendem NVDA. Drücken Sie Tab, um durch jedes interaktive Steuerelement zu wechseln. NVDA sollte die Beschriftung, die Rolle (z. B. „edit“, „combo box“) und jeden Zustand (z. B. „required“) ansagen. Wenn NVDA nur Rolle und Zustand ohne Beschriftung ansagt, fällt das Feld durch. Verwenden Sie den Formularmodus von NVDA (wird bei interaktiven Elementen automatisch ausgelöst), um eine realistische Benutzernavigation zu simulieren.
Screenreader-Test mit VoiceOver und Safari (macOS/iOS): Aktivieren Sie VoiceOver (Command + F5 auf dem Mac). Verwenden Sie Tab oder Wischgesten, um zu jedem Formularfeld zu navigieren. VoiceOver sollte die Beschriftung vor der Rolle ansagen. Tippen Sie auf iOS auf jedes Feld und stellen Sie sicher, dass die Beschriftung vorgelesen wird, bevor die Tastatur erscheint. Felder, die nur Platzhalter verwenden, werden beim ersten Fokus typischerweise mit dem Platzhalter vorgelesen, sind aber stumm, sobald Text eingegeben wurde.
Screenreader-Test mit JAWS und Chrome: Starten Sie JAWS und navigieren Sie mit Tab durch das Formular. Verwenden Sie den Formularmodus von JAWS. Stellen Sie sicher, dass der angesagte Name jedes Feldes exakt seiner sichtbaren Beschriftung entspricht. Verwenden Sie Insert + F1 (Feldhilfe) in JAWS, um zusätzliche Beschreibungen über aria-describedby zu prüfen.
Sprachsteuerungstest mit Dragon NaturallySpeaking: Aktivieren Sie Dragon und versuchen Sie, mit jedem Feld zu interagieren, indem Sie seine sichtbare Beschriftung aussprechen. Wenn die gesprochene Beschriftung nicht mit dem programmatischen zugänglichen Namen übereinstimmt, reagiert das Feld nicht auf den Sprachbefehl, was auf eine Diskrepanz hinweist, die sowohl 3.3.2 als auch verwandte Kriterien verletzt.

Wie man es behebt

Fehlende Beschriftung bei einer Texteingabe — Falsch

<!-- No label provided; placeholder is the only hint -->
<input type='text' name='email' placeholder='Email address' />

Fehlende Beschriftung bei einer Texteingabe — Richtig

<!-- Visible <label> associated via matching for/id attributes.
     Placeholder may still be used as supplementary hint,
     but the label is the primary, persistent identifier. -->
<label for='email'>Email address</label>
<input type='text' id='email' name='email' placeholder='[email protected]' />

Unbeschriftetes Select-Dropdown — Falsch

<!-- No label; screen readers will only announce the selected option value -->
<select name='city'>
  <option value=''>Select a city</option>
  <option value='istanbul'>Istanbul</option>
  <option value='ankara'>Ankara</option>
</select>

Unbeschriftetes Select-Dropdown — Richtig

<!-- Programmatically associated label makes the field's purpose clear
     before the user opens the dropdown. -->
<label for='city'>City</label>
<select id='city' name='city'>
  <option value=''>Select a city</option>
  <option value='istanbul'>Istanbul</option>
  <option value='ankara'>Ankara</option>
</select>

Textarea ohne Beschriftung — Falsch

<!-- The textarea has no label; surrounding paragraph text is not
     programmatically associated and will not be read by screen readers
     as the field's label. -->
<p>Please describe your issue:</p>
<textarea name='message' rows='5'></textarea>

Textarea ohne Beschriftung — Richtig

<!-- Using aria-labelledby to associate the existing visible heading
     with the textarea, or alternatively wrapping with a <label> element. -->
<label for='message'>Please describe your issue</label>
<textarea id='message' name='message' rows='5'></textarea>

Fehlende Format-Anweisungen für ein Datumsfeld — Falsch

<!-- Label present but no instruction about expected date format;
     users must guess whether to enter 01/06/2025 or 2025-06-01. -->
<label for='dob'>Date of birth</label>
<input type='text' id='dob' name='dob' />

Vorhandene Format-Anweisungen für ein Datumsfeld — Richtig

<!-- Format instruction is visible and linked via aria-describedby
     so screen readers announce it when the field receives focus. -->
<label for='dob'>Date of birth</label>
<span id='dob-hint'>Enter as DD/MM/YYYY, e.g. 15/06/1990</span>
<input type='text' id='dob' name='dob' aria-describedby='dob-hint' />

Häufige Fehler

Verwendung von placeholder als einzige Beschriftung: Platzhaltertext verschwindet bei der Eingabe, wird nicht von allen Screenreadern zuverlässig als Beschriftung angesagt und ist für Nutzer mit kognitiven Beeinträchtigungen problematisch, die eine persistente Referenz benötigen. Stellen Sie immer ein sichtbares <label> zusätzlich zu jedem Platzhalter bereit.
Visuelle Positionierung einer Beschriftung in der Nähe eines Feldes ohne programmatische Verknüpfung: Ein <p> oder <span>, das visuell über einer Eingabe platziert ist, wirkt für sehende Nutzer wie eine Beschriftung, wird aber von Screenreadern ignoriert. Verwenden Sie <label for='id'>, aria-labelledby oder umschließen Sie die Eingabe mit einem <label>-Element.
Verwendung von aria-label mit Text, der nicht der sichtbaren Beschriftung entspricht: Wenn der programmatische zugängliche Name vom sichtbaren Text abweicht, können Nutzer mit Sprachsteuerung das Feld nicht aktivieren, indem sie das aussprechen, was sie auf dem Bildschirm sehen. Dies verstößt gegen SC 2.5.3 (Label in Name) und führt zudem zu Verwirrung bei Screenreader-Nutzern.
Beschriftung einer Gruppe von Optionsfeldern (Radio Buttons), aber Weglassen der Gruppenlegende: Einzelne Optionsfelder können jeweils mit ihrem Optionstext beschriftet sein, aber wenn die übergeordnete Frage (z. B. „Zahlungsmethode“) nicht über ein <fieldset> und <legend> bereitgestellt wird, hören Nutzer, die per Tastatur navigieren, jede Option isoliert, ohne zu verstehen, zwischen was sie wählen.
Kennzeichnung von Pflichtfeldern nur durch Farbe oder Sternchen ohne Erklärung: Ein Sternchen (*) neben einer Beschriftung vermittelt Screenreader-Nutzern nichts, sofern seine Bedeutung nicht erklärt wird (z. B. ein Hinweis am Anfang des Formulars: „Felder, die mit * gekennzeichnet sind, sind Pflichtfelder“) und Pflichtfelder zusätzlich das Attribut required oder aria-required='true' tragen.
Zurückhalten von Format-Anweisungen bis nach einer fehlgeschlagenen Übermittlung: Wenn Passwortregeln oder Datumsformat-Anforderungen erst in Fehlermeldungen nach der Übermittlung angezeigt werden, müssen Nutzer zunächst einen Fehler machen, bevor sie erfahren, was erwartet wird. Anweisungen müssen vor oder zum Zeitpunkt der Interaktion mit dem Feld vorhanden sein.
Ausblenden von Beschriftungen mit display:none oder visibility:hidden: Diese CSS-Eigenschaften entfernen Beschriftungen vollständig aus dem Accessibility Tree. Wenn eine Beschriftung visuell verborgen werden muss (z. B. für ein minimalistisches Design), verwenden Sie eine CSS-Klasse für visuell versteckte Elemente, die das Element im Accessibility Tree belässt, es aber außerhalb des sichtbaren Bereichs positioniert.
Verwendung des title-Attributs als einzige Beschriftung in der Annahme, es sei ausreichend: Auch wenn axe-core eine Beschriftung ausschließlich über title möglicherweise nicht markiert, erscheint das title-Attribut nur als Tooltip beim Hover und ist für reine Tastaturnutzer und Mobilnutzer unzugänglich. Es sollte als ergänzende Beschreibung, nicht als primäre Beschriftung verwendet werden.
Anwendung eines einzelnen aria-label auf ein Container-<div> in der Erwartung, dass es untergeordnete Eingaben beschriftet: ARIA-Beschriftungen auf Containerelementen werden nicht von ihren untergeordneten Formularsteuerelementen geerbt. Jedes interaktive Steuerelement muss individuell beschriftet werden.
Versäumnis, Beschriftungen nach dynamischen Inhaltsaktualisierungen erneut zu verknüpfen: Wenn Formularfelder dynamisch über JavaScript eingefügt werden (z. B. Hinzufügen einer Adresszeile), fehlen neu eingefügten Eingaben häufig die zugehörigen Beschriftungen, weil der Entwickler nur den sichtbaren Beschriftungstext als Geschwisterelement hinzugefügt hat, ohne die korrekte for/id-Verknüpfung.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

Die türkische Präsidialverfügung 2025/10, veröffentlicht im Amtsblatt Nr. 32933 am 21. Juni 2025, legt verbindliche Anforderungen an die Web-Barrierefreiheit fest, die sich an WCAG 2.2 orientieren. Das WCAG-Erfolgskriterium 3.3.2 — Beschriftungen oder Anweisungen ist eine Level-A-Anforderung, d. h. es gehört zur Basislinie der Konformität und zählt zu den am strengsten durchgesetzten Bestimmungen der Verfügung.

Die Verfügung umfasst eine breite Palette von Organisationstypen, und die Fristen für die Einhaltung unterscheiden sich je nach Sektor. Öffentliche Institutionen – einschließlich Ministerien, Gemeinden, staatlicher Behörden und öffentlich finanzierter Organisationen – müssen innerhalb von einem Jahr nach Veröffentlichung der Verfügung vollständige Level-A-Konformität erreichen. Private Sektorunternehmen im Geltungsbereich müssen innerhalb von zwei Jahren konform sein. Zu den ausdrücklich erfassten privaten Sektorunternehmen gehören E‑Commerce-Plattformen, Banken und Finanzinstitute, Krankenhäuser und private Gesundheitsdienstleister, Telekommunikationsunternehmen mit 200.000 oder mehr Abonnenten, Reisebüros, private Transportunternehmen und private Schulen, die vom Bildungsministerium (MoNE) zugelassen sind.

Für all diese Organisationen ist das Versäumnis, Formularfelder zu beschriften, nicht nur ein Usability-Mangel – es stellt eine direkte regulatorische Nichtkonformität dar. Formulare sind in allen erfassten digitalen Diensten allgegenwärtig: Bürger reichen Anträge über Regierungsportale ein, Patienten buchen Termine auf Krankenhauswebsites, Kunden schließen Käufe auf E‑Commerce-Plattformen ab, und Studierende melden sich über Schulportale an. Jeder dieser Wege ist auf Formulare angewiesen, und jedes unbeschriftete Feld in diesen Formularen ist ein nachweisbarer Verstoß gegen WCAG 3.3.2, den Prüfer dokumentieren und melden können.

Organisationen, die der Verfügung unterliegen, sollten die Einhaltung von SC 3.3.2 als Voraussetzung für jede Barrierefreiheitsprüfung oder jeden Zertifizierungsprozess behandeln. Da es sich um ein Level-A-Kriterium handelt, kann es weder aufgehoben noch aufgeschoben werden – Konformitätsansprüche, die Level-A-Punkte ausklammern, werden nicht anerkannt. Organisationen, die keine beschrifteten Eingaben in all ihren öffentlich zugänglichen Formularen nachweisen können, riskieren regulatorische Feststellungen, öffentliche Berichte über Nichtkonformität und Reputationsschäden in einem Markt, in dem digitales Vertrauen zunehmend mit inklusivem Design verknüpft ist.

Praktisch gesehen gehört die Erreichung der 3.3.2-Konformität zu den Maßnahmen mit dem geringsten Aufwand und der größten Wirkung, die eine Organisation ergreifen kann. Die Verknüpfung von Beschriftungen mit vorhandenen Formularsteuerelementen erfordert in der Regel nur geringfügige HTML-Änderungen und hat bei korrekter Implementierung keine Auswirkungen auf das visuelle Design. Für Organisationen, die das Overlay-SDK von Accsible verwenden, kann die automatisierte Erkennung fehlender Beschriftungen diese Verstöße während routinemäßiger Scans sichtbar machen und Entwicklungsteams umsetzbare Hinweise zur Behebung liefern, bevor die regulatorischen Fristen ablaufen.