--- title: "Barrierefreiheit testen: Tools, manuelle Checks und ein Testplan" url: "https://barrierefreihochzwei.de/de/blog/barrierefreiheit-testen-tools-und-testplan" language: "de" description: "Was axe, WAVE und Lighthouse finden und was nicht, welche manuellen Checks jedes Team schafft und wie ein realistischer Testplan für Barrierefreiheit aussieht." published: "2026-10-07T09:00:00+02:00" updated: "2026-10-15T09:42:14+02:00" --- # Barrierefreiheit testen: Tools, manuelle Checks und ein Testplan Automatische Tools finden nur einen Teil der Barrieren. Wie du Tools, manuelle Checks, Nutzertests und Prüfverfahren kombinierst und daraus einen Testplan machst. Du hast Lighthouse laufen lassen, die Bewertung zeigt 100 Punkte, alles grün. Fertig? Leider nicht. Ein automatischer Test kann dir sagen, dass jedes Bild ein `alt`-Attribut hat. Ob dort „Bild1.jpg“ steht oder eine sinnvolle Beschreibung, weiß er nicht. Und ob sich dein Checkout per Tastatur bis zum Ende bedienen lässt, prüft er auch nicht. Barrierefreiheit zu testen heißt deshalb, mehrere Methoden zu kombinieren: automatisierte Tools für die schnellen, wiederholbaren Funde, manuelle Checks für alles, was menschliches Urteil braucht, Tests mit Menschen mit Behinderungen für die echte Nutzungserfahrung und bei Bedarf ein formales Prüfverfahren. In diesem Artikel erfährst du, was welche Methode leisten kann, welche Werkzeuge sich bewährt haben und wie du daraus einen Testplan baust, der auch im Projektalltag funktioniert. ## Warum ein einzelnes Tool nicht reicht Die WCAG beschreiben Erfolgskriterien, und viele davon lassen sich nicht rein maschinell beurteilen. Ein Tool kann messen, ob der Kontrast zwischen Text und Hintergrund 4,5:1 erreicht. Es kann aber nicht entscheiden, ob eine Fehlermeldung verständlich ist, ob die Reihenfolge, in der der Fokus durch die Seite springt, Sinn ergibt, oder ob ein Video korrekte Untertitel hat. Wie viele Probleme automatisierte Tests insgesamt erkennen, hängt stark von der Website und vom Tool ab. Als grobe Faustregel wird in der Fachwelt oft genannt, dass sie etwa 30 bis 40 Prozent der Barrieren finden. Nimm das nicht als exakte Zahl, sondern als Hinweis auf die Größenordnung: Der größere Teil der Arbeit liegt in manuellen Prüfungen. Gleichzeitig sind automatische Tests unverzichtbar. Die jährliche WebAIM-Million-Analyse der Startseiten der eine Million meistbesuchten Websites findet seit Jahren auf über 94 Prozent automatisch erkennbare WCAG-Fehler. Der häufigste ist zu geringer Textkontrast. Diese Fehler sind leicht zu finden und meist leicht zu beheben. Wer sie nicht automatisiert abfängt, verschenkt Potenzial. ## Was automatisierte Tools finden – und was nicht Zuverlässig erkennen Tools zum Beispiel: - zu geringe Kontraste bei normalem Text ([Kontrast (Minimum)](https://barrierefreihochzwei.de/de/wcag/1-4-3-kontrast-minimum)) - Bilder ohne `alt`-Attribut - Formularfelder ohne zugeordnetes Label - Links und Buttons ohne zugänglichen Namen, etwa Icon-Buttons ohne Text - fehlende Sprachangabe im `html`-Element - ungültige ARIA-Attribute oder Rollen - doppelte IDs, die Beschriftungen ins Leere laufen lassen Nicht oder nur eingeschränkt beurteilen können sie: - ob ein Alternativtext das Bild sinnvoll beschreibt ([Nicht-Text-Inhalt](https://barrierefreihochzwei.de/de/wcag/1-1-1-nicht-text-inhalt)) - ob alle Funktionen per Tastatur erreichbar und bedienbar sind - ob die Fokusreihenfolge logisch ist - ob Fehlermeldungen das Problem verständlich beschreiben - ob Überschriften die Inhalte treffend gliedern - ob Untertitel und Audiodeskriptionen vollständig und korrekt sind - ob Kontraste über Bildern, Verläufen oder in Hover-Zuständen reichen Ein Beispiel aus der Praxis: Ein Tool meldet für einen Produktfilter null Fehler. Jedes Element hat ein Label, alle ARIA-Attribute sind gültig. Im Tastaturtest zeigt sich dann, dass sich das Dropdown zwar mit Tab erreichen, aber nicht mit den Pfeiltasten bedienen lässt, und dass der Fokus nach dem Schließen an den Seitenanfang springt. Technisch sauber, praktisch unbenutzbar. ## Browser-Erweiterungen und Werkzeuge ### axe DevTools axe DevTools von Deque ist eine Erweiterung für die Entwicklertools des Browsers. Sie basiert auf der Open-Source-Prüfbibliothek axe-core, die auch in vielen anderen Tools steckt. Die Ergebnisse sind nach Schweregrad sortiert, verweisen auf das betroffene Element und erklären, wie du den Fehler behebst. axe ist bewusst darauf ausgelegt, möglichst wenige Fehlalarme zu produzieren. ### WAVE WAVE von WebAIM blendet seine Ergebnisse als Symbole direkt in die Seite ein. Das ist besonders für Designer:innen und Redaktionen anschaulich, weil du siehst, wo genau das Problem liegt. Neben Fehlern zeigt WAVE auch Strukturinformationen wie Überschriften und Landmarks an – praktisch, um die Gliederung einer Seite schnell zu überblicken. ### Lighthouse Lighthouse ist in die Chrome-Entwicklertools eingebaut und prüft neben Performance und SEO auch Barrierefreiheit. Für Barrierefreiheit nutzt es ebenfalls Regeln aus axe-core, allerdings nur eine Auswahl. Ein Wert von 100 bedeutet deshalb nur, dass die geprüften automatischen Regeln bestanden sind, nicht, dass die Seite barrierefrei ist. ### Automatisierte Tests in der Pipeline Richtig wirksam werden automatische Checks, wenn sie bei jedem Build laufen. Mit axe-core lassen sich zum Beispiel Playwright-Tests ergänzen: ``` import { test, expect } from '@playwright/test'; import AxeBuilder from '@axe-core/playwright'; test('Warenkorb ohne automatisch erkennbare Fehler', async ({ page }) => { await page.goto('https://shop.example/warenkorb'); const results = await new AxeBuilder({ page }) .withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa']) .analyze(); expect(results.violations).toEqual([]); }); ``` So verhinderst du, dass bereits behobene Fehler mit dem nächsten Release zurückkommen. Teste dabei nicht nur die Startseite, sondern auch Zustände: geöffnete Menüs, Dialoge, Formulare mit Fehlermeldungen. ## Manuelle Checks, die jedes Team schafft Viele wichtige Prüfungen brauchen kein Spezialwissen, nur etwas Zeit und Systematik. Diese fünf solltest du bei jeder neuen Seite und Komponente machen. ### 1. Tastaturtest Leg die Maus weg und bediene die Seite nur mit Tab, Umschalt+Tab, Enter, Leertaste, Pfeiltasten und Escape. Kommst du an jedes Bedienelement ([Tastatur](https://barrierefreihochzwei.de/de/wcag/2-1-1-tastatur))? Kommst du auch wieder heraus, etwa aus einem eingebetteten Video oder einem Dialog ([Keine Tastaturfalle](https://barrierefreihochzwei.de/de/wcag/2-1-2-keine-tastaturfalle))? Ist die Reihenfolge logisch ([Fokusreihenfolge](https://barrierefreihochzwei.de/de/wcag/2-4-3-fokusreihenfolge)), und siehst du jederzeit, wo der Fokus gerade steht ([Fokus sichtbar](https://barrierefreihochzwei.de/de/wcag/2-4-7-fokus-sichtbar))? Mehr dazu im Artikel [Tastatur und Fokus](https://barrierefreihochzwei.de/de/blog/tastatur-fokus-ohne-maus). ### 2. Zoom und Umbruch Vergrößere die Seite im Browser auf 200 und dann auf 400 Prozent. Bei 400 Prozent auf einem üblichen Desktop-Fenster entspricht die Breite ungefähr 320 CSS-Pixeln. Inhalte sollten dann ohne horizontales Scrollen lesbar sein und nichts sollte abgeschnitten werden oder sich überlagern ([Umbruch](https://barrierefreihochzwei.de/de/wcag/1-4-10-umbruch-reflow)). ### 3. Inhalte und Struktur Schau dir die Überschriftenstruktur an, zum Beispiel mit WAVE oder einer Erweiterung, die Überschriften auflistet. Ergibt sie ohne den restlichen Text eine sinnvolle Gliederung? Prüfe Alternativtexte auf Sinn statt nur auf Vorhandensein, und lies Linktexte einmal isoliert: Verstehst du „Mehr“ oder „Hier klicken“ ohne Umgebung? ### 4. Formulare und Fehler Schicke Formulare absichtlich unvollständig oder falsch ab. Wird der Fehler erkannt, im Text beschrieben und dem richtigen Feld zugeordnet ([Fehlerkennzeichnung](https://barrierefreihochzwei.de/de/wcag/3-3-1-fehlererkennung))? Bleiben deine bisherigen Eingaben erhalten? Ist die Meldung auch ohne Farbe erkennbar? ### 5. Kurztest mit Screenreader Ein Screenreader zeigt dir sofort, ob Buttons sinnvoll benannt sind, ob Statusmeldungen angesagt werden und ob Dialoge den Fokus richtig führen. Du musst dafür kein Profi sein. Wie du mit NVDA, VoiceOver oder TalkBack in 15 Minuten die wichtigsten Probleme findest, zeigt der Artikel [Screenreader-Schnelltest](https://barrierefreihochzwei.de/de/blog/screenreader-schnelltest). ## Nutzertests mit Menschen mit Behinderungen Selbst eine Seite, die alle Kriterien erfüllt, kann sich im Alltag umständlich anfühlen. Wie gut ein Angebot wirklich nutzbar ist, erfährst du am verlässlichsten von Menschen, die täglich mit assistiven Technologien arbeiten. Sie bemerken Dinge, die in keiner Checkliste stehen: einen zu langen Weg bis zum Hauptinhalt, verwirrende Ansagen oder einen Ablauf, der zwar möglich, aber mühsam ist. Für einen Nutzertest brauchst du keine große Studie. Schon wenige Sitzungen mit Teilnehmenden, die zum Beispiel einen Screenreader, eine Vergrößerungssoftware oder Sprachsteuerung nutzen, liefern wertvolle Erkenntnisse. Lass sie realistische Aufgaben erledigen, etwa ein Produkt finden und bestellen, und lass sie ihre eigenen Geräte und Einstellungen verwenden. Teilnehmende findest du zum Beispiel über Selbsthilfeorganisationen oder spezialisierte Agenturen. Eine faire Vergütung sollte selbstverständlich sein. Nutzertests ersetzen keine systematische Prüfung gegen die WCAG, sie ergänzen sie. Die Prüfung zeigt, ob die Anforderungen erfüllt sind. Der Nutzertest zeigt, ob das Ergebnis tatsächlich gut funktioniert. ## Formale Prüfverfahren Wenn du eine belastbare Aussage zur Konformität brauchst, etwa als Grundlage für die [Barrierefreiheitserklärung](https://barrierefreihochzwei.de/de/blog/barrierefreiheitserklaerung-richtig-erstellen) oder für Informationen nach dem BFSG, lohnt sich ein strukturiertes Prüfverfahren. Ein international anerkannter Rahmen ist die **WCAG-EM** (Website Accessibility Conformance Evaluation Methodology) des W3C. Sie beschreibt fünf Schritte: Umfang festlegen, das Angebot erkunden, eine repräsentative Stichprobe von Seiten auswählen, die Stichprobe prüfen und die Ergebnisse dokumentieren. Gerade die Stichprobe ist wichtig, denn bei großen Websites kannst du nicht jede Seite einzeln testen. In Deutschland verbreitet ist der **BIK BITV-Test**. Er gliedert die Anforderungen der BITV 2.0 und der EN 301 549 in einzelne Prüfschritte mit genauen Anleitungen. Daneben gibt es Varianten für die WCAG 2.2 und für native Apps. Auch wenn du keinen offiziellen Test beauftragst, sind die öffentlich beschriebenen Prüfschritte eine hervorragende Hilfe, um selbst gründlicher zu testen. Ein externes Audit durch erfahrene Prüfer:innen ist besonders sinnvoll vor einem Relaunch, bei rechtlichen Anforderungen und wenn im Team noch wenig Erfahrung vorhanden ist. Achte darauf, dass der Bericht nicht nur Fehler auflistet, sondern auch den betroffenen Ort, das verletzte Kriterium und einen Lösungsvorschlag nennt. ## So baust du einen Testplan Ein Testplan muss kein dickes Dokument sein. Er beantwortet vier Fragen: Was testen wir, wann, wie und wer? **Was:** Wähle nach dem Vorbild der WCAG-EM eine Stichprobe. Dazu gehören die Startseite, jede Seitenvorlage (zum Beispiel Artikel, Kategorie, Produktdetail), alle zentralen Nutzerwege wie Registrierung, Suche und Checkout sowie wiederkehrende Komponenten wie Navigation, Dialoge und Formulare. **Wann:** Barrierefreiheit beginnt nicht erst beim fertigen Code. Prüfe Kontraste, Fokuszustände und Beschriftungen schon im Design. Lass automatische Tests bei jedem Build laufen. Mache manuelle Checks bei jeder neuen Komponente und vor jedem größeren Release. Plane mindestens einmal im Jahr eine umfassende Prüfung ein, und zusätzlich nach größeren Änderungen. **Wie:** Lege den Maßstab fest, in der Regel WCAG 2.1 AA oder besser 2.2 AA, und die Werkzeuge: zum Beispiel axe in der Pipeline, WAVE für Stichproben, Tastatur- und Screenreader-Tests nach einem festen Ablauf. **Wer:** Benenne Verantwortliche. Entwickler:innen übernehmen automatische und Tastaturtests, Design prüft Kontraste und Zustände, die Redaktion kümmert sich um Alternativtexte und Überschriften. Für die umfassende Prüfung holst du bei Bedarf externe Unterstützung. Dokumentiere Funde in deinem normalen Ticketsystem, nicht in einer separaten Liste, die niemand anschaut. Gib jedem Ticket das betroffene WCAG-Kriterium, den Ort und die Auswirkung für Nutzer:innen mit. Und priorisiere nach Wirkung: Ein Checkout, der per Tastatur nicht abschließbar ist, wiegt schwerer als ein fehlender Alternativtext bei einem Dekorbild. ## Kurze Checkliste - Automatische Tests (zum Beispiel axe) laufen bei jedem Build - Jede neue Komponente per Tastatur getestet - Zoom auf 200 und 400 Prozent geprüft - Überschriften, Alternativtexte und Linktexte inhaltlich geprüft - Formulare mit absichtlichen Fehlern getestet - Screenreader-Kurztest für zentrale Nutzerwege - Nutzertests mit Menschen mit Behinderungen eingeplant - Regelmäßige umfassende Prüfung nach einem festen Verfahren ## Fazit Automatisierte Tools sind ein guter Anfang, aber nur ein Anfang. Sie finden die häufigen, technischen Fehler schnell und zuverlässig und sollten deshalb fest in deinem Entwicklungsprozess verankert sein. Den größeren Teil der Barrieren entdeckst du jedoch erst mit manuellen Checks, mit Screenreader-Tests und im Gespräch mit Menschen, die auf Barrierefreiheit angewiesen sind. Der wichtigste Schritt ist, überhaupt regelmäßig zu testen. Ein einfacher Plan, der wirklich gelebt wird, bringt mehr als ein perfektes Konzept in der Schublade. Wenn du zu einem Fund das passende Kriterium nachschlagen willst, hilft dir der [WCAG-Guide](https://barrierefreihochzwei.de/de/wcag). ## Quellen - [WCAG-EM Overview: Website Accessibility Conformance Evaluation Methodology – W3C WAI](https://www.w3.org/WAI/test-evaluate/conformance/wcag-em/) - [Easy Checks – A First Review of Web Accessibility – W3C WAI](https://www.w3.org/WAI/test-evaluate/preliminary/) - [The WebAIM Million – WebAIM](https://webaim.org/projects/million/) - [WAVE Web Accessibility Evaluation Tools – WebAIM](https://wave.webaim.org/) - [axe-core – Deque Systems auf GitHub](https://github.com/dequelabs/axe-core) - [BIK BITV-Test](https://www.bitvtest.de/)