Scroll-Storytelling mit Tastatur und Screenreader bedienbar machen

Scrollgesteuerte Effekte sind seit ein paar Jahren fester Bestandteil anspruchsvoller Websites, und sie funktionieren, wenn sie gut gemacht sind. Wie so ein Aufbau technisch aussieht, habe ich am Beispiel einer Website beschrieben, durch die man swipt statt scrollt. Dieser Beitrag beantwortet die Frage, die dabei offen bleibt: Was muss dazukommen, damit der Effekt nicht nur mit der Maus funktioniert.

Denn genau daran scheitern die meisten Umsetzungen. Nicht an der Optik, nicht an der Performance, sondern an der Bedienung mit der Tastatur.

Der häufigste Fehler kostet eine Zeile

Der Klassiker ist ein Container mit overflow: auto oder overflow: scroll, in dem Inhalt scrollbar ist, der aber selbst keinen Tastaturfokus bekommen kann. Mit der Maus lässt sich der Bereich scrollen, mit dem Rad ebenfalls. Wer sich mit der Tabulatortaste durch die Seite bewegt, springt schlicht darüber hinweg und kommt an den Inhalt nicht heran.

Das ist ein Verstoß gegen WCAG 2.1.1, Tastaturbedienbarkeit, und der liegt auf Konformitätsstufe A. Also nicht auf der Feinschliff-Ebene, sondern auf der untersten.

Die Abhilfe ist unspektakulär. Entweder enthält der scrollbare Bereich ohnehin ein fokussierbares Element, etwa einen Link oder eine Schaltfläche, dann ist er über dieses erreichbar. Oder er bekommt selbst ein tabindex="0":

<div class="story-panel" tabindex="0" role="region" aria-label="Projektverlauf">
  <!-- scrollbarer Inhalt -->
</div>

Damit landet der Container in der Tabulatorreihenfolge, und wer ihn fokussiert hat, kann mit den Pfeiltasten scrollen. Das role und das aria-label sind kein Muss, machen aber aus einem namenlosen Fokusstopp einen benannten Bereich, was die Orientierung mit Screenreader erheblich verbessert.

Der zweite Klassiker betrifft die Reihenfolge. Wenn Abschnitte beim Scrollen ein- und ausgeblendet oder horizontal verschoben werden, weicht die sichtbare Reihenfolge oft von der Dokumentreihenfolge ab. Der Fokus springt dann für Tastaturnutzer scheinbar wahllos über die Seite. Das ist WCAG 2.4.3, Fokus-Reihenfolge, ebenfalls Stufe A. Die Regel dahinter ist einfach: Was visuell nacheinander kommt, sollte auch im Markup nacheinander stehen. Wer die Reihenfolge ausschließlich per CSS oder Transformation herstellt, baut sich dieses Problem ein.

Foto: Davide Baraldi / Pexels

Was die Untersuchung tatsächlich zeigt

Die Nielsen-Norman-Group hat scrollgesteuerte Effekte untersucht und dabei nicht pauschal verurteilt, sondern differenziert. Die Mehrheit der Testpersonen war mindestens leicht desorientiert. Am schwersten wogen die Probleme dort, wo der veränderte Scrollablauf mit längeren Textpassagen zusammentraf, weil Lesen und ein ungewohntes Scrollverhalten sich gegenseitig stören. Auf kleinen Bildschirmen verstärkt sich der Effekt zusätzlich, weil derselbe Ablauf dort länger dauert.

Interessanter als die Kritik ist aber die andere Hälfte des Befunds, nämlich unter welchen Bedingungen der Effekt funktioniert hat:

• unterhalb der Falz statt gleich im ersten Bildschirm
• mit einem schnellen Scrollverhältnis, das wenig Eingabe verlangt
• abwechselnd mit normal scrollenden Abschnitten statt über die ganze Seite
• ohne größere Textmengen im bewegten Bereich
• auf dem Desktop, nicht auf dem Telefon

Das ist eine brauchbare Entwurfsregel, und sie deckt sich mit dem, was ich in Projekten sehe. Ein Effekt, der eine Grafik oder einen Produktaufbau schrittweise zeigt, trägt. Ein Effekt, durch den man einen Fließtext lesen soll, nervt.

prefers-reduced-motion ist der größte Hebel

Wer im Betriebssystem eingestellt hat, weniger Bewegung sehen zu wollen, tut das meist aus gutem Grund. Für einen Teil der Nutzer ist das Komfort, für einen anderen sind flächige Bewegungen ein handfestes Problem bis hin zu Schwindel und Übelkeit. Die Einstellung lässt sich in CSS abfragen, und der Aufwand ist minimal:

.story-panel {
  transition: transform 600ms cubic-bezier(0.4, 0, 0.2, 1);
}

@media (prefers-reduced-motion: reduce) {
  .story-panel {
    transition: none;
  }
  .story-track {
    /* zurück auf normales, dokumentnahes Scrollen */
    transform: none;
    overflow-y: auto;
    scroll-snap-type: none;
  }
}

Wichtig ist dabei die Denkrichtung. Es geht nicht darum, die Animation abzuschalten und den Nutzer mit einem halb funktionierenden Rest sitzen zu lassen, sondern eine vollwertige ruhige Fassung anzubieten. Alle Inhalte sind vorhanden, sie erscheinen nur ohne Bewegung und in normaler Scrollmechanik. Wenn das nicht funktioniert, ist das ein Hinweis darauf, dass Inhalt und Effekt zu eng verdrahtet sind.

Denselben Test kann man übrigens ohne jede Zusatzeinstellung machen: Wie sieht die Seite aus, wenn JavaScript nicht läuft? Sind die Inhalte dann noch da und lesbar? Wenn ja, ist die Grundlage solide, und der Effekt liegt als Schicht darüber. Wenn nein, hängt der gesamte Inhalt an der Animation, und das ist die eigentliche Baustelle.

Foto: Thirdman / Pexels

Was das rechtlich bedeutet

Für Websites, die unter das Barrierefreiheitsstärkungsgesetz fallen, ist das keine Geschmacksfrage. Das Gesetz verweist auf die harmonisierte europäische Norm und damit auf die WCAG-Kriterien der Stufen A und AA. Beide oben genannten Punkte, Tastaturbedienbarkeit und Fokus-Reihenfolge, liegen auf Stufe A.

Praktisch heißt das: Ein aufwendiger Scroll-Effekt kann gestalterisch hervorragend sein und trotzdem an einer Anforderung scheitern, die sich mit einem Attribut und einer Medienabfrage erfüllen ließe. Denselben Punkt hatte ich schon bei WebGL und Barrierefreiheit beschrieben, und er gilt hier genauso: Der aufwendige Teil ist nicht die Barrierefreiheit, sondern das nachträgliche Einbauen in etwas, das ohne sie entworfen wurde.

Foto: Tima Miroshnichenko / Pexels

Die Prüfliste, die ich verwende

Vier Handgriffe, die vor dem Livegang durchlaufen sollten und zusammen keine Stunde kosten:

1. Tabulatortaste drücken, bis man durch die ganze Seite ist. Wird jeder scrollbare Bereich erreicht? Ist erkennbar, wo der Fokus gerade steht? Springt die Reihenfolge?
2. Bewegung im Betriebssystem reduzieren und die Seite neu laden. Sind alle Inhalte da, ist alles lesbar, funktioniert das Scrollen normal?
3. JavaScript abschalten. Bleiben die Inhalte sichtbar oder ist die Seite leer?
4. Auf dem Telefon durchscrollen. Fühlt sich der Effekt dort träge oder unkontrollierbar an? Wenn ja, gehört er auf kleinen Bildschirmen deaktiviert.

Keiner dieser Punkte verlangt Spezialwissen oder ein Prüfwerkzeug. Sie fangen den Großteil dessen ab, was in der Praxis schiefgeht.

Wenn du eine Website mit aufwendigen Scroll-Effekten hast und wissen willst, ob sie mit Tastatur und Screenreader bedienbar ist, schaue ich mir das gerne an. Meist sind es wenige Stellen, an denen es hakt, und die lassen sich gezielt beheben, ohne den Effekt aufzugeben.