Website auf Barrierefreiheit testen: So gehst du vor

Automatische Scanner allein reichen nicht: Mit diesem 7-Schritte-Testplan prüfst du deine Website systematisch – von der Tastatur bis zum Screenreader.

Aktualisiert am 17. Juli 2026 · Wave Tools Redaktion · 9 Min. Lesezeit

Warum ein Testplan besser ist als ein einzelnes Tool

Viele Website-Betreiber starten einen automatischen Scan, sehen ein paar Fehlermeldungen und halten das Thema damit für erledigt. Das greift zu kurz: Barrierefreiheit lässt sich nur teilweise maschinell prüfen. Ob eine Seite wirklich mit der Tastatur bedienbar ist, ob ein Screenreader die Inhalte sinnvoll vorliest oder ob Fehlermeldungen in Formularen verständlich sind – das musst du selbst ausprobieren.

Der folgende Testplan kombiniert deshalb automatische Werkzeuge mit manuellen Prüfungen. Du brauchst dafür keine Spezialausstattung: ein aktueller Browser, eine Tastatur und der Screenreader, der ohnehin auf deinem Betriebssystem installiert ist, reichen für den Anfang. Als Maßstab dient die WCAG 2.2, der internationale Standard für barrierefreie Webinhalte.

Schritt 1: Automatische Scanner als Ausgangspunkt

Automatische Tools finden typische technische Fehler schnell und zuverlässig: fehlende Alt-Attribute, zu geringe Kontraste, fehlende Formular-Labels, fehlerhafte ARIA-Attribute. Drei bewährte, kostenlose Werkzeuge:

  • Lighthouse: in Chrome und Edge eingebaut. Entwicklertools öffnen (F12), Reiter „Lighthouse", Kategorie „Accessibility" auswählen und den Bericht erstellen lassen.
  • axe DevTools: Browser-Erweiterung von Deque. Nach der Installation findest du in den Entwicklertools einen eigenen Reiter, der Fundstellen direkt im Code markiert.
  • WAVE: ein Prüfwerkzeug der US-Organisation WebAIM (nicht mit Wave Tools verbunden – die Namensähnlichkeit ist Zufall). Es legt Symbole direkt über deine Seite und macht Probleme so sehr anschaulich.

Prüfe nicht nur die Startseite, sondern jeden Seitentyp: Startseite, Inhaltsseite, Formularseite, Produkt- oder Beitragsseite, Suchergebnisse.

Wichtig: Automatische Scanner erkennen nach gängigen Untersuchungen nur einen Teil aller Barrieren – oft werden etwa 30 bis 40 Prozent genannt. Ein fehlerfreier Scan bedeutet also nicht, dass deine Website barrierefrei ist. Er bedeutet nur, dass die maschinell prüfbaren Punkte in Ordnung sind. Die folgenden Schritte sind deshalb kein Bonus, sondern Pflicht.

Schritt 2: Der Tastatur-Test

Lege die Maus beiseite und bediene deine Website nur mit der Tastatur. Mit der Tab-Taste springst du vorwärts durch alle interaktiven Elemente, mit Umschalt+Tab rückwärts, mit Enter oder der Leertaste löst du sie aus. Achte auf drei Dinge:

  1. Reihenfolge: Der Fokus sollte in einer logischen Reihenfolge wandern – in der Regel von oben links nach unten rechts, entlang der sichtbaren Struktur. Springt er wild hin und her, stimmt etwas mit der Dokumentstruktur nicht.
  2. Sichtbarkeit: Du musst jederzeit erkennen können, welches Element gerade den Fokus hat. Fehlt der Fokusrahmen (häufig per CSS mit outline entfernt), sind Tastaturnutzer verloren.
  3. Keine Fallen: Du musst jedes Element auch wieder verlassen können. Klassische Fallen sind eingebettete Widgets, Cookie-Banner und Modaldialoge, die sich nicht per Escape schließen lassen.

Teste auch Menüs, Akkordeons, Slider und Datepicker – genau dort scheitern viele Websites.

Schritt 3: Screenreader-Basistest

Ein Screenreader liest die Seite so vor, wie blinde und stark sehbehinderte Menschen sie wahrnehmen. Für einen Basistest brauchst du nichts zu kaufen:

  • Windows: NVDA ist kostenlos und weit verbreitet. Nach dem Start liest er automatisch vor; mit der Taste H springst du von Überschrift zu Überschrift, mit Tab durch die interaktiven Elemente.
  • macOS und iOS: VoiceOver ist eingebaut. Auf dem Mac startest du es mit Cmd+F5, auf dem iPhone über die Einstellungen unter Bedienungshilfen.

Stelle dir beim Zuhören drei Fragen: Ergibt die Seite auch ohne Bildschirm Sinn? Werden Bilder mit sinnvollen Alternativtexten angesagt oder nur mit Dateinamen? Erfährst du bei Buttons und Links, was passiert, wenn du sie auslöst – oder hörst du nur „Link" und „hier klicken"? Schon zehn Minuten mit einem Screenreader zeigen dir mehr über deine Website als jeder Bericht.

Schritt 4: Zoom auf 200 Prozent und Reflow

Viele Menschen mit Sehbehinderung vergrößern Inhalte im Browser. Die WCAG verlangt, dass Text bei 200 Prozent Zoom ohne Verlust von Inhalt und Funktion nutzbar bleibt. So testest du:

  1. Vergrößere die Seite mit Strg und Plus (Mac: Cmd und Plus) schrittweise auf 200 Prozent.
  2. Prüfe, ob Texte abgeschnitten werden, sich überlappen oder ob Bedienelemente aus dem sichtbaren Bereich rutschen.
  3. Verkleinere zusätzlich das Browserfenster auf etwa 320 Pixel Breite oder zoome auf 400 Prozent: Jetzt sollte sich der Inhalt in eine Spalte umbrechen (Reflow), ohne dass du horizontal scrollen musst.

Wenn deine Website responsiv sauber gebaut ist, besteht sie diesen Test meist ohne Nacharbeit – wenn nicht, siehst du sofort, wo es klemmt.

Schritt 5: Kontraste prüfen

Zu schwache Kontraste gehören zu den häufigsten Barrieren überhaupt. Die WCAG fordert für normalen Text ein Kontrastverhältnis von mindestens 4,5:1 zum Hintergrund, für großen Text (ab etwa 24 Pixel oder 19 Pixel fett) mindestens 3:1. Auch Bedienelemente und grafische Symbole brauchen mindestens 3:1.

Zum Messen eignen sich der Contrast Checker von WebAIM, das Farbwähler-Werkzeug in den Browser-Entwicklertools oder Desktop-Programme wie der Colour Contrast Analyser. Prüfe gezielt die kritischen Kandidaten: hellgrauen Text auf Weiß, Platzhaltertexte in Formularfeldern, Text auf Fotos und Buttons in Markenfarben. Verlasse dich nicht auf deinen Eindruck am eigenen, gut eingestellten Monitor – miss nach.

Schritt 6: Formulare und Fehlermeldungen

Formulare sind der Ort, an dem Barrieren am teuersten sind – hier brechen Bestellungen und Anfragen ab. Fülle jedes wichtige Formular einmal komplett aus, einmal absichtlich falsch und einmal nur mit der Tastatur. Achte darauf:

  • Jedes Feld hat ein sichtbares, programmatisch verknüpftes Label – ein Platzhaltertext im Feld ersetzt kein Label, denn er verschwindet beim Tippen.
  • Pflichtfelder sind als solche gekennzeichnet, nicht nur durch Farbe.
  • Fehlermeldungen erscheinen in Textform direkt am betroffenen Feld, erklären konkret, was falsch ist und wie es richtig geht – „Ungültige Eingabe" allein hilft niemandem.
  • Nach dem Absenden mit Fehlern bleibt das bereits Eingegebene erhalten.
  • Zeitlimits, etwa in Buchungsstrecken, lassen sich verlängern oder abschalten.

Schritt 7: Inhalte prüfen – Alt-Texte, Überschriften, Linktexte

Zum Schluss geht es um die redaktionelle Ebene, die kein Tool bewerten kann:

  • Alt-Texte: Beschreibt der Alternativtext, was auf dem Bild zu sehen ist und welche Funktion es hat? Sind rein dekorative Bilder mit leerem Alt-Attribut versehen? Wie gute Alt-Texte entstehen, zeigt unser Artikel Alt-Texte richtig schreiben.
  • Überschriften-Hierarchie: Genau eine H1 pro Seite, danach eine lückenlose Gliederung (H2, darunter H3). Überschriften sind Struktur, kein Gestaltungsmittel – wer eine H4 wählt, weil sie hübsch klein aussieht, sabotiert die Navigation per Screenreader.
  • Linktexte: Jeder Link sollte aus sich heraus verständlich sein. „Mehr erfahren" und „hier" sind es nicht – „Preisliste als PDF herunterladen" schon.

Priorisieren, dokumentieren, dranbleiben

Nach den sieben Schritten hast du eine Liste von Fundstellen. Sortiere sie nach Wirkung: Zuerst kommen Blocker, die Nutzung komplett verhindern (Tastaturfallen, unbeschriftete Formulare, nicht bedienbare Navigation), dann große Hürden wie fehlende Alt-Texte auf zentralen Seiten und schwache Kontraste, zuletzt Feinschliff.

Dokumentiere jede Fundstelle mit Seite, Beschreibung, betroffenem WCAG-Kriterium und geplanter Abhilfe. Diese Dokumentation zahlt sich doppelt aus: Sie ist die Arbeitsgrundlage für dein Team – und sie liefert die Fakten für deine Barrierefreiheitserklärung, in der du bekannte Einschränkungen und geplante Maßnahmen ohnehin benennen musst.

Tipp: Barrierefreiheit ist kein einmaliges Projekt. Jedes Update, jedes neue Plugin und jeder neue Inhalt kann neue Barrieren einführen. Plane einen kurzen Test bei jedem größeren Release ein und eine vollständige Prüfung mindestens einmal im Jahr – so bleibt der Aufwand klein und der Stand aktuell.

Wave Access prüft deine WordPress-Website direkt im Backend, führt dich durch die manuellen Checks und erstellt einen Prüfbericht als PDF-Report – die ideale Grundlage für deine Dokumentation und Barrierefreiheitserklärung.

Wave Access entdecken →