Sichtbarer Fokus und Tastaturnavigation: das übersehene Accessibility-Fundament

Tastaturnavigation betrifft nicht nur Screenreader. Sie entscheidet, ob eine Website für alle nutzbar ist, die keine Maus verwenden, vorübergehend oder dauerhaft, und dient zugleich als Robustheitstest für die gesamte Oberfläche. Sichtbarer Fokus und eine kohärente Tab-Reihenfolge bilden das kostenwirksamste Accessibility-Fundament überhaupt, und eines der am häufigsten vernachlässigten.

#Die Tastatur legt die Struktur offen

Auf einer sauber gebauten Seite bewegt die Tab-Taste den Fokus von einem interaktiven Element zum nächsten, in der Reihenfolge, in der sie im Dokument stehen. Native Elemente (ein a mit href, button, Formularfelder) sind ohne Konfiguration fokussierbar. Ein div, dem ein Click-Handler aufgepfropft wurde, ist es nicht: Es bleibt für die Tastatur unsichtbar, solange es keine Rolle und keine Tastenbehandlung erhält.

Eine Website allein mit der Tastatur zu durchlaufen, offenbart daher in Sekunden, was kein Screenshot zeigt: ein Menü, das sich nicht erreichen lässt, ein Phantom-Button aus einem klickbaren Bild, ein Karussell, das den Fokus einsperrt. Die Tastatur testet nicht nur die Barrierefreiheit, sie testet die Solidität des Markups.

#:focus-visible statt den Umriss zu entfernen

Der häufigste Fehler passt in eine einzige Deklaration: outline: none, gesetzt, um den beim Klick als unschön empfundenen blauen Ring zu tilgen. Damit nimmt man Tastaturnutzern zugleich den einzigen Hinweis darauf, wo sie sich befinden. Die Lösung besteht nicht darin, den alten Umriss überall wiederherzustellen, sondern ihn dem richtigen Kontext vorzubehalten.

Die Pseudoklasse :focus-visible überlässt dem Browser die Entscheidung: Er zeigt den Ring, wenn er den Fokus als von der Tastatur kommend einschätzt, und blendet ihn bei einem Mausklick aus. Der Umriss erscheint so nur dort, wo er nützt.

/* Ne jamais retirer le contour sans le remplacer. */
:focus-visible {
  outline: 3px solid #2d6cdf;
  outline-offset: 2px;
  border-radius: 2px;
}

/* Souris : pas d'anneau ; clavier : anneau visible. */
:focus:not(:focus-visible) {
  outline: none;
}

/* Lien d'evitement : masque, revele au focus clavier. */
.skip-link {
  position: absolute;
  left: -9999px;
}
.skip-link:focus {
  left: 1rem;
  top: 1rem;
}

Die Regel gilt für jede interaktive Komponente, benutzerdefinierte Elemente eingeschlossen. Ein Ring von mindestens drei Pixeln, deutlich zum Hintergrund kontrastiert und durch einen outline-offset vom Element abgehoben, bleibt auf den meisten Flächen lesbar.

Eine Website, die sich nicht vollständig per Tastatur durchlaufen lässt, hat einen funktionalen Mangel, nicht bloß einen Accessibility-Mangel.

#Die Tab-Reihenfolge folgt dem DOM

Die Reihenfolge, in der der Fokus die Elemente besucht, ist die des Quelltexts, nicht die der Darstellung. Ein per CSS visuell verschobener Block (etwa mit order in einem Grid) behält seine ursprüngliche Position in der Tab-Folge. Wenn visuelle und DOM-Reihenfolge auseinanderlaufen, wird die Navigation verwirrend: Besser die Struktur korrigieren, als sie mit der Tastatur zu überdecken.

Zwei Werkzeuge decken die überwiegende Mehrheit der Fälle ab. Der Sprunglink, das erste fokussierbare Element der Seite, erlaubt es, die Navigation zu überspringen und zum Inhalt zu gelangen. Das Attribut tabindex="-1" macht ein Ziel programmatisch fokussierbar, ohne es in die Tab-Reihenfolge einzufügen.

<!-- Premier element focusable de la page -->
<a class="skip-link" href="#contenu">Aller au contenu</a>

<nav>…</nav>

<!-- tabindex="-1" rend la cible focusable par programme,
     sans l'ajouter a l'ordre de tabulation. -->
<main id="contenu" tabindex="-1">
  <h1>Titre de la page</h1>
</main>

Eine Regel hält alles zusammen: niemals ein positives tabindex verwenden. tabindex="1", "2" und so weiter zu setzen, erzwingt eine künstliche Reihenfolge, die sich bei der ersten Ergänzung vom Inhalt löst und unpflegbar wird. Die einzigen sinnvollen Werte sind 0 (fokussierbar in natürlicher Reihenfolge) und -1 (nur programmatisch fokussierbar).

#Maßgeschneiderte Komponenten, wo es bricht

Dropdown-Menüs, Tabs, Dialoge: Sobald sich eine Komponente von den nativen Elementen entfernt, wird die Tastaturbehandlung explizit. Ein modaler Dialog muss insbesondere den Fokus halten, solange er geöffnet ist, sonst wandert die Tab-Folge zurück in die dahinterliegende Seite, außer Sichtweite.

// Piege de focus minimal pour une boite de dialogue.
function piegerFocus(dialogue) {
  const focusables = dialogue.querySelectorAll(
    'a[href], button:not([disabled]), input, select, textarea, [tabindex]:not([tabindex="-1"])'
  );
  const premier = focusables[0];
  const dernier = focusables[focusables.length - 1];

  dialogue.addEventListener('keydown', (e) => {
    if (e.key !== 'Tab') return;
    if (e.shiftKey && document.activeElement === premier) {
      e.preventDefault();
      dernier.focus();
    } else if (!e.shiftKey && document.activeElement === dernier) {
      e.preventDefault();
      premier.focus();
    }
  });
}

Die Fokusfalle ist nur die Hälfte des Vertrags. Beim Öffnen sollte der Fokus auf den Dialog oder sein erstes Feld gehen; beim Schließen sollte er zu dem Element zurückkehren, das ihn ausgelöst hat; die Escape-Taste sollte den Dialog schließen. Ohne diesen vollständigen Zyklus bleibt das Modal eine Falle für den Tastaturnutzer.

#Formulare: verknüpfte Beschriftungen und Fokus auf den Fehler

Formulare bündeln die meisten Tastaturinteraktionen und einen guten Teil der Mängel. Jedes Feld muss mit einem expliziten label verbunden sein, über das Attribut for, das auf die id des Felds zeigt: Ein Klick auf die Beschriftung fokussiert dann das Feld, und assistive Technologien geben den richtigen Namen aus. Ein placeholder ersetzt keine Beschriftung, da er verschwindet, sobald getippt wird.

Bei der Validierung sollte der Fokus auf das erste fehlerhafte Feld springen, und die zugehörige Meldung mit aria-describedby an das Feld gebunden sein. So wird der Tastaturnutzer direkt zum Problem geführt, ohne das ganze Formular erneut durchzutabben.

#Welcher Selektor für welchen Bedarf

#Das Wichtigste in Kürze

• Tastaturnavigation ist ein Robustheitstest für die gesamte Oberfläche, keine Option für eine Minderheit.
• :focus-visible behält den Fokusring der Tastatur vor, ohne ihn für alle zu entfernen.
• Die Tab-Reihenfolge folgt dem DOM; ein Sprunglink und ein auf 0 und -1 begrenztes tabindex genügen.
• Maßgeschneiderte Komponenten brauchen eine explizite Fokusbehandlung, modale Dialoge vor allem.

#Weiterführend

Referenz: :focus-visible auf MDN Web Docs, und das WCAG-Erfolgskriterium 2.4.7 „Fokus sichtbar“.

#Ebenfalls auf Mail Studio

• Design Tokens: ein helles und dunkles Theme, das hält
• CSS Anchor Positioning: Menüs, Tooltips und Popovers ohne JavaScript