Komponenten · Formulare
Mehrstufige Formulare & Wizards barrierefrei
Ein barrierefreier Wizard beantwortet an jeder Stelle drei Fragen: Wo bin ich, was kommt noch, und sind meine Eingaben noch da? Technisch heißt das: Fortschritt im Seitentitel, in einer geordneten Schrittliste mit aria-current="step" und in der Überschrift – dazu Fokusführung beim Wechsel und Eingaben, die beim Zurückblättern erhalten bleiben.
Checkout, Registrierung, Antragsstrecke: Sobald ein Formular lang wird, teilt man es in Schritte – und genau an diesen Nahtstellen entstehen die Barrieren. WCAG 2.2 hat für solche Strecken gleich zwei Kriterien nachgeschärft, und das teuerste Problem ist keines davon: Es ist der Fokus, der nach dem Schrittwechsel im Nichts hängt und den neuen Schritt lautlos beginnen lässt.
Das Wichtigste in Kürze
- Der Fortschritt steht dreifach da: im Seitentitel („Zahlung (Schritt 2 von 3)“), in einer
<ol>-Schrittliste mitaria-current="step"und in der<h1>. - Nach dem Schrittwechsel gehört der Fokus auf die Überschrift des neuen Schritts – sonst bleibt er stehen, und der Screenreader schweigt zum Wechsel.
- 3.3.7 Redundante Eingabe ist Stufe A, nicht AA: Was im selben Vorgang schon eingegeben wurde, wird vorbelegt oder zur Auswahl angeboten – Ausnahmen nur bei Sicherheit, Notwendigkeit oder abgelaufener Gültigkeit.
- „Zurück“ darf keine Daten verwerfen. Zustand server- oder clientseitig halten, nie auf den Browser-Cache hoffen.
- Validiert wird pro Schritt, mit Fehlerzusammenfassung und Feldmeldungen. Niemand soll in Schritt 4 erfahren, was in Schritt 1 falsch war.
- Vor dem verbindlichen Abschluss steht eine Prüfseite mit „Ändern“-Links je Abschnitt – das verlangt 3.3.4 für rechtliche, finanzielle und datenbezogene Vorgänge.
- Session-Timeouts brauchen Vorwarnung und Verlängerung: gewarnt wird vor Ablauf, für die Verlängerung bleiben mindestens 20 Sekunden, und sie muss mindestens zehnmal möglich sein (2.2.1).
- Ein Schritt pro Seite ist die robusteste Technik. Echte URLs, echter Browser-Zurück-Knopf, Fokus und Titel gratis.
Die Basis: jedes Einzelformular bleibt ein gutes Formular
Alles, was für Labels, Validierung und Fehlermeldungen gilt, gilt pro Schritt unverändert. Ein Wizard macht kein schlechtes Formular gut – er verteilt es nur auf mehr Seiten. Dazu kommen die vier Bausteine, die den Wizard vom Einzelformular unterscheiden.
Baustein 1: Orientierung – Titel, Liste, Überschrift
<head>
<title>Zahlung (Schritt 2 von 3) – Kasse | Beispiel-Shop</title>
</head>
…
<nav aria-label="Bestellschritte">
<ol class="steps">
<li>
<a href="/kasse/adresse.html">Adresse</a>
<span class="visually-hidden">(abgeschlossen)</span>
</li>
<li aria-current="step">Zahlung</li>
<li aria-disabled="true">Prüfen & bestellen</li>
</ol>
</nav>
<main>
<h1>Schritt 2 von 3: Zahlung</h1>
…
</main>
Warum dreifach? Weil jede Stelle andere Menschen erreicht:
- Der Seitentitel ist die einzige Stelle, die ohne Blick in die Seite funktioniert – bei zwanzig offenen Tabs, in der Fensterliste, im Verlauf.
- Die Schrittliste zeigt gleichzeitig, was war und was kommt. Sie ist semantisch eine
<ol>, weil die Reihenfolge Bedeutung trägt, und der aktuelle Punkt trägtaria-current="step"– dasselbe Muster wie bei den Breadcrumbs. -
Die
<h1>ist der Anker für die Überschriftennavigation und gleichzeitig das Fokusziel beim Wechsel.
Was dagegen nicht funktioniert: die Schrittzahl nur als Kreis-Grafik. Dann fehlt die Information allen, die nicht auf die Optik zugreifen. Und role="progressbar" ist für die Schrittanzeige das falsche Werkzeug: Sie beschreibt einen laufenden Vorgang, den niemand steuert, nicht eine Abfolge von Stationen, zwischen denen man sich bewegt.
Ein Detail zu den erledigten Schritten: Der Zusatz „(abgeschlossen)“ als versteckter Text ist mehr als Kosmetik. Optisch erkennt man den Stand am Häkchen und an der Farbe; ohne den Text hört ein Screenreader dreimal denselben Link ohne Zustand.
Baustein 2: Fokus-Führung beim Schrittwechsel
Bei klassischen Einzelseiten pro Schritt übernimmt der Browser das Nötige: Neue Seite, neuer Titel, Fokus am Dokumentanfang. Beim Single-Page-Wizard, bei dem Schritte per Skript getauscht werden, musst du den Fokus führen:
function schrittZeigen(schritt) {
aktuellen.hidden = true;
schritt.hidden = false;
const titel = schritt.querySelector('h2');
titel.setAttribute('tabindex', '-1');
titel.focus();
document.title = `${titel.textContent} – Kasse | Beispiel-Shop`;
history.pushState({ schritt: schritt.id }, '', `#${schritt.id}`);
}Drei Dinge passieren hier zusammen, und alle drei sind nötig:
- Der Fokus landet auf der Überschrift des neuen Schritts. Ein
tabindex="-1"macht sie programmatisch fokussierbar, ohne sie in die Tab-Reihenfolge zu holen. Der Screenreader liest daraufhin den neuen Abschnitt an – das ist die Ansage, die den Wechsel überhaupt hörbar macht. - Der Seitentitel wird aktualisiert. Sonst bleibt „Schritt 1 von 3“ im Tab stehen, während man in Schritt 3 ist.
- Der Verlauf bekommt einen Eintrag. Ohne
pushStateführt der Browser-Zurück-Knopf aus der Strecke heraus – der häufigste Grund für abgebrochene Bestellungen bei Single-Page-Wizards, und für Menschen, die den Zurück-Knopf als Korrekturweg nutzen, ein echtes Hindernis.
Der Fokus gehört auf die Überschrift, nicht auf das erste Eingabefeld. Beim Feld hört man nur das Label und weiß nicht, in welchem Abschnitt man gelandet ist; bei der Überschrift bekommt man den Kontext und tabbt einmal weiter.
Baustein 3: Eingaben bewahren – die 2.2-Pflichten
Zwei WCAG-2.2-Kriterien zielen direkt auf Wizards, und eines davon wird regelmäßig unterschätzt.
3.3.7 Redundante Eingabe liegt auf Stufe A. Das heißt: Es gilt schon für die niedrigste Konformitätsstufe und damit überall, wo überhaupt eine Anforderung besteht. Der Wortlaut verlangt, dass Informationen, die im selben Vorgang bereits eingegeben wurden, entweder automatisch vorbelegt oder zur Auswahl angeboten werden. Der Klassiker ist die Rechnungsadresse: „Rechnungsadresse entspricht Lieferadresse“ als Checkbox statt eines zweiten Adressformulars.
Drei Ausnahmen nennt das Kriterium ausdrücklich: wenn die erneute Eingabe notwendig ist (ein Merkspiel wäre sonst sinnlos), wenn sie aus Sicherheitsgründen verlangt wird (das Passwort zur Bestätigung), oder wenn die frühere Angabe nicht mehr gültig ist. Alles andere ist ein Verstoß – auch wenn es nur unbequem wirkt.
„Zurück“ ohne Datenverlust. Wer zurückblättert oder von der Prüfseite aus korrigiert, findet alle Eingaben wieder vor. Technisch: Zustand server- oder clientseitig halten. Auf den Browser-Cache zu bauen ist keine Lösung – er verhält sich je nach Browser, Formularart und Zurück-Weg unterschiedlich.
Dazu kommt 2.2.1, und zwar mit erstaunlich konkreten Zahlen: Eine Zeitbegrenzung muss abschaltbar, anpassbar (auf mindestens das Zehnfache des Standardwerts) oder verlängerbar sein. Für die Verlängerung gilt: vor Ablauf warnen, dann mindestens 20 Sekunden Zeit lassen, um mit einer einfachen Handlung zu verlängern – und das mindestens zehnmal erlauben. Ausgenommen sind Echtzeit-Ereignisse, Fälle, in denen die Frist unerlässlich ist, und Grenzen jenseits von 20 Stunden.
Der Grund ist einfach: Mit Switch-Bedienung oder Sprachsteuerung dauert ein Formular nun einmal länger. Eine Sitzung, die nach zehn Minuten still verfällt, ist für manche Nutzer eine Wand.
Die Timeout-Warnung selbst gehört als Dialog umgesetzt, mit Fokus darin – nicht als Meldung, die irgendwo am Rand erscheint und unbemerkt bleibt. Und der Verlängern-Knopf ist der erste Tabstop.
Baustein 4: Fehler je Schritt, Abschluss mit Prüfseite
Validiert wird pro Schritt, mit Fehler-Zusammenfassung und Feld-Meldungen (3.3.1). Nach dem Absenden eines Schritts mit Fehlern gehört der Fokus in die Zusammenfassung – nicht auf das erste falsche Feld, weil man dann nicht erfährt, wie viele Fehler es insgesamt gibt.
Vor dem verbindlichen Abschluss steht die Übersichtsseite mit „Ändern“-Links je Abschnitt. Das ist die 3.3.4-Pflicht für Vorgänge mit rechtlichen oder finanziellen Folgen: Eingaben müssen entweder zurücknehmbar, geprüft oder bestätigbar sein – und in deutschen Shops ist die Prüfseite ohnehin rechtlicher Standard.
Zwei Details, die den Unterschied machen: Die „Ändern“-Links führen zurück und danach wieder auf die Prüfseite, nicht in die Strecke ab Schritt 1. Und jeder Link nennt sein Ziel im Text – „Zahlungsart ändern“ statt fünfmal „Ändern“, sonst ist die Linkliste eines Screenreaders eine Reihe identischer Einträge (2.4.4).
Enthält die Strecke einen Anmeldeschritt, kommt 3.3.8 Zugängliche Authentifizierung dazu: kein Rätsel, kein Gedächtnistest, und Einfügen aus dem Passwortmanager muss erlaubt bleiben.
Wie viele Schritte, und wie viel pro Schritt?
Hier gibt es keine Zahl, aber eine Richtung. Jede Naht ist ein Abbruchrisiko und eine Stelle, an der Fokus und Zustand verloren gehen können. Gleichzeitig ist ein Schritt mit vierzig Feldern für Menschen mit kognitiven Einschränkungen kaum zu bewältigen.
Da würd ich nach Zusammengehörigkeit schneiden, nicht nach Feldanzahl: Adresse, Zahlung, Prüfen sind drei Fragen, die man einzeln beantworten kann. „Vorname“ und „Nachname“ auf zwei Schritte zu verteilen, macht nichts leichter – es verdoppelt nur die Nahtstellen.
Und die robusteste Technik bleibt die klassische Seitenfolge: echte URLs, echter Browser-Zurück-Knopf, Fokus und Titel gratis. Single-Page-Wizards sparen einen Seitenwechsel und kosten dafür Fokus-Management, Titel-Pflege, Verlaufs-Logik und Zustandshaltung in Eigenregie. Wer unsicher ist, wählt die Seitenfolge.
Häufige Fehler
- Fortschritt nur als Grafik ohne Text und ohne
aria-current. - Fokus bleibt nach dem Wechsel stehen – der neue Schritt beginnt lautlos.
- Seitentitel wird nicht aktualisiert und zeigt dauerhaft Schritt 1.
- Browser-Zurück verlässt die Strecke, weil kein Verlaufseintrag geschrieben wurde.
- „Zurück“ verwirft Eingaben – Verstoß gegen den Geist von 3.3.7 und der sichere Weg zum Abbruch.
- Timeout mitten im Schritt ohne Warnung und ohne Verlängerung.
- Deaktivierter „Weiter“-Button ohne Erklärung – besser aktiv lassen und beim Klick die konkreten Fehler benennen.
- Fünf gleichnamige „Ändern“-Links auf der Prüfseite.
-
role="progressbar"für die Schrittanzeige – falsches Muster, falsche Erwartung.
Eine Seite pro Schritt oder Schritte im Browser umschalten? Der Komponenten-Baukasten zeigt beide Varianten mit Vorschau, Code und einem Testprotokoll, das den Fokuswechsel und die Fehlerliste mitnimmt.
Häufige Fragen
Brauche ich eine Live-Region für den Schrittwechsel?
Wenn der Fokus sauber auf die neue Überschrift geführt wird, hört der Nutzer den Wechsel dadurch bereits. Eine zusätzliche Statusmeldung lohnt für Nebeninfos, die nicht im Fokusziel stehen – „Eingaben gespeichert“ oder „3 von 12 Dateien übertragen“. Beides gleichzeitig erzeugt doppelte Ansagen.
Wie viele Schritte sind okay?
So wenige wie möglich, geschnitten nach zusammengehörigen Angaben. Für die kognitive Last zählt die Übersichtlichkeit innerhalb eines Schritts mehr als die reine Schrittzahl – ein Schritt mit vier klar gruppierten Feldern ist leichter als einer mit vierzig, egal wie viele Schritte es insgesamt sind.
Darf ich Schritte überspringbar machen?
Ja, und bei optionalen Abschnitten ist das sinnvoll. Wichtig: Der übersprungene Schritt muss in der Liste sichtbar bleiben und erreichbar sein, und sein Zustand gehört angesagt („übersprungen“). Ein Schritt, der einfach verschwindet, macht die Zählung „2 von 3“ falsch.
Wo speichere ich den Zwischenstand?
Serverseitig, wenn es einen Account oder eine Sitzung gibt – dann übersteht der Stand auch einen Gerätewechsel. sessionStorage ist die pragmatische Zwischenlösung für anonyme Strecken. Was nicht dorthin gehört: Zahlungsdaten und alles, was man nicht im Klartext im Browser liegen haben möchte.
Gilt 3.3.7 auch über verschiedene Domains hinweg?
Ja, solange es derselbe Vorgang in derselben Sitzung ist. Das W3C nennt ausdrücklich den Fall eines externen Zahlungsdienstleisters: Auch dort dürfen bereits erfasste Angaben nicht erneut abgefragt werden, wenn sie zum selben Prozess gehören.
Fazit
Ein barrierefreier Wizard ist Orientierung an drei Stellen, Fokusführung beim Wechsel, Fehler am Ort des Geschehens und Eingaben, die nichts vergessen. Die Messlatte liefern 3.3.7 auf Stufe A, 3.3.4 und 2.2.1.
Wenn du nur eine Sache umsetzt, dann die Fokusführung: Sie kostet vier Zeilen und ist der Unterschied zwischen einem Schrittwechsel, der angesagt wird, und einem, der einfach passiert. Die Formular-Grundlagen stehen bei den Labels und der Validierung.
Quellen
- Understanding SC 3.3.7 Redundant Entry (W3C – Wortlaut, Stufe A, die drei Ausnahmen und der Fall externer Zahlungsdienstleister)
- Understanding SC 2.2.1 Timing Adjustable (W3C – 20-Sekunden-Warnung, zehnfache Verlängerung, Ausnahmen)