Keyboard-Zugänglichkeit ist einer der kritischsten – und zugleich am meisten vernachlässigten – Aspekte der Webzugänglichkeit; Studien zeigen, dass 85% der Websites immer noch keine ausreichende Tastaturnavigation bieten. Dieser Leitfaden behandelt die WCAG-Anforderungen, häufige Fehlerbilder und praktische Techniken auf Code-Ebene, um Entwickler:innen und Compliance-Verantwortliche dabei zu unterstützen, wirklich tastaturnavigierbare Erlebnisse zu schaffen.

Stell dir vor, du versuchst, eine Bewerbung auszufüllen, einen Arzttermin zu buchen oder einen Online-Kauf abzuschließen – und deine Maus funktioniert nicht. Nicht kaputt, nur irrelevant: Du navigierst ausschließlich mit Tab, Enter und den Pfeiltasten. Für Millionen von Menschen weltweit ist das kein Gedankenexperiment. Menschen mit motorischen Behinderungen, Sehnenscheidenentzündungen, Sehbeeinträchtigungen und alle, die auf Screenreader angewiesen sind, nutzen die Tastaturnavigation als primäre Schnittstelle zum Web. Dennoch zeigen Studien immer wieder, dass 85% der Websites keine ausreichende Tastaturnavigation bieten und diese Nutzer:innen damit jeden Tag von grundlegenden digitalen Aufgaben ausschließen. Wenn deine Website zu dieser Mehrheit gehört, ist dieser Leitfaden für dich.

Wer auf Tastaturnavigation angewiesen ist – und warum das wichtiger ist, als du denkst

Tastaturzugänglichkeit ist kein Nischenthema für eine kleine Nutzergruppe. Die Menschen, die darauf angewiesen sind, sind zahlreicher und vielfältiger, als die meisten Entwickler:innen ahnen. Menschen mit körperlichen Behinderungen, die keine Maus nutzen können, blinde Menschen, die den Mauszeiger auf dem Bildschirm nicht sehen können, und Menschen mit chronischen Erkrankungen wie Sehnenscheidenentzündungen, die ihre Mausnutzung einschränken sollten, sind alle auf Tastaturnavigation als ihr Tor zum Web angewiesen. Über Behinderungen hinaus bevorzugen viele Power-User – Entwickler:innen, Autor:innen, Datenerfasser:innen – Tastaturkürzel wegen Geschwindigkeit und Effizienz.

Screenreader-Nutzer:innen stellen eine weitere große Gruppe dar. Screenreader interpretieren und geben Seitenelemente basierend auf Fokus und semantischer Struktur aus, und Nutzer:innen bewegen sich mit Tastenkombinationen durch Inhalte. Wenn eine Website den Tastaturfokus nicht beibehält oder keine logische Fokusreihenfolge unterstützt, bricht die Screenreader-Navigation vollständig zusammen. Spracherkennungssoftware wie Dragon NaturallySpeaking erzeugt ebenfalls Tastaturereignisse, was bedeutet, dass schlechte Tastaturunterstützung auch sprachgesteuertes Browsen beeinträchtigt.

Auch aus geschäftlicher Sicht ist das Thema überzeugend. Laut verfügbaren Daten verfügen Menschen mit Behinderungen in den USA über nahezu eine halbe Billion Dollar an verfügbarem Einkommen. Wenn deine Website nicht tastaturzugänglich ist, weist du aktiv einen erheblichen Teil dieses Marktes ab. Das rechtliche Risiko ist ebenfalls real: Tastaturzugänglichkeit ist essenziell für die Konformität mit WCAG, dem Maßstab für die Einhaltung des ADA, Section 508, des European Accessibility Act und EN 301 549 weltweit. Allein Tastaturfallen – bei denen ein:e Nutzer:in in einem Seitenelement feststeckt und nicht mehr herauskommt – gelten als eindeutige WCAG-Verstöße, die in Barrierefreiheitsklagen eine Rolle gespielt haben.

Vielleicht am aussagekräftigsten: 71% der behinderten Nutzer:innen verlassen eine Website einfach, wenn sie sie schwer zu bedienen finden. Sie beschweren sich nicht. Sie gehen. Und da Probleme mit der Tastaturzugänglichkeit typischerweise an den kritischsten Interaktionspunkten auftreten – Formulare, Modale, Navigationsmenüs und Checkout-Flows – trifft der Schaden direkt deine Conversion-Rates.

Der WCAG-Rahmen: Was die Regeln tatsächlich verlangen

Die Web Content Accessibility Guidelines (WCAG) ordnen Tastaturanforderungen hauptsächlich der Richtlinie 2.1 zu – „Make all functionality available from a keyboard“. Zu verstehen, was verlangt wird und was nicht, ist der erste Schritt zur Konformität. WCAG 2.2, das am 5. Oktober 2023 zum offiziellen W3C-Standard wurde und neun neue Erfolgskriterien zum bestehenden Rahmen hinzufügte, ist nun der empfohlene Standard für ADA, Section 508 und den European Accessibility Act.

Die wichtigsten tastaturbezogenen Erfolgskriterien, die du kennen musst, sind:

SC 2.1.1 Keyboard (Level A): Alle Funktionalitäten müssen über eine Tastaturschnittstelle bedienbar sein, ohne dass spezifisches Timing für einzelne Tastenanschläge erforderlich ist, außer wenn die zugrunde liegende Funktion pfadabhängige Eingaben erfordert (wie freihändiges Zeichnen). Dies ist die Basis – jedes interaktive Element muss per Tastatur erreichbar und bedienbar sein.
SC 2.1.2 No Keyboard Trap (Level A): Wenn der Tastaturfokus mit der Tastatur auf eine Komponente verschoben werden kann, muss der Fokus auch ausschließlich mit der Tastatur wieder davon weg bewegt werden können. Wenn eine nicht standardmäßige Methode zum Verlassen erforderlich ist, müssen Nutzer:innen darüber informiert werden. Tastaturfallen sind ein absoluter Blocker für Tastaturnutzer:innen.
SC 2.4.3 Focus Order (Level A): Wenn eine Webseite sequentiell navigierbar ist, muss die Fokusreihenfolge Bedeutung und Bedienbarkeit erhalten. Eine logische, vorhersehbare Tab-Reihenfolge ist unverzichtbar.
SC 2.4.7 Focus Visible (Level AA): Jede per Tastatur bedienbare Benutzeroberfläche muss einen Modus haben, in dem der Tastaturfokus-Indikator sichtbar ist. Nutzer:innen müssen jederzeit sehen können, wo sie sich auf der Seite befinden.
SC 2.4.11 Focus Not Obscured (Minimum) (Level AA – neu in WCAG 2.2): Wenn ein tastaturfokussierbares Element Fokus erhält, darf es nicht vollständig durch vom Autor erstellte Inhalte wie Sticky-Header oder Cookie-Banner verdeckt werden.
SC 2.4.12 Focus Not Obscured (Enhanced) (Level AAA): Eine strengere Version, die verlangt, dass kein Teil der fokussierten Komponente durch vom Autor erstellte Inhalte verdeckt wird.
SC 2.5.8 Target Size (Minimum) (Level AA – neu in WCAG 2.2): Interaktive Ziele müssen mindestens 24x24 CSS-Pixel groß sein, um Fehler bei Nutzer:innen mit eingeschränkter Motorik zu reduzieren.
SC 2.5.7 Dragging Movements (Level AA – neu in WCAG 2.2): Jede Funktionalität, die Dragging erfordert, muss eine Alternative mit einem einzelnen Zeiger haben – was indirekt auch Tastaturnutzer:innen zugutekommt, die keine Drag-Operationen ausführen können.

WCAG 2.2 ist vollständig abwärtskompatibel mit WCAG 2.1 – es fügt Kriterien hinzu, entfernt aber keine (mit Ausnahme des nun obsoleten 4.1.1 Parsing). Wenn deine Website bereits WCAG 2.1 AA erfüllt, musst du nur die sechs neuen Level-AA-Kriterien implementieren. Speziell für Tastaturzugänglichkeit ist die große neue Ergänzung, sicherzustellen, dass fokussierte Elemente niemals vollständig von Sticky-Seitenelementen verdeckt werden – ein häufiges Problem in der Praxis, das WCAG 2.1 nicht explizit adressiert hat.

Das WCAG-Prinzip ist einfach zu formulieren, aber anspruchsvoll umzusetzen: Wenn alle Funktionalitäten mit der Tastatur erreicht werden können, können sie von Tastaturnutzer:innen, Sprachsteuerung, Bildschirmtastaturen und einer Vielzahl von Hilfstechnologien genutzt werden, die simulierte Tastenanschläge erzeugen. Keine andere Eingabeform ist so flexibel oder wird so universell unterstützt.

Die häufigsten Fehler bei der Tastaturzugänglichkeit (und was sie verursacht)

Manuelle Audits zeigen immer wieder, dass Probleme mit der Tastaturzugänglichkeit zu den häufigsten und störendsten Barrieren im Web gehören. In einer groß angelegten Studie hatten 54% der Seiten mit Formularen Tastaturzugänglichkeitsprobleme, die kritische Nutzeraktionen wie das Tabben zwischen Formularfeldern, das Schließen von Pop-up-Fenstern oder das Drücken von Absenden-Buttons beeinträchtigten. Tester:innen waren häufig gezwungen, Warenkörbe aufzugeben oder Seiten neu zu laden, nachdem sie an Elementen hängen geblieben waren, die sie nur mit der Tastatur nicht steuern konnten.

Die Ursachen konzentrieren sich auf einige wiederkehrende Muster, die es sich lohnt, genauer anzusehen.

1. Nur-Maus-Event-Handler. Die Verwendung von onmouseover, onmouseout oder onclick auf <div>-Elementen ohne entsprechende Tastatur-Event-Handler ist einer der häufigsten Fehler. Ein <div> mit einem Click-Handler ist kein Button – es hat keine implizite Tastaturrolle, erhält keinen Fokus über Tab und reagiert nicht auf Enter oder Leertaste. Das Hinzufügen von role='button' über ARIA hilft Screenreadern, erfordert aber weiterhin, dass du tabindex='0', onkeydown und onkeyup manuell hinzufügst. Die richtige Lösung ist fast immer, ein echtes <button>-Element zu verwenden.

2. Unterdrückte Fokusrahmen. Eines der am weitesten verbreiteten Probleme ist die CSS-Regel outline: none oder outline: 0, global oder auf fokussierte Elemente angewendet. Designer:innen entfernen häufig den standardmäßigen Fokusrahmen des Browsers, weil er in bestimmten Themes unschön aussieht. Das Ergebnis ist, dass Tastaturnutzer:innen nicht wissen, wo sie sich auf der Seite befinden. Dies ist ein direkter Verstoß gegen WCAG SC 2.4.7 und eines der am leichtesten zu verursachenden – und zu behebenden – Probleme.

3. Tastaturfallen in Modalen, Widgets und iframes. Modale Dialoge, die den Fokus nicht korrekt einschränken, lassen Tab einfach am Modal vorbei in verdeckte Hintergrundinhalte weiterlaufen, sodass das Modal per Tastatur nicht mehr geschlossen werden kann. Drittanbieter-Widgets – Chat-Tools, Videoplayer, Datepicker, Karten-Einbettungen – sind dafür besonders anfällig, weil ihre interne Tastaturbehandlung für dich intransparent ist.

4. Unlogische Tab-Reihenfolge. Die standardmäßige Tastaturnavigationsreihenfolge wird durch die DOM-Quellreihenfolge bestimmt. Wenn Entwickler:innen CSS Grid, Flexbox oder CSS-Positionierung verwenden, um die visuelle Darstellung unabhängig von der DOM-Reihenfolge umzuordnen, springt der Tab-Fokus über den Bildschirm, auf eine Weise, die von der visuellen Anordnung völlig entkoppelt ist. Positive tabindex-Werte (z. B. tabindex='2'), die eine bestimmte Reihenfolge erzwingen sollen, verschlimmern dieses Problem in den meisten realen Fällen erheblich.

5. Nur-Hover-Dropdown-Menüs. Navigationsmenüs, die sich nur bei Maus-Hover öffnen und keinen Tastaturauslöser haben, lassen Tastaturnutzer:innen im Stich. Dies ist ein extrem häufiges Muster in reinen CSS-Dropdown-Menüs, bei denen Untermenüs bei :hover erscheinen, aber nie für fokusbasierte Navigation zugänglich sind.

6. Fokus wird nach dynamischen Interaktionen nicht zurückgegeben. Wenn ein Modal, Drawer oder Flyout geschlossen wird, muss der Fokus zu dem Element zurückkehren, das es ausgelöst hat. Wenn das nicht passiert – wenn er am Seitenanfang landet oder in einer unbestimmten Position verschwindet – sind Nutzer:innen völlig orientierungslos. Dynamische Single-Page-Applications sind dafür besonders anfällig.

Tastaturzugänglichkeit richtig umsetzen: Praktische Implementierung

Mit den Fehlermustern im Hinterkopf sieht korrekte Implementierung in den wichtigsten Bereichen einer typischen Website wie folgt aus.

Verwende zuerst semantisches HTML

Native HTML-Elemente sind standardmäßig tastaturzugänglich. Links (<a href>), Buttons (<button>), Formulareingaben, Selects und Textareas nehmen alle an der Tab-Reihenfolge teil, reagieren auf Standard-Tastendrücke und kommunizieren ihre Rolle an Hilfstechnologien – ganz ohne zusätzliche JavaScript-Zeile. Ein <button>-Element hat automatisch die richtige Rolle, ist tastaturzugänglich, reagiert auf Enter und Leertaste und verfügt über ein eingebautes Fokusmanagement. Das Hinzufügen von role='button' zu einem <div> gibt zwar die richtige Rolle, erfordert aber weiterhin, dass du Tastaturunterstützung und Fokusmanagement manuell implementierst. Bevorzuge immer semantisches HTML.

<!-- Avoid: non-semantic div pretending to be a button -->
<div onclick='doSomething()' class='btn'>Submit</div>

<!-- Correct: native button element -->
<button type='button' onclick='doSomething()'>Submit</button>

Repariere deine Fokusindikatoren

Anstatt den standardmäßigen Outline des Browsers zu entfernen, überschreibe ihn mit einem gestalteten, benutzerdefinierten Fokusindikator. WCAG 2.2 SC 2.4.11 verlangt, dass der Bereich des Fokusindikators mindestens so groß ist wie ein 2 CSS-Pixel dicker Rand der nicht fokussierten Komponente, mit einem Kontrastverhältnis von mindestens 3:1 zwischen fokussiertem und nicht fokussiertem Zustand. Verwende die Pseudoklasse :focus-visible statt :focus, um Fokusindikatoren nur für Tastaturnutzer:innen anzuzeigen, ohne die Ästhetik der Mausinteraktion zu beeinträchtigen.

/* Remove default only to replace with better indicator */
*:focus {
  outline: none;
}

*:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 3px;
  border-radius: 2px;
}

Dieser Ansatz gibt dir vollständige visuelle Kontrolle und erhält gleichzeitig die WCAG-Konformität. Stelle sicher, dass die Fokusfarbe ausreichenden Kontrast sowohl zum Hintergrund als auch zur Komponente selbst hat, insbesondere bei Dark-Themes oder über Bildern.

Fokus bei dynamischen Interaktionen steuern

Wenn sich Inhalte dynamisch ändern – ein Modal öffnet sich, neue Inhalte werden geladen, ein Element wird entfernt – musst du den Fokus programmatisch steuern. Beim Öffnen eines Modals verschiebe den Fokus auf das erste fokussierbare Element darin. Beim Schließen gib den Fokus an das auslösende Element zurück. Verwende dafür die JavaScript-Methode .focus(). Um den Fokus korrekt innerhalb eines Modals zu halten, fange Tab- und Shift+Tab-Tastenereignisse ab und zyklisiere den Fokus zwischen dem ersten und letzten fokussierbaren Element im Dialog.

// Opening a modal: move focus inside
function openModal(modalEl, triggerEl) {
  modalEl.removeAttribute('hidden');
  const firstFocusable = modalEl.querySelector(
    'button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])'
  );
  if (firstFocusable) firstFocusable.focus();
}

// Closing a modal: return focus to trigger
function closeModal(modalEl, triggerEl) {
  modalEl.setAttribute('hidden', '');
  triggerEl.focus();
}

Skip-Navigation-Links implementieren

Tastaturnutzer:innen müssen bei jedem Seitenaufruf mit Tab durch jedes interaktive Element vor dem Hauptinhalt – Header, Navigationsmenüs, Suchleisten – navigieren. Skip-Links sind die Lösung: ein visuell versteckter Link ganz oben auf der Seite, der beim Fokus sichtbar wird und Nutzer:innen direkt zum Hauptinhaltsbereich springen lässt. Sie sind eine WCAG-Anforderung auf Level A und eines der wirkungsvollsten Quick Wins.

<!-- Place as the first element in <body> -->
<a href='#main-content' class='skip-link'>Skip to main content</a>

<!-- Target anchor on the main content container -->
<main id='main-content' tabindex='-1'>
  <!-- page content -->
</main>

/* Show skip link only on keyboard focus */
.skip-link {
  position: absolute;
  top: -40px;
  left: 0;
  background: #000;
  color: #fff;
  padding: 8px 16px;
  z-index: 100;
  transition: top 0.2s;
}

.skip-link:focus {
  top: 0;
}

Zugängliche Navigationsmenüs erstellen

Navigationsmenüs mit Dropdown-Untermenüs erfordern besondere Aufmerksamkeit. Das korrekte Tastatur-Interaktionsmuster für ein Navigationsmenü ist: Tab bewegt sich zwischen den obersten Einträgen; Enter oder Leertaste öffnet ein Untermenü; Pfeiltasten navigieren innerhalb des Untermenüs; Escape schließt das Untermenü und gibt den Fokus an den Auslöser zurück. Verwende ARIA-Attribute, um den Zustand zu kommunizieren. Menüs, die sich nur bei Hover öffnen und keinen Tastaturauslöser haben, sind nicht zugänglich und müssen korrigiert werden.

<nav aria-label='Main navigation'>
  <ul role='menubar'>
    <li role='none'>
      <button
        aria-haspopup='true'
        aria-expanded='false'
        aria-controls='products-menu'>
        Products
      </button>
      <ul role='menu' id='products-menu' hidden>
        <li role='none'>
          <a role='menuitem' href='/software'>Software</a>
        </li>
        <li role='none'>
          <a role='menuitem' href='/hardware'>Hardware</a>
        </li>
      </ul>
    </li>
  </ul>
</nav>

Verwende aria-expanded='false' und aria-expanded='true', per JavaScript umgeschaltet, um den geöffneten/geschlossenen Zustand zu kommunizieren. Verwende aria-haspopup='true', um anzuzeigen, dass das Aktivieren des Buttons ein Untermenü öffnet. Stelle sicher, dass die Escape-Taste das Untermenü schließt und den Fokus zum Button-Auslöser zurückbringt.

tabindex korrekt verwenden

Es gibt drei sinnvolle Werte für tabindex, und jeder hat einen eigenen Zweck. tabindex='0' fügt ein nicht interaktives Element in die natürliche Tab-Reihenfolge ein – verwende dies, wenn du wirklich ein normalerweise nicht fokussierbares Element (wie einen Container für ein benutzerdefiniertes Widget) fokussierbar machen musst. tabindex='-1' entfernt ein Element aus der Tab-Reihenfolge, erlaubt aber, dass es programmatisch über .focus() Fokus erhält – essenziell für Modal-Ziele und Skip-Link-Zielbereiche. Positive tabindex-Werte (wie tabindex='1' oder tabindex='5') überschreiben die natürliche Reihenfolge auf eine Weise, die fast immer mehr Probleme verursacht als löst; vermeide sie vollständig und korrigiere stattdessen die DOM-Reihenfolge.

ARIA: Ein mächtiges Werkzeug, aber kein Allheilmittel

Accessible Rich Internet Applications (ARIA)-Attribute erweitern die Semantik von HTML, damit Hilfstechnologien benutzerdefinierte Komponenten verstehen können, die von nativen HTML-Elementen nicht abgedeckt werden – Tabs, Akkordeons, Treeviews, Karussells, Kombinationsfelder. ARIA-Attribute können zusätzlichen Kontext liefern, sollten aber semantisches HTML ergänzen – nicht ersetzen. Ein häufiger und gefährlicher Fehler ist, zu ARIA zu greifen, bevor geprüft wird, ob ein natives HTML-Element die Aufgabe nicht ebenso gut erfüllen könnte.

Die erste Regel von ARIA lautet: Verwende ARIA nicht, wenn ein natives HTML-Element oder Attribut dieselbe Aufgabe erfüllen kann. Die zweite Regel: Kein ARIA ist besser als schlechtes ARIA. Falsches ARIA-Markup – zum Beispiel role='menu' ohne die korrekte Hierarchie von role='menuitem'-Kindern oder aria-hidden='true' auf einem Element, das Fokus erhält – kann Barrierefreiheit aktiv verschlechtern statt verbessern.

Wenn ARIA wirklich benötigt wird, sind die nützlichsten Attribute für Tastaturinteraktionen: aria-expanded, um den geöffneten/geschlossenen Zustand von ausklappbaren Elementen zu kommunizieren; aria-controls, um einen Auslöser mit den Inhalten zu verknüpfen, die er steuert; aria-haspopup, um anzuzeigen, dass ein Button ein Menü oder einen Dialog öffnet; aria-modal='true' auf Dialogelementen, um anzuzeigen, dass Hintergrundinhalte inaktiv sind; und aria-live-Regionen (polite für Statusmeldungen, assertive für dringende Warnungen), um dynamische Inhaltsänderungen Screenreader-Nutzer:innen anzukündigen, ohne den Fokus zu verschieben.

Ein subtiler, aber wichtiger Aspekt: Screenreader wie NVDA und JAWS verwenden eigene Tastaturkürzel – zum Beispiel springt H in NVDA zur nächsten Überschrift auf der Seite. Entwickler:innen sollten vermeiden, benutzerdefinierte Anwendungskürzel zu erstellen, die mit diesen Befehlen von Hilfstechnologien kollidieren.

Tests auf Tastaturzugänglichkeit

Der mit Abstand effektivste Test, den du jetzt sofort durchführen kannst, benötigt keine Tools: Zieh deine Maus ab und navigiere deine Website ausschließlich mit der Tastatur. Drücke Tab, um vorwärts durch interaktive Elemente zu gehen, Shift+Tab, um rückwärts zu gehen, Enter, um Links und Buttons zu aktivieren, Leertaste, um Checkboxen umzuschalten und Buttons zu aktivieren, Escape, um Modale und Menüs zu schließen, und Pfeiltasten, um innerhalb von Komponenten zu navigieren. Frage dich: Kannst du jedes interaktive Element erreichen? Kannst du jederzeit sehen, wo du dich befindest? Kannst du jede kritische User Journey abschließen, ohne steckenzubleiben?

Automatisierte Tools können einen bedeutenden Teil der Tastaturzugänglichkeitsprobleme erkennen – insbesondere fehlende Labels, leere Buttons und einige Fokusmanagement-Probleme. Tools wie axe DevTools, WAVE und Lighthouse sind wertvolle erste Schritte. Allerdings erkennen automatisierte Tools nur etwa 40% der WCAG-Probleme. Fokus-Sichtbarkeit, logische Fokusreihenfolge und korrektes ARIA-Zustandsmanagement erfordern alle manuelle menschliche Bewertung. Für die gründlichste Bewertung kombiniere automatisiertes Scannen mit manuellen Tastatur-Only-Tests in mehreren Browsern und ergänze sie durch Screenreader-Tests mit NVDA (Windows), JAWS (Windows) oder VoiceOver (macOS/iOS).

Einige spezifische Szenarien, die du bei jeder neuen Komponente oder Seite manuell testen solltest: Kannst du jedes Dropdown, jedes Modal und jedes Akkordeon ausschließlich mit Tab, Enter und Escape öffnen und schließen? Wenn ein Modal geschlossen wird, kehrt der Fokus zum Auslöser zurück? Erscheint der Skip-Navigation-Link beim ersten Tab-Druck und funktioniert er? Gibt es Stellen, an denen der Tab-Fokus in einem Element verschwindet, ohne dass ein sichtbarer Indikator vorhanden ist? Verdecken Sticky-Header oder Cookie-Banner fokussierte Elemente, während du dich mit Tab durch die Seite bewegst?

Für Teams, die Komponentenbibliotheken entwickeln, ist der WAI-ARIA Authoring Practices Guide (APG) des W3C die maßgebliche Referenz für Tastatur-Interaktionsmuster bei Dutzenden von Widget-Typen – von Akkordeons und Karussells bis hin zu Datepickern und Treeviews. Jedes Muster legt genau fest, welche Tasten unterstützt werden müssen und welches Verhalten erwartet wird.

Sticky-Header, feste Footer und verdeckter Fokus

Einer der praktisch relevantesten neuen Anforderungen in WCAG 2.2 ist Erfolgskriterium 2.4.11: Focus Not Obscured. Es adressiert ein Problem, das so häufig ist, dass es das moderne Web praktisch definiert: Sticky-Navigationsleisten, Cookie-Consent-Banner, Chat-Widgets und feste Footer, die über Seiteninhalten liegen. Wenn ein Tastaturnutzer zu einem Element tabbt, das hinter einer dieser fixierten Ebenen gescrollt wurde, wird das fokussierte Element unsichtbar – die Person kann nicht sehen, womit sie interagiert.

Die Lösung erfordert eine Abstimmung zwischen CSS und JavaScript. Wenn ein Element Fokus erhält, muss der Browser es in einen sichtbaren Bereich scrollen. Aber ein Sticky-Header mit position: fixed und einer Höhe von beispielsweise 80px bedeutet, dass die oberen 80px des Viewports dauerhaft belegt sind. CSS Scroll Padding kann das ausgleichen:

html {
  /* Height of your sticky header + a small buffer */
  scroll-padding-top: 96px;
}

Dies teilt dem Browser mit, die Scroll-Verankerung um den angegebenen Betrag zu versetzen, sodass beim automatischen Scrollen eines fokussierten Elements in den sichtbaren Bereich der fixe Header berücksichtigt wird. Du benötigst möglicherweise auch ein entsprechendes scroll-padding-bottom, wenn du einen Sticky-Footer hast. Für Cookie-Banner oder Overlays, die erscheinen und verschwinden, stelle sicher, dass sie z-index-Werte haben, die das fokussierte Element nicht überdecken, oder passe das Scroll Padding dynamisch an, wenn das Banner sichtbar ist.

Wesentliche Erkenntnisse

Semantisches HTML ist dein bester erster Schritt. Native Elemente wie <button>, <a> und Formularelemente sind standardmäßig tastaturzugänglich. Jedes benutzerdefinierte Widget, das aus divs gebaut ist, kostet dich Barrierefreiheit, die du dann mühsam mit ARIA und JavaScript nachbauen musst.
Unterdrücke niemals Fokusindikatoren, ohne sie zu ersetzen. Die globale Regel outline: none ist eine der schädlichsten Dinge, die du in ein Stylesheet schreiben kannst. Verwende :focus-visible, um einen gestalteten, kontrastreichen Fokusring bereitzustellen, der die Mindestanforderungen von WCAG 2.2 an Größe und Kontrast erfüllt.
Steuere den Fokus programmatisch bei jeder dynamischen Interaktion. Modale, Drawer, Toast-Benachrichtigungen und dynamische Inhaltsänderungen erfordern alle explizites Fokusmanagement – Fokus hinein verschieben und beim Schließen zurückgeben. Ohne dies verlieren Tastaturnutzer:innen bei jeder UI-Änderung ihre Position.
Füge am Anfang jeder Seite einen Skip-Navigation-Link hinzu. Er benötigt weniger als 20 Zeilen Code und verbessert die Erfahrung für Tastaturnutzer:innen drastisch, die sonst bei jedem Seitenaufruf durch deinen gesamten Header und deine Navigation tabben müssten.
Teste mit deiner Tastatur, bevor du auslieferst. Automatisierte Tools erkennen nur einen Bruchteil der Probleme mit der Tastaturzugänglichkeit. Ein zehnminütiger Tastatur-Only-Durchlauf deiner wichtigsten User Journeys deckt echte Blocker auf, die kein Scanner findet – und kann von jeder Entwickler:in im Team ohne Spezialschulung durchgeführt werden.

Tastaturzugänglichkeit: So machen Sie Ihre Website vollständig per Tastatur navigierbar