Scrollbereich per Tastatur nicht erreichbar (scrollable-region-focusable)

Die Regel scrollable-region-focusable meldet einen Bereich, der scrollt – eine breite Tabelle, ein AGB-Kasten, ein Codeblock –, wenn weder der Bereich selbst noch etwas darin den Tastaturfokus erhalten kann. Mit Maus oder Finger lässt er sich scrollen; wer die Tastatur nutzt, erreicht den verdeckten Teil gar nicht. Die Lösung: den Bereich fokussierbar machen und benennen – tabindex="0" mit role="region" und einer Beschriftung.

Was die Regel bedeutet

WCAG 2.1.1 Tastatur verlangt, dass alle Funktionen per Tastatur verfügbar sind. Einen Bereich zu scrollen, um Verdecktes zu lesen, gehört dazu. Mit der Tastatur scrollt ein Bereich über die Pfeiltasten erst, wenn der Fokus auf ihm oder in ihm liegt.

axe-core meldet ein Element, wenn alles davon zutrifft:

• sein Inhalt läuft horizontal oder vertikal um mehr als ein paar Pixel über, und overflow steht auf auto oder scroll – overflow: hidden ist kein Scrollen;
• ein Teil des Inhalts liegt tatsächlich außerhalb des sichtbaren Bereichs;
• das Element ist nicht in der Tab-Reihenfolge und enthält nichts, was es ist – keinen Link, keinen Button, kein Formularfeld, kein anderes Element mit tabindex="0".

Ein Scrollbereich mit einem Link darin besteht, weil der Sprung per Tab zum Link den Bereich mitscrollt. <select> und <textarea> sind ausgenommen, ebenso Aufklapplisten von Comboboxen.

Was die Regel nicht prüft: ob sich der Bereich per Tastatur angenehm scrollen lässt, ob das fokussierbare Element darin den verdeckten Inhalt wirklich ins Bild holt und ob der Bereich einen sichtbaren Fokusrahmen hat, sobald er fokussierbar ist. axe-core ordnet die Regel außerdem 2.1.3 Tastatur (keine Ausnahme) zu, einem Kriterium der Stufe AAA.

Wen es betrifft

Menschen, die nur mit der Tastatur navigieren: Menschen mit motorischen Einschränkungen, die Tastatur, Schaltersteuerung oder Mundstab nutzen, und blinde Menschen, die einen Screenreader mit der Tastatur bedienen. Für sie existieren die Spalten einer Tabelle, die nicht hineinpassen, oder die zweite Hälfte eines Textes in einem Kasten mit fester Höhe schlicht nicht. Wer stark vergrößert, ist häufiger betroffen, denn was auf einem breiten Bildschirm passt, beginnt auf einem schmalen zu scrollen.

Warum die Prüfung anschlägt

• Responsive Tabellen in einem Container mit overflow-x: auto – der übliche Weg, damit eine breite Tabelle auf dem Smartphone das Layout nicht sprengt.
• Textkästen mit fester Höhe für AGB, Datenschutzhinweise oder Einwilligungstexte, mit overflow-y: auto.
• Codeblöcke und vorformatierter Text in Dokumentationen und Blogs, die seitlich scrollen.
• Chatverläufe, Aktivitäts-Feeds und Kommentarlisten in einem scrollenden Container.
• Kartenreihen und Produkt-Slider als horizontale Scrollbereiche ohne Links in den Karten.
• Inhalte, die am Desktop passen und mobil überlaufen – deshalb zeigt sich das Problem oft nur bei schmaler Breite.

So beheben Sie es

1. Setzen Sie tabindex="0" auf den scrollenden Container. Dann erhält er den Fokus, und die Pfeiltasten scrollen ihn.
2. Geben Sie ihm role="region" und einen Namen – aria-labelledby mit Verweis auf eine Tabellenbeschriftung oder Überschrift, oder aria-label –, damit Screenreader ansagen, was dieser Tab-Stopp ist.
3. Geben Sie ihm einen sichtbaren Fokusstil, denn er ist jetzt ein Tastatur-Stopp wie jedes Bedienelement.
4. Noch besser: Vermeiden Sie das Scrollen, wo es geht. Lassen Sie Tabellen auf schmalen Bildschirmen in gestapelte Zeilen umbrechen und Textkästen mitwachsen.

<!-- Vorher: die Tariftabelle scrollt seitlich, aber nichts kann den Fokus erhalten -->
<style>
  .tabelle-scroll { overflow-x: auto; max-width: 20rem; }
  .tabelle-scroll table { min-width: 40rem; }
</style>
<div class="tabelle-scroll">
  <table>
    <caption>Fahrpreise nach Zone</caption>
    <tr><th scope="col">Zone</th><th scope="col">Einzelfahrt</th><th scope="col">Tageskarte</th><th scope="col">Wochenkarte</th></tr>
    <tr><td>A</td><td>3,20 €</td><td>9,50 €</td><td>34,00 €</td></tr>
  </table>
</div>

<!-- Nachher: benannter, fokussierbarer Bereich – Tab erreicht ihn, Pfeiltasten scrollen -->
<style>
  .tabelle-scroll { overflow-x: auto; max-width: 20rem; }
  .tabelle-scroll table { min-width: 40rem; }
</style>
<div class="tabelle-scroll" tabindex="0" role="region" aria-labelledby="fahrpreise-titel">
  <table>
    <caption id="fahrpreise-titel">Fahrpreise nach Zone</caption>
    <tr><th scope="col">Zone</th><th scope="col">Einzelfahrt</th><th scope="col">Tageskarte</th><th scope="col">Wochenkarte</th></tr>
    <tr><td>A</td><td>3,20 €</td><td>9,50 €</td><td>34,00 €</td></tr>
  </table>
</div>

Dazu der Fokusstil, den der neue Tastatur-Stopp braucht:

.tabelle-scroll:focus-visible { outline: 2px solid #005fcc; outline-offset: 2px; }

So prüfen Sie es von Hand

1. Ziehen Sie das Browserfenster auf Smartphone-Breite zusammen (oder nutzen Sie die Geräteansicht der Entwicklertools) – viele Scrollbereiche entstehen erst dort.
2. Gehen Sie mit Tab durch die Seite. Erreicht der Fokus jeden Scrollbereich oder etwas darin?
3. Wenn ja: Drücken Sie die Pfeiltasten. Scrollt der Bereich, und erreichen Sie seinen ganzen Inhalt?
4. Prüfen Sie, ob der fokussierte Bereich einen sichtbaren Fokusrahmen hat und – mit Screenreader – ob er mit einem sinnvollen Namen angesagt wird.
5. Manche Browser machen Scroll-Container inzwischen von sich aus fokussierbar. Testen Sie deshalb in mehr als einem, auch in Safari – ein Bereich, der in einem Browser funktioniert, kann in einem anderen unerreichbar sein.

Zugehöriges WCAG-Kriterium

2.1.1 Tastatur, Stufe A. Verwandt: 1.4.10 Reflow (Umbruch), das Scrollen in zwei Richtungen nur für Inhalte wie Datentabellen erlaubt, die es brauchen, und 2.4.7 Fokus sichtbar für den Fokusrahmen am Container. 2.1.3 Tastatur (keine Ausnahme) gehört zur Stufe AAA und hat hier keine eigene Seite.

So meldet Reviseberg diese Regel

Reviseberg führt scrollable-region-focusable auf jeder gecrawlten Seite bei 1280 px und noch einmal bei 360 px aus, weil eine Tabelle oder ein Textkasten, der auf breitem Bildschirm passt, auf schmalem oft zu scrollen beginnt. Ein Bereich, der bei beiden Breiten auffällt, zählt nur einmal. In der Befundliste sehen Sie die Regel mit Schweregrad, WCAG-Kriterium 2.1.1 und Stufe, der Zahl der Elemente und Seiten und den Punkten, die ein Fix zurückbringt. Im Detail stehen Selektor und HTML-Ausschnitt des scrollenden Containers und alle betroffenen Seiten – meist erklärt ein gemeinsamer Tabellen-Wrapper oder eine Textkasten-Komponente alle Vorkommen. Befunde können Sie mit Begründung als „ignorieren“, „nicht behebbar“ oder „Fehlalarm“ markieren; jede Entscheidung wird protokolliert.

Kein Crawl entscheidet 2.1.1 allein. Ohne Befund gilt das Kriterium als teilweise geprüft, nicht als bestanden, bis ein Mensch ein manuelles Ergebnis erfasst.

Verwandte Regeln

• undefined – der Tastatur-Agent findet Bedienelemente, die Tab nie erreicht.
• undefined – Fokus ohne sichtbaren Rahmen, den der neue Tab-Stopp braucht.
• undefined – die andere Regel, bei der Zoom und schmale Bildschirme ins Spiel kommen.
• undefined – ebenfalls noch einmal bei 360 px geprüft.

Tabellen und Scrollbereiche in Smartphone-Breite prüfen – kostenloser Scan