Praxisleitfaden Scrollbereiche und Tastatur

Scrollbereiche per Tastatur bedienen

Machen Sie verborgene Protokollzeilen auch ohne Maus erreichbar.

scrollable-region-focusableWCAG 2.1.1, 2.1.3

Sehen Sie, was sich durch die Korrektur ändert.

Beispiel im Prüfbericht
Markierter Befund · Kritisch · WCAG 2.1.1, 2.1.3Protokoll ohne expliziten Fokuszugang

Befund verstehen

Das Protokoll ist länger als sein Sichtfenster

Erkannter Befund

  1. Das fällt auf

    scrollable-region-focusable meldet .lab-panel > div: Der Scrollbereich und sein Inhalt besitzen keinen expliziten Tastaturfokus.

  2. So ist es einzuordnen

    In der Maschinenakte steht ein Schrittprotokoll in einem 46 Pixel hohen Fenster. Der innere Inhalt ist 224 Pixel hoch. Die Schritte bis „Bühne leeren“ liegen unter dem sichtbaren Rand; der Container hat kein tabindex und enthält nur Text.

  3. Das bedeutet es für die Nutzung

    Wer die Maus nicht bedienen kann, braucht einen Tastaturzugang zum Scrollen. Manche Browser nehmen Scrollbereiche selbstständig in die Tabfolge auf. Darauf allein sollte die Bedienbarkeit dieses Protokolls nicht beruhen.

Regel
scrollable-region-focusable
Referenz
WCAG 2.1.1, 2.1.3
Diagnose vor der Korrektur
.lab-panel > div
Überlauf: vertikal
Sichtfenster: 46 px · Inhalt: 224 px
tabindex: fehlt · fokussierbarer Inhalt: keiner
Axe: Verstoß (serious)

Protokollfenster als Komponente nachprüfen

Ein gemeinsamer Scrollcontainer kann auf mehreren Seiten vorkommen. Prüfen Sie kurze, lange und nachgeladene Protokolle nach der Änderung.

Illustratives Beispiel · Tastaturzugang zum Scrollbereich
Gemeinsamer UrsprungKomponente für ProtokollfensterDie konkrete Verwendung entscheidet mit.
  • Schrittprotokoll Befund im Beispiel
  • Ablaufliste Befund im Beispiel
  • Panel ohne Protokoll Ohne diesen Befund im Beispiel

Nach der Änderung erneut prüfenErreichen Sie das Textende mit der Tastatur und verlassen Sie den Bereich anschließend wieder.

Schematische Zuordnung, kein Scanergebnis. „Ohne diesen Befund“ sagt nichts über andere Barrieren aus.

Braucht der Inhalt einen eigenen Scrollbereich?

Entscheiden Sie zuerst, ob das begrenzte Fenster für die Aufgabe erforderlich ist.

  • Protokollfenster beibehalten

    Die Maschinenakte soll kompakt bleiben und längere Protokolle aufnehmen.

    Passende Umsetzung

    Machen Sie den Container mit tabindex="0" erreichbar. Geben Sie dem benannten Bereich einen erkennbaren Fokus und prüfen Sie seine Scrolltasten.

  • Text vollständig anzeigen

    Das kurze Protokoll muss nicht in einem eigenen Fenster stehen.

    Passende Umsetzung

    Heben Sie die feste Höhe und den inneren Überlauf auf. Prüfen Sie danach den normalen Seitenfluss und die tatsächliche Erreichbarkeit aller Werte.

  • Vorhandene Bedienelemente nutzen

    Ein anderer Scrollbereich enthält bereits erreichbare Links oder Eingabefelder.

    Passende Umsetzung

    Testen Sie das Scrollen von dort aus. Eingabefelder können Pfeiltasten selbst verarbeiten; ein erreichbares Kind allein beweist keine vollständige Bedienbarkeit.

Fundstelle ansehen

Das Schrittprotokoll in der Maschinenakte

Der Beleg bewahrt den gesamten Abschnitt „Protokoll der ausgemusterten F-01“ mit Archivmarke, Bühnenschalter und der Zeile „Maschinenpause“. Die Markierung umfasst genau das flache Protokollfenster.

Der BefundProtokoll ohne expliziten Fokuszugang

Im Sichtfenster ist nur „Schritt 01 · Kreis setzen“ vollständig lesbar; die zweite Zeile ist bereits am unteren Rand abgeschnitten. Die Schritte bis „Bühne leeren“ benötigen Scrollen. Das Bildschirmfoto zeigt die räumliche Begrenzung; den fehlenden Tastaturzugang erklärt die Diagnose.

Beispiel im Prüfbericht Markierter Befund
Markierter Befund · Kritisch · WCAG 2.1.1, 2.1.3Protokoll ohne expliziten Fokuszugang

Container korrigieren

Den Scrollbereich in die Tabfolge aufnehmen

Die Korrektur ergänzt tabindex="0" am bestehenden Container. role="region" und aria-label benennen ihn als Schrittprotokoll. Inhalt, Fensterhöhe und Scrollverhalten bleiben erhalten; JavaScript für eigene Scrolltasten ist hier nicht erforderlich.

Was sich im Code ändert

Die geänderte Stelle im Beispiel. Unveränderter Anfang und Schluss sind hier ausgeblendet.

Kommt hinzu
tabindex="0"
  role="region" aria-label="Schrittprotokoll"

Im Komponenten-Template Setzen Sie die Attribute auf das Element mit overflow:auto, nicht auf einen äußeren Rahmen. Übernehmen Sie den sichtbaren Fokus aus Ihrem Designsystem und kontrollieren Sie das veröffentlichte HTML.

Vollständigen Code vergleichen
KorrekturvergleichHTML des Scrollbereichs

Vorher

<div style="max-height:3rem;overflow:auto">
  <div>Schritt 01 · Kreis setzen<br>Schritt 02 · Winkel drehen<br>Schritt 03 · Position halten<br>Schritt 04 · Bühne leeren</div>
</div>

Nachher

<div style="max-height:3rem;overflow:auto" tabindex="0"
  role="region" aria-label="Schrittprotokoll">
  <div>Schritt 01 · Kreis setzen<br>Schritt 02 · Winkel drehen<br>Schritt 03 · Position halten<br>Schritt 04 · Bühne leeren</div>
</div>

Markierte Zeilen wurden geändert

Bedienung umsetzen

Fokus, Scrollen und Ausstieg zusammen prüfen

Ein erreichbares Fenster muss seinen Inhalt zeigen und sich wieder verlassen lassen.

  1. 1

    Verwenden Sie tabindex="0" für die natürliche DOM-Reihenfolge. Positive Werte sind hier nicht nötig.

  2. 2

    Benennen Sie den Bereich nach seinem Inhalt. Gibt es eine passende sichtbare Überschrift, können Sie diese mit aria-labelledby verknüpfen.

  3. 3

    Lassen Sie einen sichtbaren Fokusrahmen stehen. Prüfen Sie, dass der Rand nicht von einem übergeordneten Container abgeschnitten wird.

  4. 4

    Erreichen Sie das Fenster mit Tab oder Umschalt+Tab und scrollen Sie mit Bild-ab und Pfeiltasten bis zum letzten Wert.

  5. 5

    Verlassen Sie es anschließend mit Tab. Wiederholen Sie den Weg bei vergrößerter Darstellung und mit den unterstützten Browsern.

Fehlversuche vermeiden

Was ein tabindex allein nicht absichert

tabindex="-1" setzen

Damit lässt sich ein Element programmatisch fokussieren, es erhält aber keinen regulären Platz in der Tabfolge.

Nur eine ARIA-Rolle ergänzen

role="region" und ein Name beschreiben den Bereich. Sie sorgen für sich genommen nicht für Tastaturfokus.

Pfeiltasten abfangen

Ein keydown-Handler mit preventDefault kann das native Scrollen verhindern. Prüfen Sie beobachtbare Bewegung im Fenster, nicht nur das aktive Element.

Überlauf verstecken

overflow:hidden macht die nicht sichtbaren Protokollschritte nicht zugänglich. Entfernen Sie die Höhenbegrenzung nur, wenn danach wirklich alle Inhalte sichtbar sind.

Erreichbar, scrollbar und wieder verlassbar

Axe bestätigt am selben Container einen Pass. Im ergänzenden Chromium-Tastaturtest erreicht Tab das Protokoll von der inneren Protokollmarke aus. Bild-ab bewegt den Inhalt; Pfeil-ab erreicht das Ende. Umschalt+Tab führt zurück zur Protokollmarke.

Ihre eigene Nachprüfung

Die Markierungen gelten nur für Ihre Selbstkontrolle. Sie ändern den dokumentierten Beispielbefund nicht und werden nicht gespeichert.

0 von 3 Punkten für Ihre Nachprüfung markiert.

Dieser Beleg bestätigt eine Korrektur an genau einem Scrollfenster. Weitere Bedienelemente der Kalibrierseite und vollständige WCAG-Konformität wurden damit nicht geprüft.

Beispiel im Prüfbericht Gelöst
GelöstFokuszugang ergänzt und Scrollen geprüftAxe meldet einen Pass. Der Chromium-Test erreicht per Tastatur den Container, scrollt bis zum Ende und verlässt ihn mit Tab.
Beobachtung nach der Korrektur
tabindex="0" · Region: Schrittprotokoll
Tab: Container erreicht
Bild-ab: scrollTop von 0 auf 40 px
Pfeil-ab: Ende bei 178 von 178 px erreicht
Umschalt+Tab: vorherige Protokollmarke erreicht
Axe: Pass am selben Element

Prüfgrenzen kennen

Der Scan findet Struktur, der Bedienweg braucht Kontrolle

Die automatische Regel und ein Tastaturtest beantworten unterschiedliche Fragen zum selben Fenster.

Automatisch prüfbar

  • Gerenderte Scrollbereiche auf fehlenden Fokuszugang untersuchen.
  • Die betroffene Stelle mit Selektor und Kontext zuordnen.
  • Den Regelbefund nach der Änderung am selben Element erneut prüfen.

Im Kontext zu entscheiden

  • Die Sichtbarkeit des Fokus und eine verständliche Ansage mit Screenreader beurteilen.
  • Alle relevanten Inhalte in unterstützten Browsern tatsächlich per Tastatur erreichen.
  • Dynamisch nachgeladene Protokolle, horizontales Scrollen und verschachtelte Bereiche im jeweiligen Zustand testen.

Werbung

Kostenloser Website-Barrierefreiheits-Check

Website auf Barrierefreiheit prüfen.

Technische WCAG-Warnsignale erkennen. Kritische Stellen zuerst prüfen.

Der Website-Check ist bereit.

Werbung

Ein letzter Schritt

Prüfen, bevor Sie gehen.

Finden Sie automatisch erkennbare Barrieren auf Ihrer eigenen Website.

Website prüfen

Kostenlos starten · keine Installation

Automatisches Screening. Tastaturbedienung und Screenreader bleiben manuelle Prüfung.