Barrierefreiheit testen: So prüfst du deine Website richtig

Bevor du Barrieren beheben kannst, musst du sie finden. Testen ist der erste und wichtigste Schritt zu einer barrierefreien Website – und zugleich der, bei dem die meisten Fehler gemacht werden. Denn „Website auf Barrierefreiheit prüfen” wird oft auf einen schnellen Tool-Scan reduziert, und genau das führt in die Irre: Ein Tool sieht nur einen Teil.

Dieser Artikel zeigt, was automatisierte Tests können und was nicht, wie manuelle Prüfung und assistive Technologien den Rest abdecken, und wie aus einem Testergebnis echte Behebung wird – statt eines grünen Häkchens, das nichts beweist.

Warum Testen der erste Schritt ist

Du kannst nichts beheben, was du nicht kennst. Wie groß das Problem typischerweise ist, zeigt die WebAIM-Million-Studie: 2024 fanden sich auf über 96 % der untersuchten Startseiten automatisch erkennbare WCAG-Fehler. Das Problem ist also fast universell – und der erste Schritt zur Lösung ist eine ehrliche Bestandsaufnahme.

Wichtig ist die Haltung dahinter: Testen ist kein einmaliger Akt, sondern Teil eines Kreislaufs aus Prüfen, Beheben und erneutem Prüfen. Wie das insgesamt zusammenhängt, beschreibt Website barrierefrei machen

Automatisierte Tests: schnell, aber begrenzt

Automatisierte Werkzeuge sind ein guter Anfang. Sie finden Fehler mit klaren, programmierbaren Regeln zuverlässig und über viele Seiten hinweg: fehlende Alternativtexte, unzureichende Kontraste, fehlende Formular-Beschriftungen, strukturelle Probleme.

Ihre Grenze ist aber prinzipiell – und hier lohnt Ehrlichkeit statt Marketing-Zahlen. Gemessen an den WCAG-Erfolgskriterien können automatisierte Tools nur etwa ein Drittel sinnvoll prüfen, rund 16 der 50 Kriterien für Stufe AA. Der Rest verlangt menschliches Urteil.

Eine wichtige Nuance gehört dazu: Misst man stattdessen die schiere Menge der gefundenen Einzelfehler, liegt die Quote höher – Deque nennt für sein Werkzeug axe-core etwa 57 % –, weil häufige Fehlertypen wie Kontrast in großer Zahl auftreten und automatisch auffindbar sind. Das bedeutet aber nicht „57 % konform”. Es bedeutet nur: Das Tool findet viele Einzelfälle, übersieht aber ganze Kategorien von Anforderungen.

Der Grund ist einfach: Ein Tool kann nicht beurteilen, ob ein Alternativtext inhaltlich sinnvoll ist, ob ein Bild dekorativ oder informativ ist, ob die Fokusreihenfolge logisch ist oder ob ein Text verständlich formuliert wurde. Was Tools können und wo genau sie aussteigen, vertieft Automatisierte WCAG-Tests

Ein Warnsignal noch: Falsch eingesetztes ARIA macht eine Seite nicht besser, sondern schlechter – Seiten mit ARIA weisen im Schnitt mehr erkannte Fehler auf als solche ohne. Genau das produzieren Overlays und überhastete Quick-Fixes (mehr dazu in Accessibility-Overlays).

Manuelle Prüfung: was Tools nicht sehen

Hier prüft ein Mensch, was Urteilsvermögen verlangt – also der größere Teil der Kriterien:

• Sind Alternativtexte inhaltlich sinnvoll, nicht nur vorhanden?
• Ist die Fokusreihenfolge logisch und nachvollziehbar?
• Sind Inhalte, Beschriftungen und Anweisungen verständlich?
• Funktionieren interaktive Abläufe – Formulare, Filter, Menüs – tatsächlich für alle?

Diese Prüfung ist kein „Nice-to-have”, sondern der Teil, ohne den keine belastbare Aussage über Konformität möglich ist.

Test mit assistiven Technologien

Den realsten Eindruck gewinnst du, wenn du die Seite so nutzt wie betroffene Menschen:

• Tastaturtest: Bediene die gesamte Seite nur mit Tabulator, Enter und Pfeiltasten. Kommst du überall hin? Ist der Fokus immer sichtbar? Gibt es Stellen, aus denen du nicht mehr herauskommst?
• Screenreader-Test: Geh mit einem Screenreader durch die Seite – NVDA ist unter Windows kostenlos, VoiceOver ist in macOS und iOS integriert, TalkBack in Android. Wird alles sinnvoll vorgelesen? Stimmen Überschriften und Orientierungspunkte?
• Echte Nutzer: Wo möglich, ist das Testen mit Menschen mit Behinderungen die aussagekräftigste Prüfung überhaupt.

Vom Testergebnis zur Behebung

Testen ist kein Selbstzweck. Das Ergebnis ist eine Liste echter Probleme – und die werden im Quellcode behoben, nicht überdeckt. Der Kreislauf dahinter: prüfen, im Code beheben, erneut prüfen, und der nachweisbare Wert steigt Schritt für Schritt.

Genau hier setzt ein ehrlicher Scanner an: Er zeigt die echten Quellcode-Probleme und macht den Fortschritt über erneute Scans messbar – statt ein grünes Häkchen zu simulieren, das einer Prüfung nicht standhält. Welcomas kommender WCAG-Scanner ist dafür gebaut: aufdecken, was wirklich da ist, damit du es beheben kannst.

Tools im Überblick

• Für den schnellen Erstbefund: axe (Deque), WAVE (WebAIM), Lighthouse (in Chrome eingebaut) und Pa11y (für automatisierte Pipelines). Sie liefern in Minuten eine erste Fehlerliste.
• Für die manuelle Prüfung mit assistiver Technik: NVDA, VoiceOver, TalkBack.

Entscheidend ist: Keines dieser Werkzeuge ersetzt die anderen. Ein Tool gibt dir den schnellen Überblick, die manuelle Prüfung die Tiefe, die assistive Technik die Realität. Und ein einzelnes „grünes” Tool-Ergebnis ist kein Konformitätsnachweis – wer das behauptet, verkauft Schein statt Substanz.