Zum Hauptinhalt springen

Tastaturbedienung und Fokus nach WCAG richtig umsetzen

Website nur mit Tastatur bedienen: Fokusreihenfolge, sichtbarer Fokus, Skip-Link, Dialoge und Tastaturfallen mit Codebeispielen prüfen.

Marc Schraepler von Gerlach

Marc Schraepler von Gerlach

· barrierefreie-agenturen.de

Wie prüfen Sie eine Website mit der Tastatur?

Kurzantwort: Legen Sie die Maus zur Seite. Navigieren Sie mit Tab vorwärts und mit Umschalt+Tab rückwärts. Aktivieren Sie Links und Schalter mit Enter beziehungsweise Leertaste und schließen Sie überlagernde Elemente mit Escape. Jede Funktion muss erreichbar sein, der Fokus sichtbar bleiben und einer nachvollziehbaren Reihenfolge folgen.

Auf einen Blick:

  • Grundgesten: Tab vorwärts, Umschalt+Tab rückwärts, Enter und Leertaste aktivieren, Escape schließt.
  • Fokus sichtbar machen: :focus-visible mit deutlicher outline, nie outline: none ohne Ersatz (WCAG 2.4.7).
  • Reihenfolge: DOM-Struktur reparieren statt positiver tabindex-Werte. tabindex="-1" nur für programmatische Ziele.
  • Skip-Link: beim ersten Tab sichtbar, Ziel <main id="main" tabindex="-1">, damit der Fokus wirklich ankommt.
  • Dialoge: Fokus hinein, im Dialog halten, mit Escape schließen, danach zum Auslöser zurück.
  • Testdauer: der komplette Durchgang unten dauert etwa zehn Minuten, auch bei 200 % Zoom wiederholen.

Native Elemente sind der sichere Ausgangspunkt

Problematisch

<div class="button" onclick="save()">Speichern</div>

Das div ist weder automatisch fokussierbar noch besitzt es die Tastaturinteraktion und Semantik eines Schalters.

Besser

<button type="button" onclick="save()">Speichern</button>

Verwenden Sie Links für Navigation und Buttons für Aktionen. Ein tabindex="0" macht ein beliebiges Element zwar fokussierbar, baut aber seine Bedienlogik nicht nach. Warum native Elemente hier so viel Arbeit sparen, zeigt der Leitfaden zu semantischem HTML und ARIA.

Den Fokus sichtbar gestalten

Entfernen Sie die Browser-Markierung nicht ersatzlos. Ein robuster Stil kann so aussehen:

:focus-visible {
  outline: 3px solid #185fa5;
  outline-offset: 3px;
}

Der Fokusindikator muss sich ausreichend vom fokussierten Element und seiner Umgebung unterscheiden; die Grenzwerte dafür stehen im Artikel zum Farbkontrast nach WCAG. Prüfen Sie ihn auf hellen und dunklen Flächen sowie in Hover- und Fehlerzuständen. Fixierte Kopfzeilen oder Cookie-Banner dürfen das fokussierte Element nicht vollständig verdecken.

DOM-Reihenfolge statt positiver tabindex-Werte

Die Tab-Reihenfolge folgt grundsätzlich dem Dokument. Wenn die visuelle Reihenfolge mit CSS stark verändert wird, kann sie von der Fokus- und Lesereihenfolge abweichen. Reparieren Sie in diesem Fall die DOM-Struktur.

Vermeiden Sie tabindex="1", tabindex="2" und weitere positive Werte. Sie erzeugen eine zweite, schwer wartbare Reihenfolge. tabindex="-1" ist dagegen sinnvoll, um ein Ziel nur programmatisch zu fokussieren – etwa eine Fehlerzusammenfassung oder den Hauptinhalt nach einem Skip-Link.

Ein Skip-Link sollte beim ersten Tab-Schritt sichtbar werden und direkt zum Hauptinhalt führen:

<a class="skip-link" href="#main">Zum Inhalt springen</a>
<main id="main" tabindex="-1">…</main>

Testen Sie nicht nur, ob die Seite scrollt. Nach der Aktivierung muss auch der Tastaturfokus am Hauptinhalt ankommen.

Menüs und Dialoge

Ein aufklappbares Menü benötigt einen echten Button mit aria-expanded und aria-controls. Beim Schließen mit Escape sollte der Fokus zum auslösenden Button zurückkehren.

Bei einem modalen Dialog gelten zusätzliche Anforderungen:

  • Fokus beim Öffnen sinnvoll in den Dialog setzen.
  • Tab und Umschalt+Tab innerhalb des offenen Dialogs halten.
  • Escape zum Schließen anbieten, sofern die Aktion nicht zwingend fortgesetzt werden muss.
  • Fokus anschließend zum Auslöser zurückgeben.
  • Hintergrundinhalte dürfen nicht weiter bedienbar sein.

Das native <dialog>-Element übernimmt Teile dieses Verhaltens, ersetzt aber keinen realen Tastaturtest.

Ein reproduzierbarer Zehn-Minuten-Test

  1. Laden Sie die Seite neu und drücken Sie Tab.
  2. Prüfen Sie Skip-Link und Hauptnavigation.
  3. Folgen Sie der sichtbaren Fokusmarkierung durch die gesamte Seite.
  4. Bedienen Sie Menüs, Filter, Akkordeons und Dialoge.
  5. Füllen Sie Formulare aus und lösen Sie Fehler aus (Details im Leitfaden zu barrierefreien Formularen).
  6. Navigieren Sie mit Umschalt+Tab zurück.
  7. Prüfen Sie, ob ein Element unerreichbar ist oder der Fokus verschwindet.
  8. Wiederholen Sie den Test bei 200 % Zoom und schmalem Viewport.

Notieren Sie für jeden Fehler URL, Element, Tastenschritte, erwartetes und tatsächliches Verhalten. So wird aus „funktioniert nicht“ ein reproduzierbarer Befund für die Entwicklung. Wenn die Befunde tiefer in Komponenten und Templates sitzen, ist das ein Fall für eine barrierefreie Umsetzung durch eine spezialisierte Agentur.

Nutzen Sie ergänzend die WCAG-Schnellcheckliste oder lesen Sie den Überblick zu automatischen und manuellen Tests.

Häufige Fragen

Darf ich outline: none verwenden?

Nur wenn Sie einen mindestens gleichwertigen eigenen Fokusstil setzen. Die Markierung ersatzlos zu entfernen verletzt WCAG 2.4.7 auf Level AA und macht die Seite für Tastaturnutzende praktisch unbedienbar. Mit :focus-visible können Sie den Stil gezielt für Tastaturfokus vergeben, ohne bei Mausklicks einen Rahmen zu zeigen.

Was ist eine Tastaturfalle?

Ein Bereich, den Sie mit der Tastatur betreten, aber nicht wieder verlassen können – typisch bei Dialogen ohne Escape, eingebetteten Playern oder selbstgebauten Widgets. WCAG 2.1.2 verbietet das schon auf Level A, dem niedrigsten. Prüfen Sie es, indem Sie mit Umschalt+Tab auch wieder zurücknavigieren.

WCAG 2.4.1 verlangt auf Level A einen Mechanismus, um wiederkehrende Blöcke zu überspringen. Ein Skip-Link ist die robusteste und für Nutzende verständlichste Umsetzung, deshalb empfehlen wir ihn. Wichtig ist der zweite Schritt: nach der Aktivierung muss auch der Tastaturfokus im Hauptinhalt ankommen, nicht nur die Seite dorthin scrollen.

Sind positive tabindex-Werte ein WCAG-Fehler?

Nicht automatisch, aber sie sind fast immer ein Wartungsproblem. tabindex="1" und höher erzeugen eine zweite Reihenfolge neben der DOM-Struktur, die bei jeder Änderung neu durchdacht werden muss, und brechen dadurch schnell WCAG 2.4.3. Reparieren Sie stattdessen die DOM-Reihenfolge; tabindex="-1" bleibt für rein programmatische Fokusziele sinnvoll.

Quellen und weiterführende Standards

Stand: 7. August 2026.

Rechtlicher Hinweis: Die auf barrierefreie-agenturen.de bereitgestellten Inhalte dienen der allgemeinen Information über das Barrierefreiheitsstärkungsgesetz (BFSG). Sie stellen keine Rechtsberatung dar und können eine individuelle juristische Prüfung nicht ersetzen. Trotz sorgfältiger Recherche übernehmen wir keine Gewähr für die Richtigkeit, Vollständigkeit und Aktualität der bereitgestellten Informationen.