Barrierefreiheitstests

Warum Barrierefreiheitstests nach dem Launch Pflicht sind

Nach der Entwicklung einer barrierefreien Website sind Barrierefreiheitstests entscheidend, um die Einhaltung von WCAG und BITV nachweisbar zu prüfen. Viele Probleme tauchen erst in echten Nutzungssituationen auf, etwa bei Tastaturbedienung, Screenreader-Nutzung oder bei starker Vergrößerung.

Merksatz: Automatische Tools finden viele Fehler, aber nicht die wichtigsten Nutzungsbarrieren.

Was genau wird bei Barrierefreiheitstests geprüft?

Barrierefreiheitstests bewerten, ob Nutzer Inhalte wahrnehmen, bedienen und verstehen können, unabhängig von Einschränkungen oder Assistenztechnik. In der Praxis prüfen Sie vor allem:

• Struktur und Semantik: Überschriftenhierarchie, Landmarken, Formularlabels
• Bedienbarkeit: Tastatur, Fokusführung, keine Tastaturfallen
• Wahrnehmbarkeit: Kontraste, Zoom, Reflow, Alternativtexte
• Robustheit: sauberes HTML, ARIA korrekt eingesetzt, kompatibel mit Assistenztechnik

Methoden der Barrierefreiheitstests

1) Automatische Prüftools

Automatische Tools scannen Code und DOM auf typische Probleme, zum Beispiel:

• fehlende oder leere Alternativtexte
• fehlende Formularlabels
• Kontrastwarnungen
• ARIA-Fehler

Stärke: schnell, gut für Basis-Screening und Regression-Checks
Grenze: erkennt nicht zuverlässig, ob etwas wirklich bedienbar und verständlich ist

2) Manuelle Prüfungen

Manuelle Tests prüfen die tatsächliche Bedienung. Typische Checks:

• Tastaturnavigation mit Tab, Shift+Tab, Enter, Escape
• Fokus-Reihenfolge und sichtbarer Fokus
• Dropdowns, Modals, Offcanvas-Menüs
• Formulare: Fehlermeldungen, Pflichtfelder, Hilfetexte
• Inhalt bei 200 Prozent Zoom und auf kleinen Viewports (Reflow)

3) Screenreader-Tests

Screenreader-Tests prüfen, wie Inhalte vorgelesen und navigiert werden, zum Beispiel:

• korrekte Ansage von Überschriften und Bereichen
• sinnvolle Linktexte
• Formulareingaben und Fehlermeldungen
• Statusmeldungen (z. B. “in den Warenkorb gelegt”)

Wichtig: Mindestens ein Screenreader-Test sollte Teil des Standardprozesses sein.

4) Tests mit echten Nutzern

Am aussagekräftigsten sind Tests mit Menschen, die Assistenztechnik täglich nutzen. Das zeigt schnell:

• wo Nutzer hängen bleiben
• welche Begriffe missverständlich sind
• welche Interaktionen nicht funktionieren

Welche Methode findet welche Fehler?

Schritt-für-Schritt: So führen Sie Barrierefreiheitstests durch

Schritt 1: Umfang und Seitenliste festlegen

Testen Sie nicht blind “die ganze Website”. Definieren Sie eine sinnvolle Auswahl:

• Startseite
• wichtigste Landingpages
• Formulare (Kontakt, Checkout, Registrierung)
• Navigation und Suche
• zentrale Inhaltsseiten (Blog, Glossar, Service)

Schritt 2: Automatisches Screening durchführen

Nutzen Sie ein Tool als erste Schicht, um offensichtliche Probleme zu sammeln. Wichtig ist, die Findings später manuell zu verifizieren.

Schritt 3: Tastatur-Test als Pflichtprogramm

Gehen Sie jede Seite durch und prüfen Sie:

• Erreichbarkeit aller Funktionen ohne Maus
• sichtbarer Fokus
• logische Reihenfolge
• Escape schließt Overlays
• keine “Fokus-Fallen”

Schritt 4: Screenreader-Schnelltest

Prüfen Sie mindestens:

• Seitenstruktur (Überschriften, Bereiche)
• Navigation (Menü, Dropdowns)
• Formulare (Labels, Fehlermeldungen)
• wiederkehrende Komponenten (Cards, Akkordeons)

Schritt 5: Findings priorisieren und sauber dokumentieren

Dokumentieren Sie pro Finding:

• Seite/URL
• WCAG-Kriterium (wenn bekannt)
• Beschreibung des Problems in einem Satz
• Schritte zum Reproduzieren
• erwartetes Verhalten
• Impact (hoch/mittel/niedrig)
• Vorschlag zur Behebung

Beispiel: Struktur für ein Finding (Template)

**Seite:** /kontakt/
**Problem:** Fokus springt nach Öffnen des Modals nicht in das Modal.
**Reproduktion:** Button "Termin buchen" fokussieren -> Enter -> Modal öffnet -> Tab.
**Ist-Zustand:** Fokus bleibt im Hintergrund, Nutzer landet außerhalb des Modals.
**Soll-Zustand:** Fokus setzt auf die erste Interaktion im Modal, Tab bleibt im Modal, Escape schließt.
**Impact:** Hoch (Tastatur und Screenreader)
**Fix-Idee:** Focus Trap + initial focus + aria-modal + role="dialog"

Minimalbeispiel: Dialog korrekt markieren (Code Snippet)

<button aria-haspopup="dialog" aria-controls="kontakt-dialog">
  Termin buchen
</button>

<div id="kontakt-dialog" role="dialog" aria-modal="true" aria-labelledby="dialog-title" hidden>
  <h2 id="dialog-title">Termin buchen</h2>
  <button type="button" data-close>Schließen</button>
  <!-- Formularfelder -->
</div>

Hinweis: ARIA ersetzt keine saubere Bedienlogik. Fokusmanagement muss technisch umgesetzt werden.

Checkliste für schnelle Qualitätsprüfung

• Alle Funktionen sind per Tastatur erreichbar
• Fokus ist immer sichtbar und logisch
• Skip-Link vorhanden (wenn Navigation umfangreich ist)
• Überschriften sind hierarchisch korrekt
• Formulare haben Labels und klare Fehlermeldungen
• Linktexte sind eindeutig (nicht “Mehr”, “Hier klicken”)
• Kontrast ist ausreichend, auch bei Buttons und Fokus
• Inhalte funktionieren bei 200 Prozent Zoom und auf Mobile
• ARIA nur dort eingesetzt, wo nötig, und korrekt

Häufige Stolperfallen in der Praxis

Zu viel ARIA, zu wenig Semantik

Wenn ein <button> reicht, ist ein <div role="button"> fast immer die schlechtere Wahl.

Fokus wird aus Designgründen entfernt

Ein “unsichtbarer” Fokus ist ein echter Blocker. Design muss Fokus mitdenken.

Fehlertexte sind visuell da, aber nicht ansagbar

Formularfehler müssen programmatisch mit dem Feld verknüpft sein, sonst sind sie für Screenreader-Nutzer schwer nutzbar.

Fazit

Barrierefreiheitstests sind der entscheidende Schritt, um aus “sieht barrierefrei aus” eine wirklich bedienbare Website zu machen. Am zuverlässigsten ist die Kombination aus automatischen Checks, manuellen Tastatur-Tests und Screenreader-Prüfungen. Wenn möglich, ergänzen Sie Nutzertests, weil sie die echten Hürden im Ablauf sichtbar machen.