---
title: "Tastatur und Fokus: Websites, die ohne Maus funktionieren"
url: "https://barrierefreihochzwei.de/de/blog/tastatur-fokus-ohne-maus"
language: "de"
description: "Fokusreihenfolge, sichtbarer Fokus, Skip-Links, Tastaturfallen, modale Dialoge und ARIA mit Augenmaß: So wird deine Website komplett per Tastatur bedienbar."
published: "2026-09-25T09:00:00+02:00"
updated: "2026-10-15T09:42:08+02:00"
---

# Tastatur und Fokus: Websites, die ohne Maus funktionieren

Nicht alle nutzen eine Maus. So machst du Navigation, Dialoge und eigene Komponenten per Tastatur bedienbar, gestaltest einen sichtbaren Fokus und setzt ARIA nur dort ein, wo es hilft.

Leg die Maus zur Seite und versuch, auf deiner Website etwas zu bestellen. Oft dauert es nur wenige Tabulator-Drücke, bis etwas schiefgeht: Der Fokus ist unsichtbar, das Menü öffnet sich nur beim Überfahren mit der Maus, ein Cookie-Banner schluckt jede Eingabe oder ein Dialog lässt sich nicht mehr schließen.

Für viele Menschen ist das kein Experiment, sondern Alltag. Wer blind ist und einen Screenreader nutzt, bedient den Computer über die Tastatur. Menschen mit motorischen Einschränkungen arbeiten mit Tastatur, Schaltern oder Sprachsteuerung, die alle auf eine saubere Tastaturbedienung angewiesen sind. Dazu kommen Power-User, die schlicht schneller sind, und alle, deren Trackpad gerade streikt. Wie diese Hilfsmittel im Einzelnen funktionieren, beschreibt der Artikel über [assistive Technologien](https://barrierefreihochzwei.de/de/blog/assistive-technologien-im-web).

Tastaturbedienbarkeit ist deshalb eine der Grundlagen der Barrierefreiheit. In diesem Artikel erfährst du, worauf es ankommt: Reihenfolge, sichtbarer Fokus, Skip-Links, Tastaturfallen, modale Dialoge, eigene Komponenten und die Frage, wann ARIA hilft und wann es schadet.

## Die Grundregel: Alles erreichbar, nichts gefangen

Das Kriterium [2.1.1 Tastatur](https://barrierefreihochzwei.de/de/wcag/2-1-1-tastatur) auf Stufe A verlangt, dass sich alle Funktionen einer Website per Tastatur bedienen lassen, ohne dass bestimmte Zeitabstände zwischen Tastendrücken nötig sind. Ausgenommen sind nur Funktionen, bei denen der Bewegungspfad selbst entscheidend ist, etwa freihändiges Zeichnen.

Die Tasten, mit denen Menschen im Web navigieren, sind überschaubar:

- **Tab** und **Umschalt + Tab** springen vor und zurück zwischen Links, Buttons und Formularfeldern.
- **Enter** folgt einem Link oder löst einen Button aus.
- **Leertaste** löst Buttons aus, setzt Häkchen und scrollt die Seite.
- **Pfeiltasten** bewegen sich innerhalb von Radiogruppen, Auswahllisten, Tabs oder Menüs.
- **Escape** schließt Dialoge, Menüs und Aufklapper.

Mindestens ebenso wichtig ist [2.1.2 Keine Tastaturfalle](https://barrierefreihochzwei.de/de/wcag/2-1-2-keine-tastaturfalle). Wer mit der Tastatur in ein Element hineinkommt, muss auch wieder herauskommen. Klassische Fallen sind eingebettete Player, Karten oder Editoren, die alle Tastendrücke abfangen, sowie selbst gebaute Dialoge, bei denen der Fokus zwar hineinspringt, aber kein Weg hinausführt. Wenn zum Verlassen eine besondere Taste nötig ist, muss das klar erklärt werden.

Auch Tastenkürzel können zum Problem werden. Reagiert eine Anwendung auf einzelne Buchstaben, etwa „s“ für Suche, lösen Menschen mit Sprachsteuerung diese Aktionen versehentlich aus. Solche Kürzel müssen sich deshalb abschalten oder umbelegen lassen oder dürfen nur aktiv sein, solange das betreffende Element den Fokus hat.

## Eine logische Fokusreihenfolge

Nach [2.4.3 Fokus-Reihenfolge](https://barrierefreihochzwei.de/de/wcag/2-4-3-fokusreihenfolge) muss der Fokus in einer Reihenfolge wandern, die Sinn und Bedienung erhält. In der Regel heißt das: so, wie du die Seite liest, von oben nach unten und innerhalb von Zeilen in Leserichtung.

Die Fokusreihenfolge folgt der Reihenfolge im HTML, nicht der Darstellung. Wenn du mit CSS Grid, Flexbox und Eigenschaften wie `order` oder `flex-direction: row-reverse` Elemente visuell umsortierst, springt der Fokus plötzlich kreuz und quer. Die Lösung: Bring das HTML in die richtige Reihenfolge und nutze CSS nur für das Layout, nicht für die Logik.

Ein häufiger Grund für chaotische Reihenfolgen ist das Attribut `tabindex`. Seine drei Varianten solltest du kennen:

- `tabindex="0"` nimmt ein Element in die natürliche Tab-Reihenfolge auf. Das brauchst du nur für eigene interaktive Elemente, und die sind selten nötig.
- `tabindex="-1"` macht ein Element per JavaScript fokussierbar, ohne es in die Tab-Reihenfolge aufzunehmen. Nützlich für Überschriften, Fehlerübersichten oder Dialoginhalte, auf die du den Fokus gezielt setzt.
- Positive Werte wie `tabindex="3"` erzwingen eine eigene Reihenfolge, die praktisch nie zum Rest der Seite passt. Verzichte darauf.

Auch Inhalte, die gerade nicht sichtbar sind, dürfen keinen Fokus erhalten. Ein eingeklapptes Off-Canvas-Menü, dessen Links trotzdem per Tab erreichbar sind, lässt Menschen ins Leere navigieren. Mit `hidden`, `display: none` oder dem Attribut `inert` entfernst du solche Bereiche zuverlässig aus der Reihenfolge.

## Sichtbarer Fokus

Wer mit der Tastatur navigiert, muss jederzeit sehen, wo der Fokus gerade steht. Das verlangt [2.4.7 Fokus sichtbar](https://barrierefreihochzwei.de/de/wcag/2-4-7-fokus-sichtbar). Trotzdem findet sich in vielen Stylesheets noch immer die Zeile, die den Fokusrahmen des Browsers einfach entfernt, weil er beim Klicken mit der Maus „stört“.

Die moderne Lösung ist die Pseudoklasse `:focus-visible`. Browser zeigen sie an, wenn ein sichtbarer Fokus sinnvoll ist, also vor allem bei Tastaturbedienung, und lassen sie bei Mausklicks auf Buttons weg. So bekommst du einen deutlichen Fokus, ohne dass jemand beim Klicken Rahmen sieht.

```
/* Vorher: Fokus entfernt, Tastaturnutzer:innen sind blind */
*:focus {
  outline: none;
}

/* Nachher: deutlicher Fokus bei Tastaturbedienung */
:focus-visible {
  outline: 3px solid #0b5cad;
  outline-offset: 2px;
}

/* Platz für einen fixierten Header beim Scrollen zum Fokus */
html {
  scroll-padding-top: 5rem;
}
```

Setze dabei auf `outline` statt nur auf `box-shadow`. Im Modus „Erzwungene Farben“, etwa mit den Kontrastdesigns unter Windows, werden Schatten entfernt, ein Outline bleibt sichtbar. Wechseln sich helle und dunkle Hintergründe ab, hilft ein zweifarbiger Ring, zum Beispiel ein dunkles Outline mit hellem Schatten dahinter. Der Fokusindikator braucht ausreichend Kontrast zur Umgebung; mehr dazu im Artikel über [Kontrast und Farbe](https://barrierefreihochzwei.de/de/blog/kontrast-farbe-design-fuer-alle).

Seit WCAG 2.2 gibt es zusätzlich [2.4.11 Fokus nicht verdeckt (Minimum)](https://barrierefreihochzwei.de/de/wcag/2-4-11-fokus-nicht-verdeckt-minimum) auf Stufe AA. Das fokussierte Element darf nicht vollständig von Inhalten verdeckt werden, die du selbst platziert hast, etwa von einem fixierten Header, einem Chat-Button oder einem Cookie-Banner. Die Zeile `scroll-padding-top` im Beispiel sorgt dafür, dass aktuelle Browser beim Scrollen zum fokussierten Element genug Abstand zum Header lassen. Wer noch weiter gehen will, findet in 2.4.13 auf Stufe AAA genaue Vorgaben zu Größe und Kontrast der Fokusmarkierung.

## Skip-Links: Abkürzung zum Inhalt

Stell dir vor, du müsstest auf jeder Seite erst durch 40 Links in Header und Navigation tabben, bevor du den eigentlichen Inhalt erreichst. Genau dafür gibt es [2.4.1 Blöcke umgehen](https://barrierefreihochzwei.de/de/wcag/2-4-1-bloecke-umgehen). Die einfachste Umsetzung ist ein Skip-Link als erstes Element der Seite, der beim ersten Tab-Druck sichtbar wird.

```
<body>
  <a class="skip-link" href="#inhalt">Zum Inhalt springen</a>
  <header>…</header>
  <main id="inhalt">…</main>
</body>

<style>
  .skip-link {
    position: absolute;
    left: 1rem;
    top: -10rem;
  }
  .skip-link:focus {
    top: 1rem;
  }
</style>
```

Verstecke den Link nicht dauerhaft, denn sehende Tastaturnutzer:innen müssen ihn erkennen können. Prüfe außerdem, ob das Ziel wirklich angesprungen wird und der nächste Tab-Druck im Inhalt landet. Ergänzend helfen Landmarks wie `header`, `nav`, `main` und `footer` sowie eine saubere Überschriftenstruktur, denn Screenreader können direkt zwischen ihnen springen.

## Modale Dialoge richtig umsetzen

Modale Dialoge gehören zu den häufigsten Fehlerquellen. Ein guter Dialog setzt beim Öffnen den Fokus hinein, hält ihn dort, solange er offen ist, lässt sich mit Escape schließen und gibt den Fokus danach an das Element zurück, das ihn geöffnet hat. Der Rest der Seite darf in dieser Zeit weder fokussierbar noch für Screenreader erreichbar sein.

Früher brauchte man dafür viel JavaScript. Heute erledigt das native `dialog`-Element mit `showModal()` das meiste selbst: Es macht den Hintergrund inaktiv, verschiebt den Fokus in den Dialog, schließt per Escape, und aktuelle Browser setzen den Fokus beim Schließen zurück.

```
<button type="button" id="oeffnen">Newsletter abonnieren</button>

<dialog id="newsletter" aria-labelledby="newsletter-titel">
  <h2 id="newsletter-titel">Newsletter abonnieren</h2>
  <!-- Formularfelder -->
  <form method="dialog">
    <button>Schließen</button>
  </form>
</dialog>

<script>
  const dialog = document.getElementById("newsletter");
  document.getElementById("oeffnen")
    .addEventListener("click", () => dialog.showModal());
</script>
```

Teste trotzdem in den Browsern, die deine Zielgruppe nutzt, und achte auf einen sichtbaren Schließen-Button. Nicht jede Person weiß, dass Escape funktioniert.

## Eigene Komponenten: erst HTML, dann JavaScript

Viele Tastaturprobleme entstehen, weil interaktive Elemente aus `div` oder `span` gebaut werden. Ein `div` mit Klick-Handler sieht aus wie ein Button, ist aber per Tab nicht erreichbar, reagiert nicht auf Enter oder Leertaste und wird von Screenreadern nicht als Button angesagt. Das verletzt neben 2.1.1 auch [4.1.2 Name, Rolle, Wert](https://barrierefreihochzwei.de/de/wcag/4-1-2-name-rolle-wert).

```
<!-- Vorher: sieht aus wie ein Button, ist aber keiner -->
<div class="btn" onclick="speichern()">Speichern</div>

<!-- Nachher: fokussierbar, Enter und Leertaste inklusive -->
<button type="button" onclick="speichern()">Speichern</button>
```

Die Faustregel ist einfach: Führt ein Element zu einer anderen Adresse, ist es ein Link (`a` mit `href`). Löst es eine Aktion auf derselben Seite aus, ist es ein `button`. Beide bringen Fokus, Tastaturbedienung und die richtige Rolle kostenlos mit, und mit CSS sehen sie aus, wie du willst.

Für komplexere Widgets wie Tabs, Baumansichten oder Kombinationsfelder gibt es kein fertiges HTML-Element. Hier legen die WAI-ARIA Authoring Practices fest, welche Tasten was tun. Bei Tabs etwa ist nur der aktive Tab per Tab-Taste erreichbar, zwischen den Tabs wechselst du mit den Pfeiltasten. Dieses Prinzip heißt „Roving Tabindex“: Das aktive Element trägt `tabindex="0"`, alle anderen `tabindex="-1"`. Bevor du so etwas selbst baust, prüfe, ob ein einfacheres Muster reicht, etwa eine Reihe von Abschnitten mit Überschriften statt Tabs.

## ARIA: Wann es hilft und wann es schadet

ARIA ergänzt HTML um Rollen, Zustände und Eigenschaften, die Hilfsmitteln verraten, was ein Element ist und tut. Es ändert aber nichts am Verhalten: `role="button"` macht ein `div` weder fokussierbar noch per Tastatur bedienbar. Deshalb lautet die erste Regel für den Einsatz von ARIA: Wenn es ein natives HTML-Element mit der gewünschten Semantik und dem gewünschten Verhalten gibt, nimm dieses.

Die WAI-ARIA Authoring Practices bringen es auf den Punkt: „No ARIA is better than bad ARIA.“ Falsches ARIA ist schlimmer als keines, weil es Hilfsmitteln etwas verspricht, das die Seite nicht hält. Typische Fehler sind:

- `role="menu"` für die normale Website-Navigation. Diese Rolle kündigt ein Anwendungsmenü mit Pfeiltastensteuerung an, das die meisten Navigationen gar nicht bieten.
- `aria-hidden="true"` auf Elementen, die fokussierbar sind oder fokussierbare Inhalte enthalten. Der Fokus landet dann auf etwas, das für den Screenreader nicht existiert.
- `aria-label`, das den sichtbaren Text ersetzt, ohne ihn zu enthalten. Sprachsteuerung findet das Element dann nicht mehr über seinen sichtbaren Namen.
- Rollen ohne das dazugehörige Verhalten, etwa `role="tab"` ohne Pfeiltastensteuerung.

Wo ARIA dagegen wirklich hilft, sind Zustände, die HTML allein nicht ausdrücken kann. Ein Button, der einen Bereich auf- und zuklappt, teilt über `aria-expanded` mit, ob der Bereich gerade offen ist. `aria-current="page"` markiert in der Navigation die aktuelle Seite, und Live-Regionen sagen Statusmeldungen an.

```
<button type="button" aria-expanded="false" aria-controls="filter">
  Filter
</button>
<div id="filter" hidden>…</div>

<script>
  const knopf = document.querySelector("[aria-controls=filter]");
  const bereich = document.getElementById("filter");
  knopf.addEventListener("click", () => {
    const offen = knopf.getAttribute("aria-expanded") === "true";
    knopf.setAttribute("aria-expanded", String(!offen));
    bereich.hidden = offen;
  });
</script>
```

Für einfache Aufklapper ohne JavaScript ist übrigens das native Paar `details` und `summary` oft die bessere Wahl.

## So testest du mit der Tastatur

Ein Tastaturtest kostet wenige Minuten und braucht keine Software. Auf dem Mac musst du vorher die Tastaturnavigation in den Systemeinstellungen aktivieren und in Safari zusätzlich die Option, mit der Tab-Taste alle Elemente einer Webseite hervorzuheben. Dann gehst du so vor:

1. Lade die Seite und drücke Tab. Erscheint ein Skip-Link?
2. Tabbe durch die ganze Seite. Ist der Fokus immer sichtbar und nie verdeckt?
3. Folgt die Reihenfolge der Leserichtung, ohne Sprünge in unsichtbare Bereiche?
4. Lassen sich Menüs, Aufklapper, Slider und Formulare mit Enter, Leertaste und Pfeiltasten bedienen?
5. Öffne jeden Dialog: Landet der Fokus darin, schließt Escape ihn, und kehrt der Fokus danach zurück?
6. Kommst du aus jedem eingebetteten Element wieder heraus?

Danach lohnt sich ein Durchgang mit Screenreader, um zu hören, ob Rollen und Zustände stimmen. Wie das geht, zeigt der [Schnelltest mit Screenreader](https://barrierefreihochzwei.de/de/blog/screenreader-schnelltest).

## Checkliste

- Alle Funktionen sind per Tastatur erreichbar und bedienbar.
- Es gibt keine Tastaturfallen, auch nicht in eingebetteten Inhalten.
- Die Fokusreihenfolge folgt der Leserichtung; keine positiven `tabindex`-Werte.
- Der Fokus ist immer deutlich sichtbar und wird nicht von fixierten Elementen verdeckt.
- Ein Skip-Link führt direkt zum Hauptinhalt.
- Modale Dialoge halten den Fokus, schließen per Escape und geben ihn zurück.
- Buttons sind `button`, Links sind `a` mit `href`.
- ARIA wird nur eingesetzt, wo HTML nicht reicht, und dann mit vollständigem Tastaturverhalten.

## Fazit

Tastaturbedienbarkeit ist kein Spezialthema, sondern die Basis, auf der Screenreader, Sprachsteuerung und Schaltersteuerung aufbauen. Die meisten Probleme lassen sich mit wenigen Grundsätzen vermeiden: native Elemente verwenden, den Fokus sichtbar lassen, die Reihenfolge im HTML richtig anlegen und Dialoge mit `dialog` bauen.

Der beste Einstieg ist der eigene Test. Zieh einen Tag lang regelmäßig die Maus ab und bediene dein Produkt nur per Tastatur. Du wirst schnell merken, wo es hakt, und die meisten Lösungen sind kleiner, als du denkst. Alle Kriterien rund um Tastatur und Fokus findest du ausführlich im [WCAG-Guide](https://barrierefreihochzwei.de/de/wcag).

## Quellen

- [W3C: Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/)
- [W3C WAI: ARIA Authoring Practices Guide (APG)](https://www.w3.org/WAI/ARIA/apg/)
- [W3C: Using ARIA](https://www.w3.org/TR/using-aria/)
- [W3C: Understanding Success Criterion 2.4.7 Focus Visible](https://www.w3.org/WAI/WCAG22/Understanding/focus-visible.html)
- [WebAIM: Keyboard Accessibility](https://webaim.org/techniques/keyboard/)