Accessibility-Testing für SPAs - Warum herkömmliche Tools versagen

React, Angular, Vue - moderne Web-Apps werden als Single Page Applications gebaut. Das Problem: Die meisten Accessibility-Tools wurden für statische Websites entwickelt. Sie sehen nur die erste HTML-Seite und verpassen alles, was JavaScript dynamisch rendert.

Das Problem mit klassischen Scannern

Herkömmliche Accessibility-Scanner arbeiten so:

HTTP-Request an die URL senden
HTML-Antwort empfangen
HTML parsen und prüfen
Fertig

Das funktioniert bei einer klassischen WordPress-Seite. Aber bei einer SPA sieht die initiale HTML-Antwort oft so aus:

<html>
<body>
  <div id="root"></div>
  <script src="bundle.js"></script>
</body>
</html>

Ein leeres <div> und ein JavaScript-Bundle. Kein Inhalt. Der klassische Scanner prüft also: nichts.

Was SPAs besonders macht

Client-Side Routing

SPAs laden keine neuen Seiten - sie tauschen Inhalte dynamisch aus. Die URL ändert sich, aber es findet kein echter Seitenaufruf statt. Ein Scanner, der nur die initiale URL aufruft, sieht nur die Startseite.

Dynamische Inhalte

Modals, Dropdown-Menüs, Tabs, Akkordeons - all diese Elemente existieren erst, wenn der Nutzer damit interagiert. Ein Scanner, der nicht klickt, sieht sie nie.

Asynchrone Daten

Produktlisten, Nutzerdaten, Formulare - vieles wird erst geladen, nachdem die Seite gerendert ist. Ein Scanner muss warten, bis alle Daten da sind.

Zustandsabhängige UI

Fehlerseiten, Ladeanimationen, leere Zustände - die UI sieht je nach Zustand anders aus. Jeder Zustand kann eigene Accessibility-Probleme haben.

Was ein SPA-fähiger Scanner können muss

1. Echten Browser verwenden

Statt nur HTTP-Requests zu senden, muss der Scanner einen echten Browser starten (z.B. Chromium via Playwright). Nur so wird JavaScript ausgeführt und die SPA vollständig gerendert.

2. Warten können

Der Scanner muss erkennen, wann die Seite fertig geladen ist. Das bedeutet: Warten auf Netzwerk-Requests, DOM-Änderungen und Animationen.

3. Interagieren

Links klicken, Buttons drücken, Formulare ausfüllen, Modals öffnen - der Scanner muss die App wie ein echter Nutzer bedienen, um alle Inhalte und Zustände zu sehen.

4. Client-Side Routing verstehen

Wenn der Scanner auf einen internen Link klickt, darf er nicht warten, dass eine neue Seite geladen wird. Er muss erkennen, dass sich nur der Inhalt innerhalb der SPA geändert hat.

5. Den gerenderten DOM prüfen

Die Accessibility-Prüfung muss auf dem aktuellen, gerenderten DOM laufen - nicht auf dem Quellcode. Nur so werden dynamisch hinzugefügte Elemente erfasst.

Häufige SPA-spezifische Accessibility-Probleme

Fehlende Seitenankündigungen

Bei Client-Side Navigation wird kein neuer Seitentitel an den Screenreader übermittelt. Lösung: document.title bei jeder Route-Änderung aktualisieren und aria-live Regionen nutzen.

Fokus-Management

Nach einer Navigation landet der Fokus oft nirgendwo. Screenreader-Nutzer wissen nicht, dass sich etwas geändert hat. Lösung: Fokus nach Navigation auf den Hauptinhalt oder die Überschrift setzen.

Dynamische Inhalte ohne Ankündigung

Wenn neue Produkte geladen oder Fehlermeldungen angezeigt werden, merken Screenreader-Nutzer nichts. Lösung: aria-live="polite" für Statusmeldungen, aria-live="assertive" für Fehler.

Modals und Overlays

Wenn ein Modal geöffnet wird, kann der Screenreader oft noch den Hintergrund lesen. Lösung: aria-modal="true", Fokus-Trap im Modal, aria-hidden="true" auf dem Rest der Seite.

Ladeanimationen

Endlose Spinner ohne Screenreader-Info. Lösung: aria-busy="true" und role="status" mit einer Textnachricht wie "Lade Produkte...".

Framework-spezifische Tipps

React

react-helmet oder Next.js <Head> für dynamische Seitentitel
useRef und useEffect für Fokus-Management
React.Fragment statt unnötige <div>-Wrapper

Angular

Title Service für Seitentitel
RouterModule Events für Fokus-Management nach Navigation
cdkTrapFocus für Modal-Fokus-Traps

Vue

vue-announcer für Route-Ankündigungen
vue-focus-lock für Modals
$nextTick abwarten bevor Fokus gesetzt wird

So testen Sie Ihre SPA richtig

Automatischer Scan mit Browser-Engine - Nutzen Sie einen Scanner, der einen echten Browser verwendet und durch Ihre App navigiert
Tastatur-Test - Gehen Sie den gesamten User-Flow nur mit der Tastatur durch (Tab, Enter, Escape, Pfeiltasten)
Screenreader-Test - Testen Sie mit NVDA (Windows) oder VoiceOver (Mac)
Route-Wechsel prüfen - Wird der Fokus korrekt gesetzt? Wird der Seitentitel aktualisiert?
Alle Zustände testen - Leere Listen, Fehlermeldungen, Ladeanimationen

Fazit

SPAs bringen besondere Herausforderungen für Accessibility-Testing. Klassische Scanner, die nur statisches HTML prüfen, reichen nicht aus. Sie brauchen ein Tool, das Ihre App wie ein echter Nutzer bedient - mit einem echten Browser, Interaktionen und der Fähigkeit, auf dynamische Inhalte zu warten.

ScanClusive testet Ihre SPA wie ein echter Nutzer - mit Playwright und axe-core. Jetzt kostenlos testen.