WCAG 1.3.5: Eingabezweck bestimmen

WCAG 1.3.5 verlangt, dass Formularfelder, die Daten über die nutzende Person selbst erfassen, ihren Zweck maschinenlesbar angeben – im Web über das passende autocomplete-Token aus der Liste der 53 Eingabezwecke. Damit können Browser die Felder automatisch ausfüllen und Hilfsmittel sie um vertraute Symbole ergänzen.

(Englisch: Identify Input Purpose.)

Das Wichtigste in Kürze

• Nur Daten über die nutzende Person zählen. Ein Feld „Name der Empfängerin“ im Geschenkversand braucht kein Token – dort geht es um jemand anderen.
• type="email" genügt nicht. Der Eingabetyp steuert Tastatur und Validierung, den Zweck macht erst autocomplete maschinenlesbar.
• Die deutsche Adresse stolpert regelmäßig: Ort ist address-level2, das Bundesland ist address-level1 – nicht umgekehrt. Mehrere Tokens werden durch Leerzeichen getrennt: autocomplete="shipping address-line1".
• autocomplete="off" auf Personendaten ist praktisch immer ein Verstoß und wird von Browsern bei Anmeldedaten ohnehin ignoriert.
• Das Kriterium steht unter „Anpassbar“, nicht unter „Eingabehilfen“ – der ursprüngliche Zweck war Personalisierung: Hilfsmittel sollen Felder mit vertrauten Symbolen versehen können.
• Teilweise automatisch prüfbar: axe meldet ungültige Tokens über die Regel autocomplete-valid, ob das Token passt, muss ein Mensch beurteilen.
• Stufe AA, über die EN 301 549 verbindlich. Im BIK-BITV-Test heißt der Prüfschritt „1.3.5 Eingabefelder zu Nutzerdaten vermitteln den Zweck“.

Wofür ist das autocomplete-Attribut?

Der Normtext knüpft an eine feste Liste an: Der Zweck eines Eingabefeldes muss programmatisch bestimmbar sein, sofern das Feld einem der in der WCAG genannten 53 Eingabezwecke entspricht und die verwendete Technologie eine solche Auszeichnung unterstützt. Im Web ist diese Technologie HTML, und die Auszeichnung ist das autocomplete-Attribut.

Ein sichtbares Label genügt dafür nicht – es kann „Ihre Mehl-Adresse“ heißen, in Versalien stehen oder als Platzhalter im Feld liegen. Das Token dagegen ist eindeutig und für jede Software gleich lesbar:

Für mehrere Adressen in einem Formular gibt es Präfixe: shipping address-line1 und billing address-line1 unterscheiden Liefer- und Rechnungsanschrift, ohne dass sich die Tokens gegenseitig stören. Bei mehreren Kontaktangaben derselben Art hilft section-, etwa section-privat email und section-arbeit email.

Die vollständige Liste steht in der WCAG-Sektion „Input Purposes for User Interface Components“, das deutsche Prüfvorgehen im Prüfschritt „1.3.5 Eingabefelder zu Nutzerdaten vermitteln den Zweck“ des BIK-BITV-Tests.

Wen betrifft es besonders?

Menschen mit kognitiven Einschränkungen und Gedächtnisproblemen sind die Gruppe, für die das Kriterium ursprünglich geschrieben wurde. Wer sich die eigene IBAN nicht merken kann, wer bei „Geburtsdatum“ ins Grübeln über das Format gerät, wer nach dem dritten Feld den Faden verliert – für all das ist automatisches Ausfüllen keine Bequemlichkeit, sondern der Unterschied zwischen „Bestellung abgeschlossen“ und „Abbruch“.

Menschen mit motorischen Einschränkungen sparen bei einem Bestellformular gut und gern hundert Tastenanschläge. Wer per Switch oder Bildschirmtastatur schreibt, spart damit Minuten, nicht Sekunden.

Weniger bekannt ist der Personalisierungsgedanke dahinter: Das Kriterium steht im Abschnitt „Anpassbar“, weil Hilfsmittel Felder mit erkanntem Zweck um vertraute Symbole ergänzen sollen – ein Briefumschlag an der E-Mail, ein Telefonhörer an der Rufnummer. Dieser Werkzeugtyp hat sich langsamer verbreitet als gedacht, das Token ist aber die Voraussetzung dafür.

Und schließlich profitieren Nutzer von Sprachsteuerung indirekt: Ein Formular, das sich vom Browser ausfüllen lässt, muss nicht diktiert werden.

Richtig & falsch im Code

<!-- Falsch: kein Zweck erkennbar, Autofill rät -->
<label for="f1">Ihre E-Mail-Adresse</label>
<input id="f1" type="text" name="feld_1" />

<!-- Richtig: Typ und Zweck maschinenlesbar -->
<label for="email">Ihre E-Mail-Adresse</label>
<input id="email" type="email" name="email" autocomplete="email" />

<!-- Falsch: erfundenes Token – ungültig, axe schlägt an -->
<input id="vorname" autocomplete="firstname" />

<!-- Richtig -->
<input id="vorname" autocomplete="given-name" />

<!-- Richtig: Liefer- und Rechnungsadresse sauber getrennt -->
<input id="l-strasse" autocomplete="shipping address-line1" />
<input id="l-plz"     autocomplete="shipping postal-code" />
<input id="l-ort"     autocomplete="shipping address-level2" />

<input id="r-strasse" autocomplete="billing address-line1" />
<input id="r-plz"     autocomplete="billing postal-code" />
<input id="r-ort"     autocomplete="billing address-level2" />

<!-- Falsch: Autofill für Personendaten abgeschaltet -->
<input id="tel" type="tel" autocomplete="off" />

<!-- Richtig -->
<input id="tel" type="tel" autocomplete="tel" />

Ein Grenzfall, der oft falsch gelöst wird: Felder, in die man Daten anderer Personen einträgt. Ein Formular „Empfängerin des Gutscheins“ oder eine Teilnehmerliste fällt nicht unter 1.3.5 – dort wäre ein given-name-Token sogar schädlich, weil der Browser die eigenen Daten vorschlagen würde. Der BIK-BITV-Test nimmt Seiten ausdrücklich aus, auf denen Daten mehrerer Personen erfasst werden.

Die restlichen Formularpflichten – Beschriftung, Gruppierung, Pflichtfeldkennung – stehen unter Formular-Semantik und Labels & Beschriftungen.

So testest du es

1. Formulare auflisten, die Personendaten erfassen: Registrierung, Bestellung, Kontakt, Newsletter, Profil, Zahlungsdaten.
2. Jedes Feld einzeln durchgehen und die Frage stellen: Geht es hier um die nutzende Person selbst? Nur dann ist ein Token fällig.
3. Tokens gegen die Liste prüfen. Die 53 zulässigen Zwecke stehen in der WCAG-Sektion „Input Purposes“; alles andere ist ungültig, auch wenn es plausibel klingt.
4. axe DevTools laufen lassen und die Regel autocomplete-valid beachten. Sie findet Schreibfehler und erfundene Werte – nicht aber ein gültiges Token am falschen Feld.
5. Praxisprobe im Browser: Ein Profil mit Adresse hinterlegen und das Formular ausfüllen lassen. Landen die Werte in den richtigen Feldern? Rutscht die Postleitzahl ins Ortsfeld, ist die Zuordnung vertauscht.
6. Gegenprobe mit einem Passwort-Manager, weil er dieselben Tokens auswertet – das ist gleichzeitig die halbe Prüfung für 3.3.8.

Häufiger Fehler in der Praxis

Der Dauerbrenner ist die vertauschte Adressebene. address-level1 ist die größte Verwaltungseinheit unterhalb des Landes, also in Deutschland das Bundesland; address-level2 ist die Stadt. Weil deutsche Formulare selten nach dem Bundesland fragen, wird address-level1 gern für den Ort verwendet – und dann füllt der Browser „Nordrhein-Westfalen“ ins Ortsfeld. Das fällt im Test sofort auf, wenn man einmal ein echtes Profil durchlaufen lässt.

Der zweite ist autocomplete="off" aus Sicherheitsgründen. Die Begründung hält sich hartnäckig, ist aber überholt: Browser ignorieren die Angabe bei Anmeldefeldern seit Jahren, weil abgeschaltetes Autofill Menschen zu schwächeren Passwörtern treibt. Auf Adress- und Kontaktfeldern verstößt sie zusätzlich gegen 1.3.5. Wenn ein Feld wirklich nie vorausgefüllt werden soll – etwa ein Einmalcode –, ist autocomplete="one-time-code" der richtige Weg, nicht off.

Der dritte betrifft Komponentenbibliotheken. Ein hübsches Eingabefeld aus einer Design-Bibliothek reicht autocomplete schlicht nicht durch: Das Attribut landet am äußeren <div> statt am <input>. Sichtbar ist das nur im Inspektor. Ich guck bei fremden Bibliotheken inzwischen zuerst nach, ob die Attribute unten ankommen – das ist in fünf Minuten geprüft, und dann hat man’s.

Häufige Fragen

Gilt 1.3.5 für jedes Formularfeld?

Nein. Das Kriterium greift nur bei Feldern, die Daten über die nutzende Person selbst erfassen und einem der 53 definierten Zwecke entsprechen. Eine Suchleiste, ein Kommentarfeld, ein Betreff, ein Feld für die Adresse eines Dritten oder eine Mengenangabe im Warenkorb bleiben außen vor.

Reicht type="email" statt autocomplete="email"?

Nein. Der Eingabetyp bestimmt Tastaturbelegung und Browservalidierung, sagt aber nichts über den Zweck im Sinne der Norm – type="text" mit autocomplete="email" erfüllt 1.3.5, type="email" ohne Token nicht. In der Praxis setzt man beides, weil sie unterschiedliche Aufgaben erfüllen.

Darf ich autocomplete bei Zahlungsdaten weglassen?

Aus Konformitätssicht nicht: Kreditkartenfelder gehören zu den definierten Zwecken und brauchen cc-number, cc-exp und cc-name. Die Sorge um Sicherheit ist an dieser Stelle unbegründet, weil die Daten im Passwort-Manager oder Browserprofil der nutzenden Person liegen und nicht auf dem Server.

Was ist mit Feldern in einem <select> oder eigenen Comboboxen?

autocomplete funktioniert auch an <select>-Elementen, etwa country-name oder bday-year. Bei nachgebauten Comboboxen liegt der Wert dagegen häufig in einem <div> – dann greift das Token nicht. Solche Bauteile brauchen entweder ein echtes Formularfeld im Hintergrund oder eine native Umsetzung.

Wie hängt 1.3.5 mit 3.3.8 zusammen?

Eng. 3.3.8 Zugängliche Authentifizierung verlangt, dass die Anmeldung ohne kognitiven Funktionstest möglich ist – und der übliche Weg dorthin ist der Passwort-Manager, der genau die Tokens username und current-password auswertet. Wer 1.3.5 im Anmeldeformular sauber umsetzt, erledigt einen guten Teil von 3.3.8 gleich mit.

Verwandte Themen

• Formular-Semantik & Input-Typen – Typen und Attribute im Zusammenhang
• Labels & Beschriftungen – die sichtbare Hälfte
• 3.3.8 Zugängliche Authentifizierung – Autofill als Login-Erleichterung
• 3.3.7 Redundante Eingabe – Daten nicht zweimal abfragen
• 3.3.2 Beschriftungen oder Anweisungen – was am Feld stehen muss