WCAG 3.2.1: Bei Fokus

WCAG 3.2.1 verlangt, dass allein das Erhalten des Fokus keinen Kontextwechsel auslöst – kein neues Fenster, kein Seitenwechsel, kein automatisches Absenden, kein Umspringen des Fokus. Ansehen ist nicht anfassen: Durch eine Seite zu tabben muss folgenlos bleiben, solange niemand Enter drückt.

(Englisch: On Focus. Im BIK-BITV-Test heißt der Prüfschritt „3.2.1 Keine unerwartete Kontextänderung bei Fokus“.)

Das Wichtigste in Kürze

• Fokussieren ist Erkunden, nicht Auslösen. Wer mit der Tastatur navigiert, muss durch jedes Element hindurch – auch durch die, die er gar nicht aktivieren will.
• Kontextwechsel sind die großen Änderungen: neues Fenster, andere Seite, Formularversand, Versetzen des Fokus, vollständige Neuanordnung des Inhalts.
• Nicht jeder Effekt ist ein Kontextwechsel. Ein Tooltip, der beim Fokus erscheint und sich selbst wieder schließt, gilt laut Prüfschritt ausdrücklich nicht als Kontextänderung.
• Modale Dialoge sind vom Prüfschritt nicht gemeint – er bezieht sich auf neue Browserfenster, nicht auf skriptgesteuerte Überlagerungen.
• Der Fokusdieb ist der häufigste Verstoß: ein Skript, das den Fokus beim Durchtabben auf ein „wichtiges“ Feld zurückholt.
• Der Test ist eine Minute Arbeit: einmal von oben nach unten tabben, ohne Enter, und beobachten, ob die Seite still bleibt.
• 3.2.1 ist strenger als 3.2.2: Hier gibt es keine Ausnahme über eine Vorwarnung.
• Stufe A, seit WCAG 2.0 unverändert und über die EN 301 549 verbindlich.

Darf sich beim Tabben etwas ändern?

Nein. Allein das Erhalten des Fokus darf keinen Kontextwechsel auslösen: kein neues Fenster, kein Seitenwechsel, kein automatisches Absenden.

Der Normtext ist ein Satz: Wenn irgendein Bestandteil der Benutzerschnittstelle den Fokus erhält, löst dies keine Änderung des Kontexts aus. Der Rest ist die Frage, was als Kontextänderung gilt.

Die WCAG zählt dafür vier Arten auf:

• ein neues Fenster oder ein neuer Tab öffnet sich,
• die Seite wechselt,
• der Fokus wird versetzt – auf ein anderes Element als das, das gerade fokussiert wurde,
• der Inhalt wird so umgestaltet, dass die Bedeutung der Seite sich ändert.

Ein Formular, das sich beim Fokussieren selbst absendet, fällt unter die zweite und oft auch unter die vierte Kategorie.

Genauso wichtig ist, was kein Kontextwechsel ist. Der deutsche Prüfschritt sagt das ausdrücklich: Das Öffnen eines eigenen Tooltips – eines nicht-modalen Fensters, das sich selbst wieder schließt – gilt nicht als Kontextänderung. Ein Feld, das sich beim Fokus hervorhebt, ein Hilfetext, der erscheint, ein Untermenü, das aufklappt, solange der Fokus bleibt, wo er ist: Das ist alles erlaubt. Die Faustregel lautet: focus-Handler dürfen zeigen, nie wechseln.

Der Prüfschritt zieht außerdem zwei Grenzen, die man kennen sollte:

Modale Dialoge sind nicht gemeint. Der Prüfschritt bezieht sich auf neue Browserfenster, nicht auf skriptgesteuerte Überlagerungen innerhalb der Seite. Ein Dialog, der beim Fokussieren eines Felds aufgeht, ist trotzdem eine schlechte Idee – er wird über 2.4.3 Fokus-Reihenfolge und 2.1.2 Keine Tastaturfalle zum Problem, nicht zwangsläufig über 3.2.1.

Neue Fenster beim Aktivieren eines Links bewertet der Prüfschritt milder, weil moderne Browser dafür eigene Einstellungen anbieten. Das ist eine Aussage über Fenster, die durch bewusstes Klicken entstehen – nicht über solche, die beim bloßen Tabben aufspringen.

Der Normtext steht im Understanding-Dokument des W3C zu 3.2.1, das deutsche Prüfvorgehen im Prüfschritt „3.2.1 Keine unerwartete Kontextänderung bei Fokus“.

Wen betrifft es besonders?

Tastaturnutzende sind die Gruppe, für die das Kriterium geschrieben wurde. Mit der Maus kann man ein Element ansehen, ohne es anzufassen; mit der Tastatur nicht. Jedes bedienbare Element auf dem Weg zum Ziel bekommt unterwegs den Fokus. Wenn dabei etwas passiert, gibt es keinen Weg, das zu vermeiden – außer die Seite zu verlassen.

Screenreader-Nutzende erkunden Seiten fokussierend: Sie springen von Element zu Element, um zu erfahren, was es gibt. Ein Kontextwechsel unterwegs ist für sie besonders schwer zu bemerken, weil ihnen der Überblick fehlt, den ein Blick auf den Bildschirm liefert. Der Prüfschritt begründet das Kriterium genau damit – und weist darauf hin, dass die Zurück-Funktion des Browsers nach einem ungewollten Fensterwechsel oft nicht mehr hilft.

Für Menschen mit kognitiven Einschränkungen ist Vorhersehbarkeit die Grundlage jeder Bedienung. Eine Seite, die auf Erkundung mit Sprüngen reagiert, kostet nicht nur Orientierung, sondern Vertrauen: Man traut sich nicht mehr, etwas auszuprobieren.

Und Menschen mit starker Vergrößerung verlieren bei jedem ungewollten Sprung ihren Bildausschnitt. Bei 400 Prozent Zoom bedeutet das: Man sieht plötzlich einen anderen Teil der Seite und muss neu suchen, wo man gelandet ist.

Richtig & falsch im Code

Die klassischen Verstöße hängen fast alle an einem focus-Handler, der zu viel tut:

// Falsch: Fokus genügt, um zu navigieren
document.querySelector('#land').addEventListener('focus', () => {
  window.location.href = '/laenderauswahl.html';
});

// Falsch: Fokus öffnet ein neues Fenster
hilfeLink.addEventListener('focus', () => {
  window.open('/hilfe.html', '_blank');
});

// Falsch: der Fokusdieb – zieht den Fokus beim Durchtabben zurück
document.querySelectorAll('input').forEach((feld) => {
  feld.addEventListener('focus', () => {
    if (!pflichtfeldGefuellt) pflichtfeld.focus();
  });
});

Der dritte Fall ist der heimtückischste: Er ist als Hilfe gedacht („der Nutzer soll das Pflichtfeld nicht übersehen“) und macht die Seite unbedienbar. Wer nach unten tabben will, landet immer wieder im selben Feld – zugleich ein Verstoß gegen 2.1.2 Keine Tastaturfalle.

Erlaubt ist alles, was zeigt, ohne zu wechseln:

<!-- Richtig: Hilfetext erscheint bei Fokus, der Fokus bleibt -->
<label for="iban">IBAN</label>
<input type="text" id="iban" name="iban"
       aria-describedby="iban-hilfe" />
<p id="iban-hilfe" class="feldhilfe">
  22 Stellen, beginnend mit DE. Leerzeichen sind erlaubt.
</p>

// Richtig: Aktion erst bei bewusster Aktivierung
dialogKnopf.addEventListener('click', () => {
  laenderDialog.showModal();
});

Ein Muster, das häufig falsch gebaut wird, ist die automatische Weiterschaltung zwischen Codefeldern – etwa bei einer sechsstelligen Bestätigungsnummer:

// Falsch: springt schon beim Fokussieren weiter
ziffer.addEventListener('focus', () => naechstesFeld.focus());

// Vertretbar: springt erst, wenn tatsächlich etwas eingegeben wurde
ziffer.addEventListener('input', (e) => {
  if (e.target.value.length === 1) naechstesFeld.focus();
});

Die zweite Variante ist streng genommen ein Fall für 3.2.2 Bei Eingabe und wird dort diskutiert – bei Codefeldern gilt sie als erwartbar, wenn sie angekündigt ist. Für 3.2.1 zählt nur: Beim bloßen Fokussieren darf nichts springen. Noch besser ist ohnehin ein einziges Feld für den ganzen Code; das erspart die Diskussion und ist für Passwortmanager freundlicher.

So testest du es

1. Von ganz oben bis ganz unten durchtabben, ohne ein einziges Mal Enter oder Leertaste zu drücken. Die Seite muss dabei still bleiben.
2. Auf die vier Signale achten: Öffnet sich ein Fenster? Wechselt die Seite? Springt der Fokus woanders hin? Baut sich der Inhalt neu auf?
3. Rückwärts wiederholen mit Umschalt und Tab. Manche Fokushandler feuern nur in einer Richtung.
4. Formulare vollständig durchgehen – auch Selects, Radiogruppen und Datumsfelder. Dort sitzen die meisten Altlasten.
5. Den Code durchsuchen nach addEventListener('focus', onfocus= und .focus() und jeden Treffer einordnen: zeigt er nur, oder wechselt er?
6. Auf den Ladezeitpunkt achten. Ein autofocus auf einem Feld ist kein Verstoß gegen 3.2.1, kann aber 2.4.3 berühren, wenn es den Einstiegspunkt verschiebt.
7. Mit dem Screenreader gegenprüfen. Manche Kontextwechsel fallen visuell kaum auf, sind akustisch aber ein Bruch – etwa das lautlose Neuaufbauen einer Liste.

Häufiger Fehler in der Praxis

Der häufigste Verstoß ist das Select, das beim Durchgehen navigiert. Ein Sprachumschalter oder ein Sprungmenü löst per change eine Navigation aus – und in manchen Browsern feuert change schon beim Wechsel der Option mit den Pfeiltasten. Wer die Liste nur durchsehen will, landet auf einer anderen Seite. Formal ist das meist ein Fall für 3.2.2, im Ergebnis ist es dasselbe Problem: Erkunden löst aus.

Der zweite ist der Fokusdieb im Formular. Ein Skript soll dafür sorgen, dass ein Pflichtfeld ausgefüllt wird, und holt den Fokus zurück, sobald jemand weitertabbt. Für Mausnutzende fällt das nie auf. Ich würd solche Hilfen grundsätzlich streichen – sie lösen ein Problem, das eine gute Fehlermeldung besser löst, und machen die Seite für andere unbedienbar.

Der dritte ist das Popup beim Fokus. Ein Newsletter-Hinweis oder eine Chat-Einladung öffnet sich, sobald ein bestimmtes Element den Fokus bekommt – oft ein Nebeneffekt eines Werkzeugs, das eigentlich auf Mausbewegung reagieren sollte und auf Touchgeräten oder bei Tastaturnutzung anders auslöst.

Und der vierte, der bei Einzelseiten-Anwendungen häufiger wird: der Fokus, der beim Tabben verschwindet. Eine Komponente baut sich beim Fokussieren neu auf, das alte Element wird dabei ersetzt – und der Fokus landet auf body. Das ist der vierte Fall aus der Aufzählung, und er ist besonders unangenehm, weil danach das Tabben wieder ganz oben beginnt.

Häufige Fragen

Was gilt als Kontextänderung?

Vier Dinge: ein neues Fenster oder ein neuer Tab, ein Seitenwechsel, das Versetzen des Fokus auf ein anderes Element und ein so weitreichender Umbau des Inhalts, dass sich die Bedeutung der Seite ändert. Kleinere Änderungen – ein eingeblendeter Hilfetext, ein hervorgehobenes Feld – sind Inhaltsänderungen und keine Kontextänderungen.

Darf beim Fokus ein Tooltip erscheinen?

Ja. Der deutsche Prüfschritt hält ausdrücklich fest, dass ein eigener Tooltip – ein nicht-modales Fenster, das sich selbst wieder schließt – nicht als Kontextänderung gilt. Für den Tooltip selbst gelten dann die Regeln aus 1.4.13 Inhalt bei Hover oder Fokus: schließbar, überfahrbar, beständig.

Ist autofocus ein Verstoß gegen 3.2.1?

Nein. autofocus setzt den Fokus beim Laden, nicht als Reaktion darauf, dass ein Element den Fokus erhält. Es kann aus anderen Gründen problematisch sein – etwa wenn es den Einstiegspunkt verschiebt oder auf mobilen Geräten die Bildschirmtastatur aufklappt –, aber es fällt nicht unter dieses Kriterium.

Was ist der Unterschied zu 3.2.2 Bei Eingabe?

3.2.1 betrifft das bloße Fokussieren, 3.2.2 das Ändern einer Einstellung. Der entscheidende Unterschied liegt bei der Ausnahme: 3.2.2 erlaubt einen Kontextwechsel, wenn vorher darüber informiert wurde. Bei 3.2.1 gibt es diese Ausnahme nicht – Fokussieren darf nie einen Kontextwechsel auslösen.

Gilt das auch für modale Dialoge?

Der Prüfschritt bezieht sich auf neue Browserfenster, nicht auf Überlagerungen innerhalb der Seite. Ein Dialog, der beim Fokussieren eines Felds aufgeht, wird trotzdem zum Problem – über die Fokus-Reihenfolge und die Gefahr einer Tastaturfalle. Der bessere Weg bleibt: erst bei bewusster Aktivierung öffnen.

Verwandte Themen

• 3.2.2 Bei Eingabe – dieselbe Regel für das Ändern von Einstellungen
• 2.4.3 Fokus-Reihenfolge – wohin der Fokus überhaupt gehört
• 2.1.2 Keine Tastaturfalle – wenn der Fokus gar nicht mehr weiterkommt
• 1.4.13 Inhalt bei Hover oder Fokus – die Regeln für das, was beim Fokus erscheinen darf
• Tooltips & Popover – erlaubte Fokusanzeigen richtig bauen
• Tastatur & Fokus – der Überblick zum ganzen Themenfeld