WCAG 1.3.5: Eingabezweck identifizieren

Was diese Regel bedeutet

WCAG 1.3.5 — Identify Input Purpose ist ein Kriterium der Stufe AA, das in WCAG 2.1 eingeführt und in WCAG 2.2 fortgeführt wurde. Es verlangt, dass jedes <input>-, <select>- oder <textarea>-Element, das Informationen über die Nutzerin oder den Nutzer sammelt, seinen Zweck programmatisch kommuniziert, sodass Browser und unterstützende Technologien diesen Zweck automatisch erkennen und entsprechend handeln können.

Der Mechanismus zur Erfüllung dieses Kriteriums ist das Attribut autocomplete in Kombination mit dem korrekten Token-Wert aus der offiziellen Liste, die in der HTML-Spezifikation definiert ist. Wenn ein Feld den Namen, die E-Mail-Adresse, Telefonnummer, Postanschrift, Kreditkartennummer oder ähnliche personenbezogene Daten einer Nutzerin oder eines Nutzers erfasst, muss das Attribut autocomplete einen Wert tragen, der den Zweck dieses Feldes genau beschreibt — zum Beispiel autocomplete="given-name" für ein Vornamenfeld oder autocomplete="email" für ein E-Mail-Feld.

Das Kriterium gilt speziell für Eingaben, die Informationen über die Nutzerin oder den Nutzer selbst erfassen. Es gilt nicht für Felder, in denen eine Nutzerin oder ein Nutzer Daten über eine andere Person eingibt (zum Beispiel ein Reisebuchungsformular, das nach dem Namen der reisenden Person fragt, wenn die Buchung im Auftrag einer anderen Person erfolgt), und es gilt auch nicht für Felder, bei denen Autovervollständigung ein Sicherheitsrisiko darstellen würde — etwa Einmalpasswörter oder CAPTCHA-ähnliche Herausforderungen, die legitim autocomplete="off" oder autocomplete="one-time-code" verwenden können.

Ein „Pass“ erfordert, dass: (1) jedes Feld im Geltungsbereich ein autocomplete-Attribut trägt und (2) der Wert dieses Attributs ein gültiger, anerkannter Token aus der HTML-Autofill-Spezifikation ist — kein beliebiger String, kein leerer Wert, wenn ein sinnvoller erforderlich ist, und kein falsch geschriebener Token. Ein „Fail“ tritt ein, wenn ein Feld im Geltungsbereich kein autocomplete-Attribut hat, autocomplete="off" ohne Rechtfertigung verwendet oder einen ungültigen Token wie autocomplete="firstname" (der korrekte Token ist given-name) oder autocomplete="phone" (der korrekte Token ist tel) trägt.

Die vollständige Liste gültiger Autocomplete-Tokens wird vom WHATWG HTML Living Standard gepflegt und umfasst Werte für Namen (given-name, family-name, additional-name), Adressen (street-address, address-line1, postal-code, country-name), Kontaktinformationen (email, tel, tel-national), Zugangsdaten (username, current-password, new-password), Zahlungsdetails (cc-name, cc-number, cc-exp, cc-csc) und mehr. Tokens können außerdem mit Abschnittskennungen (z. B. section-billing) sowie Versand- oder Rechnungs-Schlüsselwörtern versehen werden, um mehrere Adressgruppen auf einer Seite zu handhaben.

Warum das wichtig ist

Dieses Kriterium dient in erster Linie Nutzerinnen und Nutzern mit kognitiven Beeinträchtigungen, darunter Menschen mit Dyslexie, Gedächtnisbeeinträchtigungen, Aufmerksamkeitsdefiziten und Lernschwierigkeiten. Für diese Personen kann das korrekte Ausfüllen eines komplexen Checkout-Formulars — mit getrennten Feldern für Vorname, Nachname, Straße, Stadt, Postleitzahl, Telefon und Zahlungsdetails — eine erhebliche kognitive Belastung darstellen. Wenn autocomplete-Tokens korrekt sind, können Browser die Felder mit einem einzigen Schritt aus dem gespeicherten Profil der Nutzerin oder des Nutzers vorausfüllen, was Reibung und Fehlerrisiko drastisch reduziert.

Nutzerinnen und Nutzer mit motorischen Beeinträchtigungen — darunter Menschen mit eingeschränkter Handfunktion, die Schaltersteuerung, Blickverfolgungssoftware oder Saug-Blas-Geräte verwenden — profitieren gleichermaßen. Tippen ist für diese Personen langsam, anstrengend und manchmal schmerzhaft. Zuverlässig funktionierendes Autofill kann eine zehnminütige Tortur in eine nahezu sofortige Aufgabe verwandeln. Laut Weltgesundheitsorganisation leben weltweit etwa 1,3 Milliarden Menschen mit einer Form signifikanter Behinderung, und motorische Beeinträchtigungen, die die Feinmotorik der Hände betreffen, gehören zu den häufigsten.

Über die Autovervollständigung hinaus ermöglichen korrekte autocomplete-Tokens Browsern und unterstützenden Technologien, benutzerdefinierte Symbole, Beschriftungen oder erweiterte Eingabeschnittstellen bereitzustellen — zum Beispiel automatisch eine Telefontastatur für ein tel-Feld auf einem Mobilgerät anzuzeigen oder eine Kreditkartengrafik für ein cc-number-Feld. Passwortmanager, die für Menschen mit Gedächtnisbeeinträchtigungen ein kritisches Hilfsmittel sind, sind ebenfalls auf diese Tokens angewiesen, um Anmeldefelder korrekt zu erkennen und auszufüllen.

Betrachten wir ein Szenario aus der Praxis: Eine Nutzerin oder ein Nutzer mit Zerebralparese füllt einen Antrag auf staatliche Leistungen aus. Das Formular enthält zwölf Felder zu Name, Adresse, nationaler ID und Kontaktdaten. Ohne korrekte autocomplete-Werte muss jedes Feld manuell eingegeben werden. Ein einziger falsch geschriebener Token — etwa autocomplete="surname" statt autocomplete="family-name" — reicht aus, um zu verhindern, dass der Browser das Feld erkennt, sodass die Person ihren Nachnamen Zeichen für Zeichen eingeben muss. Mit korrekten Tokens kann das gesamte Formular in Sekunden automatisch ausgefüllt werden, was sowohl den Aufwand als auch die Fehlerrate reduziert.

Es gibt auch Vorteile für Benutzerfreundlichkeit und Conversion-Rate auf Seiten der Organisationen: Studien zeigen konsistent, dass formularbasierte Prozesse mit Autofill-Unterstützung geringere Abbruchraten und höhere Abschlussraten aufweisen. Das Beheben von Autocomplete-Tokens ist daher nicht nur eine Verbesserung der Barrierefreiheit, sondern auch eine direkte geschäftliche Verbesserung.

Verwandte Axe-core-Regeln

• autocomplete-valid — Dies ist die primäre axe-core-Regel für WCAG 1.3.5. Sie untersucht jedes <input>-, <select>- und <textarea>-Element, das ein autocomplete-Attribut besitzt, und prüft, ob der Attributwert ein anerkannter, gültiger Token aus der HTML-Autofill-Spezifikation ist. Die Regel markiert Elemente, bei denen der Token falsch geschrieben ist (z. B. given name mit einem Leerzeichen statt eines Bindestrichs), bei denen ein nicht standardisierter proprietärer Wert verwendet wurde (z. B. autocomplete="first-name") oder bei denen die Token-Reihenfolge in einem Multi-Token-Wert falsch ist (z. B. wenn ein Feldname vor einem erforderlichen Abschnittspräfix steht). Die Regel markiert Felder nicht, denen das autocomplete-Attribut vollständig fehlt — diese Situation erfordert eine manuelle Prüfung —, da axe-core nicht programmatisch bestimmen kann, ob ein bestimmtes Feld in den Geltungsbereich des Kriteriums fällt (d. h. ob es Informationen über die Nutzerin oder den Nutzer sammelt).
• Warum auch manuelle Tests erforderlich sind — Automatisierte Werkzeuge wie axe-core können nur validieren, dass ein vorhandener autocomplete-Wert syntaktisch korrekt ist; sie können nicht feststellen, ob der gewählte Token den Zweck des Feldes korrekt beschreibt. Ein Feld für eine Rechnungs-Telefonnummer mit autocomplete="email" würde die automatisierte Regel bestehen (da email ein gültiger Token ist), aber das Kriterium verfehlen, weil der Token nicht dem tatsächlichen Zweck des Feldes entspricht. Ebenso können automatisierte Werkzeuge keine Felder identifizieren, denen ein autocomplete-Attribut fehlt, das sie haben sollten, da die Beurteilung, ob ein Feld personenbezogene Daten über die Nutzerin oder den Nutzer sammelt, menschliches Urteil auf Basis des Kontexts erfordert. Eine manuelle Überprüfung jedes Formularfeldes, das nutzerspezifische Daten sammelt, ist daher für die vollständige Einhaltung von 1.3.5 unerlässlich.

Wie man testet

1. Führen Sie einen automatisierten Scan mit axe DevTools oder Lighthouse durch. Öffnen Sie die Seite mit dem Formular in Chrome oder Firefox. Klicken Sie in axe DevTools auf „Analyze“ und filtern Sie die Ergebnisse nach der Regel-ID autocomplete-valid. Führen Sie in Lighthouse ein Accessibility-Audit durch und suchen Sie nach Verstößen, die sich auf Autocomplete beziehen. Notieren Sie jedes markierte Element und protokollieren Sie die gemeldeten ungültigen Token-Werte. Beheben Sie jedes markierte Element und scannen Sie erneut, um die Korrektur zu bestätigen.
2. Identifizieren Sie manuell alle Eingabefelder im Geltungsbereich. Überprüfen Sie das Formular und listen Sie jedes Feld auf, das Informationen über die aktuelle Nutzerin oder den aktuellen Nutzer sammelt — Namensfelder, Adressfelder, E-Mail, Telefon, Zahlungsdetails, Zugangsdaten. Vergewissern Sie sich für jedes Feld, dass ein autocomplete-Attribut vorhanden ist und dass sein Token dem tatsächlichen Zweck des Feldes gemäß der HTML-Autofill-Tokenliste entspricht. Felder, die Informationen über andere Personen sammeln, liegen außerhalb des Geltungsbereichs und können ausgeschlossen werden.
3. Testen Sie das Autofill-Verhalten des Browsers. Stellen Sie in Chrome oder Firefox sicher, dass der Browser ein gespeichertes Profil hat (Einstellungen > Autofill). Navigieren Sie zur Formularseite und klicken Sie in das erste Feld mit personenbezogenen Informationen. Bestätigen Sie, dass der Browser einen Autofill-Vorschlag anzeigt und dass die Auswahl dieses Vorschlags die richtigen Felder mit den richtigen Werten ausfüllt. Wiederholen Sie dies für Adressfelder, Zahlungsfelder und Felder für Zugangsdaten. Wenn Autofill keine Werte vorschlägt oder die falschen Felder ausfüllt, sind die Autocomplete-Tokens wahrscheinlich falsch.
4. Testen Sie mit einer Kombination aus Screenreader und Browser. Navigieren Sie mit NVDA und Firefox mit der Tabulatortaste zu jedem Formularfeld. NVDA sollte die Beschriftung und den Zweck des Feldes ansagen; einige Screenreader- und Browser-Kombinationen geben auch den Autocomplete-Zweck aus. Navigieren Sie mit VoiceOver unter macOS (Safari) mit Tab durch die Felder und achten Sie darauf, dass VoiceOver die Verfügbarkeit von Autofill ansagt. Navigieren Sie mit JAWS und Chrome ebenfalls per Tab durch die Felder und bestätigen Sie, dass JAWS den erwarteten Feldkontext ansagt. Auch wenn Screenreader Autocomplete-Tokens nicht immer explizit ansagen, bestätigt die Kombination aus funktionierendem Autofill und Tastaturnavigation, dass der programmatische Zweck offengelegt wird.
5. Untersuchen Sie die Autocomplete-Attribute in den Browser-DevTools. Klicken Sie mit der rechten Maustaste auf jedes Formularfeld und wählen Sie „Inspect“. Bestätigen Sie im Elements-Panel, dass das autocomplete-Attribut vorhanden ist und dass sein Wert exakt einem gültigen Token entspricht. Achten Sie besonders auf Multi-Token-Werte — zum Beispiel autocomplete="shipping street-address" — und bestätigen Sie, dass die Token-Reihenfolge der Spezifikation folgt (Abschnittsname, dann „shipping“ oder „billing“, dann Feldname).

Wie man es behebt

Namensfelder — Falsch

<!-- Invalid: uses non-standard token 'firstname' instead of 'given-name' -->
<label for='fname'>First Name</label>
<input type='text' id='fname' name='first_name' autocomplete='firstname'>

<label for='lname'>Last Name</label>
<input type='text' id='lname' name='last_name' autocomplete='surname'>

Namensfelder — Korrekt

<!-- Valid: uses the exact WHATWG-specified tokens 'given-name' and 'family-name' -->
<label for='fname'>First Name</label>
<input type='text' id='fname' name='first_name' autocomplete='given-name'>

<label for='lname'>Last Name</label>
<input type='text' id='lname' name='last_name' autocomplete='family-name'>

Adressformular mit Rechnungs- und Versandabschnitt — Falsch

<!-- Invalid: missing autocomplete attributes entirely on address fields -->
<fieldset>
  <legend>Billing Address</legend>
  <input type='text' name='bill_street' placeholder='Street Address'>
  <input type='text' name='bill_city' placeholder='City'>
  <input type='text' name='bill_postal' placeholder='Postal Code'>
</fieldset>

Adressformular mit Rechnungs- und Versandabschnitt — Korrekt

<!-- Valid: autocomplete tokens include 'billing' prefix and correct field names -->
<fieldset>
  <legend>Billing Address</legend>
  <input type='text' name='bill_street' autocomplete='billing street-address' placeholder='Street Address'>
  <input type='text' name='bill_city' autocomplete='billing address-level2' placeholder='City'>
  <input type='text' name='bill_postal' autocomplete='billing postal-code' placeholder='Postal Code'>
</fieldset>

Telefonfeld — Falsch

<!-- Invalid: uses 'phone' which is not a recognized autocomplete token -->
<label for='tel'>Phone Number</label>
<input type='text' id='tel' name='telephone' autocomplete='phone'>

Telefonfeld — Korrekt

<!-- Valid: 'tel' is the correct autocomplete token for a full phone number -->
<label for='tel'>Phone Number</label>
<input type='tel' id='tel' name='telephone' autocomplete='tel'>

Login-Daten — Falsch

<!-- Invalid: autocomplete='off' prevents password managers and autofill from working -->
<label for='user'>Username</label>
<input type='text' id='user' name='username' autocomplete='off'>

<label for='pass'>Password</label>
<input type='password' id='pass' name='password' autocomplete='off'>

Login-Daten — Korrekt

<!-- Valid: 'username' and 'current-password' allow password managers to function correctly -->
<label for='user'>Username</label>
<input type='text' id='user' name='username' autocomplete='username'>

<label for='pass'>Password</label>
<input type='password' id='pass' name='password' autocomplete='current-password'>

Häufige Fehler

• Verwendung von autocomplete="firstname" oder autocomplete="first-name" statt des korrekten Tokens given-name". Diese nicht standardisierten Werte werden von Browsern oder unterstützenden Technologien nicht erkannt, auch wenn sie logisch erscheinen. Verwenden Sie immer die exakten Tokens aus der HTML-Autofill-Spezifikation.
• Verwendung von autocomplete="phone" statt autocomplete="tel". Das Wort „phone“ ist kein gültiger Token. Die Spezifikation verwendet tel für eine vollständige Telefonnummer sowie tel-national, tel-area-code, tel-local für Teilbereiche einer Telefonnummer.
• Setzen von autocomplete="off" auf Feldern für Zugangsdaten als fehlgeleitete Sicherheitsmaßnahme. Moderne Browser und die WCAG-Spezifikation erkennen gleichermaßen an, dass das Verhindern von Autofill in Login-Formularen für Menschen mit Behinderungen echte Barrieren schafft und die Sicherheit nicht nennenswert verbessert. Verwenden Sie stattdessen autocomplete="username" und autocomplete="current-password".
• Das autocomplete-Attribut auf Feldern mit personenbezogenen Daten vollständig weglassen, in der Annahme, der Browser werde den Zweck aus Feldname oder Beschriftung ableiten. Browser verwenden Heuristiken, um den Zweck eines Feldes zu erraten, aber diese sind unzuverlässig und zwischen Browsern uneinheitlich. Explizite Tokens sind für eine garantierte, barrierefreie Erfahrung erforderlich.
• Verwendung von autocomplete="address" statt der spezifischen Adress-Subtokens. Es gibt keinen address-Token in der Spezifikation. Sie müssen street-address, address-line1, address-line2, address-level1 (Bundesland/Provinz), address-level2 (Stadt) und postal-code einzeln verwenden.
• Platzierung von Versand- oder Rechnungs-Schlüsselwörtern in der falschen Reihenfolge in Multi-Token-Werten. Die korrekte Reihenfolge lautet: optionales Abschnittspräfix (z. B. section-billing), dann optionales Versand-/Rechnungs-Schlüsselwort, dann der Feldname-Token. autocomplete="street-address billing" ist ungültig; die korrekte Form ist autocomplete="billing street-address".
• Anwendung von autocomplete nur auf sichtbare Felder und Ignorieren versteckter oder dynamisch eingeblendeter Felder. Felder, die zunächst verborgen sind, aber durch Nutzerinteraktion eingeblendet werden (z. B. zusätzliche Adresszeilen oder optionale Felder), müssen ebenfalls korrekte Autocomplete-Tokens tragen, sobald sie aktiv werden.
• Verwendung von JavaScript, um das autocomplete-Attribut nach dem Laden der Seite dynamisch zu entfernen oder zu überschreiben. Einige Formularbibliotheken oder UI-Frameworks setzen Eingabeattribute zurück, wenn Komponenten gemountet oder neu gerendert werden, und entfernen dabei unbeabsichtigt Autocomplete-Tokens. Vergewissern Sie sich immer, dass das Attribut im Live-DOM nach Ausführung aller JavaScript-Codepfade bestehen bleibt.
• Die Annahme, dass type="email" oder type="tel" bei einem Eingabefeld ausreicht, um den Zweck ohne autocomplete zu kommunizieren. Während type einige Informationen liefert, ist das Attribut autocomplete ein separates, explizites Signal, das von WCAG 1.3.5 gefordert wird und von Browsern und unterstützenden Technologien unterschiedlich genutzt wird.
• Verwendung desselben autocomplete-Tokens für zwei verschiedene Felder, die unterschiedliche Daten erfassen. Wenn beispielsweise sowohl ein Feld für die geschäftliche E-Mail-Adresse als auch ein Feld für die private E-Mail-Adresse mit autocomplete="email" versehen werden, verwirrt dies Browser und kann zu falscher Autovervollständigung führen. Verwenden Sie Abschnittspräfixe (z. B. section-work email vs. section-personal email), um dies zu vermeiden.

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 Barrierefreiheitsanforderungen für eine breite Palette von Organisationen fest, die in der Türkei tätig sind. Die Verfügung schreibt die Konformität mit WCAG 2.2 auf Stufe AA als Mindeststandard für digitale Dienste vor, was WCAG 1.3.5 — Identify Input Purpose — direkt einschließt.

Die von der Verfügung erfassten Organisationstypen sind breit gefächert. Öffentliche Institutionen und Regierungsbehörden müssen diese Standards für alle bürgerorientierten digitalen Dienste erfüllen. Zu den erfassten privaten Organisationen gehören E-Commerce-Plattformen, Banken und Finanzdienstleister, Krankenhäuser und Gesundheitsdienstleister, Telekommunikationsanbieter mit 200.000 oder mehr Abonnentinnen und Abonnenten, lizenzierte Reisebüros, private Personenverkehrsunternehmen und private Bildungseinrichtungen, die vom Bildungsministerium (MoNE) autorisiert sind. In der Praxis bedeutet dies, dass nahezu jedes große verbraucherorientierte digitale Produkt in der Türkei — von Banking-Apps über Online-Retail-Checkouts bis hin zu Portalen für Gesundheits­termine — korrekt implementierte autocomplete-Tokens auf allen Eingabefeldern für personenbezogene Daten haben muss.

Für WCAG 1.3.5 bedeutet dies konkret, dass jedes türkische E-Commerce-Checkout-Formular, Formular zur Kontoeröffnung bei einer Bank, Formular zur Patientenregistrierung in einem Krankenhaus oder Formular für einen Telekommunikationsvertrag, das Nutzerinformationen wie Name, Adresse, Telefonnummer oder Zahlungsdetails erfasst, gültige autocomplete-Attributwerte in jedem relevanten Eingabefeld enthalten muss. Die Nichteinhaltung stellt eine Nichtkonformität auf Stufe AA dar und kann verhindern, dass eine Organisation das Accessibility Logo (Erişilebilirlik Logosu) erhält oder behält — das offizielle Zeichen, das vom Ministerium für Familie und Sozialdienste vergeben wird und bestätigt, dass die digitalen Dienste einer Organisation die Barrierefreiheitsstandards erfüllen.

Das Accessibility Logo hat sowohl reputationsbezogene als auch regulatorische Bedeutung, und Organisationen in wettbewerbsintensiven Verbrauchermärkten — wie E-Commerce und Banken — haben starke Anreize, es zu erlangen und zu behalten. Da WCAG 1.3.5 einfach umzusetzen ist (das Hinzufügen oder Korrigieren von autocomplete-Attributwerten erfordert keine architektonischen Änderungen) und gleichzeitig erheblichen Nutzen für Menschen mit kognitiven und motorischen Beeinträchtigungen bietet, gehört es zu den wertvollsten und zugleich am wenigsten aufwendigen Barrierefreiheitsverbesserungen, die eine Organisation im Rahmen der angestrebten vollständigen Konformität mit Stufe AA nach der Verfügung 2025/10 vornehmen kann.

Organisationen sollten alle Formulare auf ihren digitalen Angeboten — einschließlich mobiler Weboberflächen und responsiver Layouts — prüfen und eine Entwicklungsrichtlinie etablieren, die korrekte autocomplete-Tokens als Standardbestandteil jeder Formularimplementierung vorschreibt. Dies sollte durch automatisierte Tests in CI/CD-Pipelines mit Werkzeugen wie axe-core durchgesetzt werden, damit Regressionen erkannt werden, bevor sie in die Produktion gelangen.