Cookie-Banner und Dialoge mit der Tastatur prüfen: Erreichbarkeit, Beschriftung, Fokusführung
6 Min. Lesezeit · DACH
Das Einwilligungsfenster ist das erste, was eine Besucherin antrifft, und oft die erste Barriere. Wer nur mit der Tastatur arbeitet, kommt an einem schlecht gebauten Fenster nicht vorbei und damit gar nicht auf die Website. Dieser Artikel zeigt, wie man ein solches Fenster in wenigen Minuten prüft und was der Unterschied zwischen einem gehaltenen Fokus und einer Tastaturfalle ist. Die Regeln gelten unabhängig vom Land; was das Fenster inhaltlich fragen muss, ist eine datenschutzrechtliche Frage und nicht Gegenstand dieses Artikels, der keine Rechtsberatung ist.
Redaktion Zugangscheck, veröffentlicht am . Wer dahintersteht
Keine Rechtsberatung. Quellen am Ende des Artikels.
Drei Fragen an jedes Fenster
Egal ob Einwilligungsfenster, Grössenberatung oder Hinweis auf Lieferfristen: Ein Dialog wird immer nach denselben drei Fragen geprüft. Erreichbarkeit: Kommt die Tastatur überhaupt hinein und wieder heraus? Beschriftung: Sagt ein Vorleseprogramm, was das Fenster ist und was es will? Fokusführung: Wo steht der Fokus beim Öffnen, wo bleibt er während der Bedienung, wo landet er beim Schliessen?
Das Muster für modale Dialoge des W3C beantwortet alle drei. Beim Öffnen wandert der Fokus auf ein Element im Dialog. Die Tabulatortaste bewegt den Fokus zum nächsten fokussierbaren Element innerhalb des Dialogs und vom letzten wieder auf das erste; Umschalt mit Tabulator läuft rückwärts und vom ersten auf das letzte. Die Escape-Taste schliesst den Dialog. Beim Schliessen kehrt der Fokus zu dem Element zurück, das den Dialog geöffnet hat.
An Auszeichnungen verlangt das Muster: Das Element, das den Dialog trägt, hat die Rolle dialog und aria-modal auf true. Der Dialog hat einen Namen, entweder über aria-labelledby mit Verweis auf einen sichtbaren Titel oder über aria-label. Beschreibender Text kann über aria-describedby angebunden werden.
Gehaltener Fokus oder Tastaturfalle
Hier entsteht das häufigste Missverständnis. Dass der Fokus ein Fenster nicht verlässt, ist kein Fehler, sondern der Sinn eines modalen Dialogs: Alles ausserhalb ist gerade nicht bedienbar, und der Fokus soll es auch nicht vortäuschen. Das Erfolgskriterium 2.1.2 der WCAG, «Keine Tastaturfalle», hält ausdrücklich fest, dass es Zeiten gibt, in denen es angemessen ist, den Fokus auf einen Teil des Inhalts zu beschränken, zum Beispiel in einem modalen Dialog, und dass dies das Kriterium nicht verletzt, solange die Nutzerin weiss, wie sie den Fokus wieder befreit und den Bereich verlässt.
Wann ein gehaltener Fokus in Ordnung ist und wann er zur Falle wird
| Verhalten | Einordnung | Woran erkennbar |
|---|---|---|
| Fokus bleibt im Dialog, Escape schliesst, eine sichtbare Schaltfläche schliesst ebenfalls | In Ordnung, das ist das Muster | Escape funktioniert; die Schliessen-Schaltfläche ist per Tabulator erreichbar und beschriftet |
| Fokus bleibt im Dialog, Escape tut nichts, es gibt aber eine erreichbare Schaltfläche zum Schliessen | Vertretbar, aber unfertig | Nutzerinnen suchen Escape zuerst; der Weg hinaus ist nicht der erwartete |
| Fokus bleibt im Dialog, kein Weg hinaus ausser Neuladen der Seite | Tastaturfalle, Verstoss gegen 2.1.2 | Tabulator läuft im Kreis, Escape tut nichts, keine Schaltfläche führt hinaus |
| Fokus wandert hinter das Fenster in die Seite | Fehler, auch wenn es sich frei anfühlt | Der Fokusring ist nicht sichtbar, weil er unter der Abdeckung liegt; das Vorleseprogramm liest verdeckte Inhalte |
Hinweis: Der letzte Fall ist der gefährlichste, weil er in keiner automatischen Prüfung auffällt. Der Fokus ist da, er ist nur unsichtbar. Erkennbar ist er nur daran, dass man beim Tabulator-Durchgang zählt und irgendwann nichts mehr hervorgehoben sieht.
Die Prüfung in sieben Schritten
- Die Seite in einem neuen, leeren Browserfenster öffnen, damit das Einwilligungsfenster wirklich erscheint.
- Ohne die Maus zu berühren die Tabulatortaste drücken: Landet der Fokus im Fenster, oder beginnt er in der Seite dahinter?
- Den Tabulator durch das ganze Fenster laufen lassen und zählen: Ist jede Schaltfläche erreichbar, auch «Einstellungen» und «Alle ablehnen», und ist der Fokus jederzeit sichtbar?
- Weiter drücken, bis der Fokus wieder auf dem ersten Element steht. Läuft er stattdessen in die Seite dahinter, ist die Abdeckung nur optisch.
- Escape drücken. Schliesst das Fenster? Wenn nicht, gibt es eine erreichbare, beschriftete Schaltfläche zum Schliessen?
- Nach dem Schliessen ohne Maus weiterarbeiten: Steht der Fokus wieder an einer sinnvollen Stelle, oder beginnt er von vorne am Seitenanfang?
- Mit einem Vorleseprogramm wiederholen und zuhören: Wird das Fenster als Dialog angesagt und mit einem Namen, oder hört man nur eine Schaltfläche ohne Zusammenhang?
Das W3C führt Tastaturzugang und sichtbaren Fokus unter seinen einfachen Prüfungen und ist dabei deutlich: Solche Prüfungen decken nur wenige Punkte ab und sind schnell gemeint, nicht abschliessend; eine Seite könne sie scheinbar bestehen und trotzdem erhebliche Barrieren haben. Für ein Einwilligungsfenster gilt das erst recht, weil es in Zuständen auftritt, die eine Stichprobe selten erwischt.
Ein Einwilligungsfenster, kommentiert
Der folgende Ausschnitt ist für diesen Artikel gebaut. Er zeigt ein Fenster, das optisch modal wirkt und technisch keines ist.
Kommentierter Befund an einem selbst erstellten Beispieldialog
| Teil | Inhalt |
|---|---|
| Stelle | Einwilligungsfenster beim ersten Aufruf der Startseite, unten fest eingeblendet |
| Ausschnitt | <div class=banner> mit zwei <button>, ohne role dialog, ohne aria-modal, ohne Namen; die Seite dahinter bleibt im Tabulator-Durchgang |
| Auswirkung | Das Vorleseprogramm kündigt kein Fenster an. Der Tabulator läuft nach der zweiten Schaltfläche in die verdeckte Seite, der Fokusring ist dort unsichtbar. Escape tut nichts. |
| Korrektur | Dem Fenster role dialog und aria-modal true geben, den sichtbaren Titel über aria-labelledby anbinden, den Fokus beim Öffnen in das Fenster setzen und im Fenster halten, Escape belegen und den Fokus beim Schliessen auf das Element zurückgeben, das den Dialog geöffnet hat. |
| Nachprüfung | Die sieben Schritte oben wiederholen, dazu den Tabulator-Durchgang zählen: Die Zahl der erreichbaren Elemente muss der Zahl der Schaltflächen im Fenster entsprechen. |
Das W3C führt zu seinem Muster ein vollständiges Beispiel mit Quelltext, an dem sich das erwartete Verhalten nachfahren lässt. Wer ein eigenes Fenster baut, prüft es am einfachsten gegen dieses Beispiel: dieselben Tasten, dasselbe Ergebnis.
Der Fokus nach dem Schliessen
Der Rückweg wird am häufigsten vergessen. Die Regel des Musters ist einfach: Beim Schliessen kehrt der Fokus zu dem Element zurück, das den Dialog geöffnet hat, ausser dieses Element existiert nicht mehr oder der Arbeitsablauf legt eine andere Stelle nahe. Für ein Einwilligungsfenster, das beim ersten Aufruf von selbst erscheint, gibt es kein auslösendes Element; dann ist der Anfang des Hauptinhalts die sinnvolle Stelle.
Ein zweiter Punkt betrifft den zweiten Besuch. Wer die Einstellungen später ändern will, braucht einen dauerhaft erreichbaren Weg dorthin, üblicherweise einen Link in der Fusszeile. Dieser Link ist ein auslösendes Element, und beim Schliessen gehört der Fokus genau dorthin zurück, nicht an den Seitenanfang. Sonst beginnt die Nutzerin nach jeder Änderung wieder oben.
Ihre Website jetzt prüfen
Der Gratis-Check prüft bis zu fünf Seiten und die verlinkten PDFs im echten Browser und zeigt die wichtigsten Verstösse mit Beispiel und Anleitung. Kein Konto, kein Siegel, keine Rechtsberatung.
Häufige Fragen
Ist es ein Fehler, wenn der Fokus das Fenster nicht verlässt?
Nein, das ist das gewünschte Verhalten eines modalen Dialogs. Das Erfolgskriterium 2.1.2 hält fest, dass die Beschränkung des Fokus auf einen Teil des Inhalts, etwa in einem modalen Dialog, kein Verstoss ist, solange die Nutzerin weiss, wie sie den Fokus wieder befreit. Erst wenn es keinen Weg hinaus gibt, ist es eine Tastaturfalle.
Muss die Escape-Taste das Fenster schliessen?
Das Muster des W3C sieht es vor: Escape schliesst den Dialog. Nutzerinnen erwarten es, und es ist der einzige Weg, der ohne Suchen funktioniert. Eine erreichbare und beschriftete Schaltfläche zum Schliessen ersetzt Escape nicht, sie ergänzt es.
Warum findet die automatische Prüfung das Problem nicht?
Weil sie den Zustand nicht herstellt und die Tastenfolge nicht fährt. Ein Werkzeug kann fehlende Namen und fehlende Rollen messen, aber nicht, wohin der Fokus nach dem dreizehnten Tabulator springt. Die Fokusführung ist eine Prüfung mit den Händen, nicht mit einer Regel.
Muss «Alle ablehnen» gleich erreichbar sein wie «Alle annehmen»?
Für die Tastatur gilt: Beide Schaltflächen müssen erreichbar, sichtbar fokussiert und beschriftet sein, und der Weg dorthin darf nicht länger sein als der zur Zustimmung. Ob und wie eine Ablehnung angeboten werden muss, ist eine Frage des Datenschutzrechts und gehört in die Rechtsberatung.
Was ist mit Fenstern, die erst nach einigen Sekunden aufgehen?
Sie sind der schlimmste Fall, weil sie den Fokus mitten in einer Eingabe wegreissen. Wenn ein solches Fenster nötig ist, gehört der Fokus erst dann hinein, wenn die Nutzerin den nächsten Schritt macht, und keinesfalls während einer laufenden Eingabe. Geprüft wird es wie jeder andere Dialog, nur zusätzlich beim Tippen.
Quellen
Abgerufen am 22.09.2026. Jeder Link öffnet ein neues Fenster.
- W3C ARIA Authoring Practices: Dialog (Modal) Pattern (w3.org, neues Fenster)
- W3C ARIA Authoring Practices: Modal Dialog Example (w3.org, neues Fenster)
- W3C: Understanding Success Criterion 2.1.2 No Keyboard Trap (w3.org, neues Fenster)
- W3C WAI: Easy Checks, a First Review of Web Accessibility (w3.org, neues Fenster)
Weiterlesen
- Den Checkout auf Barrierefreiheit prüfen: Warenkorb, Anmeldung, Eingaben, Fehlermeldungen, Zahlung
Warum eine Prüfung der Startseite den Kaufprozess nicht erfasst und wie man Warenkorb bis Zahlung als zusammenhängenden Ablauf testet. Mit Testvorlage.
- Barrierefreiheit testen: was Werkzeuge finden, was nur Menschen sehen
Wie man eine Website auf Barrierefreiheit prüft: automatisch, mit Tastatur, Vorleseprogramm und Zoom. Mit Checkliste und dem, was Software nicht kann.
- WordPress auf Barrierefreiheit testen: Theme, redaktionelle Inhalte und Erweiterungen auseinanderhalten
Wie man bei einem WordPress-Auftritt herausfindet, ob ein Befund aus dem Theme, aus den Inhalten oder aus einer Erweiterung kommt, und wo man ihn behebt.
- Barrierefreiheit-Checker im Überblick: axe, WAVE, Lighthouse, Accessibility Insights, PAC und Zugangscheck
Welche Werkzeuge Websites und PDFs auf Barrierefreiheit prüfen, was sie messen, was sie kosten und wo jedes seine Stärke hat. Sachlich, ohne Rangliste.
Stand der Rechtslage: 22.09.2026. Dieser Artikel erklärt, was in Gesetz, Verordnung und Norm steht, und ersetzt keine Rechtsberatung. Bei Zweifeln hilft die Bundesfachstelle Barrierefreiheit oder eine Anwältin.