Barrierefreiheit automatisiert testen: Warum das allein nicht reicht

Was dort steht, ist eine andere Aussage. Ein Werkzeug hat in dem Teil der Anforderungen, den es prüfen kann, nichts gefunden. Google schreibt das sogar selbst unter den Score: Nur ein Ausschnitt der Barrierefreiheitsprobleme lässt sich automatisch erkennen, manuelles Testen wird empfohlen. Diesen Satz liest fast niemand.

Was ein automatisierter Test tatsächlich prüft

Automatisierte Tests prüfen gegen definierte Regeln. Diese Regeln leiten sich aus den WCAG ab, sind aber nicht identisch mit ihnen. Ein Erfolgskriterium ist eine Anforderung an das Ergebnis. Eine Testregel ist ein Stück Code, das eine bestimmte technische Konstellation erkennt.

Untersucht wird dabei nicht der Quelltext, den der Server ausliefert, sondern der DOM: die Seite so, wie der Browser sie nach dem Laden zusammengebaut hat, mit allem was JavaScript und CSS daran verändert haben. Das ist auch nötig, denn bei einer modernen Anwendung steht im ausgelieferten Quelltext oft kaum mehr als ein leeres div.

Manche Anforderungen lassen sich dadurch sehr zuverlässig abbilden. Eine fehlende Beschriftung an einem Formularfeld, ein alt-Attribut das gar nicht existiert, eine Überschriftenebene die übersprungen wird, ARIA-Attribute an Elementen wo sie nicht erlaubt sind: das sind klare Ja-Nein-Fragen. Auch Kontraste lassen sich gut berechnen, solange sich Vorder- und Hintergrundfarbe eindeutig bestimmen lassen.

Genau da fängt der Graubereich an. Steht der Text über einem Farbverlauf, einem Foto oder einem halbtransparenten Overlay, kann das Werkzeug das Verhältnis nicht mehr sicher ermitteln. Gute Tools sagen das auch. axe-core kennt neben violations die Kategorie incomplete, WAVE nennt es „Alerts“, andere Werkzeuge schreiben „Needs Review“. Das ist kein Fehler im Tool, sondern die ehrlichste Ausgabe die es machen kann: Hier muss ein Mensch draufschauen.

In der Praxis werden genau diese Einträge übersehen. Sie sind nicht rot, sie kosten keinen Punkt, sie tauchen im Score nicht auf.

Dabei ist Lighthouse nicht der Maßstab, sondern der schwächste Vertreter seiner Gattung. Fachwerkzeuge wie axe DevTools, WAVE, das ARC Toolkit oder Accessibility Insights decken deutlich mehr Regeln ab, erklären ihre Befunde besser und zeigen die betroffenen Stellen direkt auf der Seite. Wer ernsthaft prüft, arbeitet mit diesen Werkzeugen und nicht mit einer Zahl aus den DevTools.

Nur ändern auch sie nichts am Grundproblem, und sie behaupten es auch gar nicht. Accessibility Insights hat neben dem schnellen Scan einen Assessment-Modus, der einen Schritt für Schritt durch die manuellen Prüfungen führt. WAVE gibt neben den Fehlern die Alerts aus, also die Stellen, die jemand ansehen muss. Das ARC Toolkit ist von vornherein als Werkzeug für Prüfende gebaut, nicht als Automat. Die Hersteller wissen genau, wo die Grenze verläuft, und sie ziehen sie sichtbar ein. Übergangen wird sie erst danach.

Dazwischen liegt eine dritte Kategorie, die selten erwähnt wird: Werkzeuge, die überhaupt nichts bewerten, sondern nur sichtbar machen. Bookmarklets und Prüf-Erweiterungen blenden die Überschriftenstruktur ein, markieren Landmarks, zeigen alt-Texte direkt am Bild oder nummerieren die Tab-Reihenfolge. Sie sagen nicht, ob etwas richtig ist. Sie sorgen dafür, dass jemand es in Sekunden sehen kann statt es im Quelltext zu suchen. Genau davon lebt eine manuelle Prüfung: Nicht davon, dass alles per Hand ausgezählt wird, sondern davon, dass die Bewertung bei einem Menschen bleibt.

Wenn das Werkzeug sich irrt

Ein automatisierter Test ist immer nur so gut wie der Code, der ihn ausführt. Und dieser Code kann Fehler haben, die für die prüfende Person überhaupt nicht nachvollziehbar sind.

Ein Beispiel aus Lighthouse selbst: Die Prüfung auf font-display erwartete die Eigenschaft mit abschließendem Semikolon. Steht sie am Ende eines Blocks und wird das CSS im Build minifiziert, fällt dieses Semikolon weg. Valides CSS, korrekt gesetzte Eigenschaft, trotzdem ein gemeldeter Fehler. Behoben wurde das 2019 in einem Pull Request mit dem Titel „limit false positives“ (öffnet in neuem Tab). Das ist ein Performance-Audit und kein Barrierefreiheits-Audit, aber es ist dieselbe Art von Regel, in derselben Software, mit derselben Fehleranfälligkeit.

Im Barrierefreiheitsbereich sieht derselbe Effekt so aus: Text vor einem Farbverlauf, ein Kontrastwert der nicht eindeutig bestimmbar ist, und je nach Werkzeug ein gemeldeter Verstoß, obwohl die tatsächlich sichtbare Kombination passt. Oder ein Element, das aus Sicht des Tools keinen zugänglichen Namen hat, weil die Beschriftung erst zur Laufzeit gesetzt wird.

Wer sich fragt, warum ein Werkzeug etwas anmeckert das nachweislich korrekt ist, sucht den Fehler meistens bei sich selbst. Manchmal liegt er im Werkzeug. Deswegen gehört zu jedem Befund die Frage, ob er stimmt, und die kann nur jemand beantworten, der die Regel dahinter kennt.

False Positives sind ärgerlich, aber sie fallen auf. Jemand schaut hin, wundert sich, prüft nach. Das eigentliche Risiko liegt in der anderen Richtung.

Das größere Problem: was gar nicht erst auffällt

Manuel Matuzović hat vor Jahren eine Seite gebaut, die praktisch unbenutzbar ist und trotzdem einen perfekten Lighthouse-Score erreicht (öffnet in neuem Tab). Das Beispiel ist alt und wird immer noch zitiert, weil sich am Grundproblem nichts geändert hat.

Zur Einordnung: Diese Seite ist mit Vorsatz gebaut. Sie ist der Beweis, dass ein perfekter Score und völlige Unbenutzbarkeit zusammenpassen können, nicht die Beschreibung eines Normalfalls. Bei einer gewachsenen Website steckt hinter den Befunden selten Absicht, sondern Zeitdruck und fehlendes Wissen. Trotzdem: Was Matuzović bewusst getan hat, passiert im Alltag unbewusst. Die Konstrukte sind dieselben.

Vor allem aber zeigt das Beispiel, worauf es ankommt. Nicht nur darauf, dass manuell geprüft wird, sondern dass jeder Befund verifiziert wird. Ein gemeldeter Fehler kann keiner sein, ein grüner Haken kann ein übersehener Fehler sein, und beides fällt nur jemandem auf, der die Regel dahinter kennt und nachschaut. Ein Werkzeug liefert Hinweise. Die Bewertung, ob ein Hinweis stimmt, ist Handarbeit.

Ein Klassiker, der durch jeden automatisierten Test läuft:

<div role="button" tabindex="0" onclick="submitForm()">Absenden</div>

Formal ist alles da. Es gibt eine Rolle, das Element ist fokussierbar, es hat einen zugänglichen Namen. Kein Werkzeug wird hier etwas melden. Trotzdem ist es kaputt: Ein nativer Button reagiert auf Enter und Leertaste, dieses Konstrukt auf keins von beidem. Wer mit der Tastatur arbeitet, kommt auf das Element und dann nicht weiter.

<button type="submit">Absenden</button>

Das ist die Lösung, und es ist genau die Art von Erkenntnis, die aus einem Score nie herausfällt.

Dasselbe bei Alternativtexten. Ein Werkzeug kann prüfen, ob ein alt-Attribut vorhanden ist. Ob es stimmt, kann es nicht prüfen:

<!-- Kein Werkzeug meldet hier einen Fehler -->
<img src="team.jpg" alt="Bild" />
<img src="chart-umsatz.png" alt="chart-umsatz.png" />
<img src="logo.svg" alt="Logo" />

Alle drei erfüllen die Regel und keiner der drei Texte hilft irgendjemandem weiter. Beim Logo kommt hinzu, dass die Antwort vom Kontext abhängt: Ist es mit der Startseite verlinkt und steht nichts weiter daneben, braucht es einen Namen. Steht der Firmenname als Text direkt daneben, ist das Bild redundant und der Alternativtext gehört leer. Sonst hört man denselben Namen zweimal.

Damit sind wir bei einem Fall, der in die andere Richtung geht: alt="" ist eine bewusste Entscheidung und oft die richtige. Beim Teamfoto, neben dem der Name als Text steht. Beim dekorativen Trenner. Beim Icon neben einer Beschriftung, die schon alles sagt. Trotzdem melden manche Werkzeuge genau das als Fehler, vor allem im SEO-Umfeld, wo ein gefüllter Alternativtext gern pauschal als Qualitätsmerkmal gilt.

<!-- Richtig, obwohl manches Tool hier meckert -->
<img src="portrait-schmidt.jpg" alt="" />
<p>Anna Schmidt, Geschäftsführung</p>

Wer solche Meldungen abarbeitet, ohne sie zu prüfen, verschlechtert die Barrierefreiheit, um eine Liste grün zu bekommen. Das ist kein Einzelfall, sondern ein Muster: gut gemeinte Umsetzung, die mehr Barrieren schafft als sie abbaut, vom zu ausführlichen Alternativtext bis zum aria-label, das die eigentliche Beschriftung überschreibt.

Die Liste lässt sich fortsetzen. Ob die Reihenfolge im Code der visuellen Reihenfolge entspricht. Ob ein Fokus sichtbar ist und nicht nur vorhanden. Ob eine Überschrift den Inhalt darunter beschreibt oder nur nach Überschrift aussieht. Ob eine Fehlermeldung angekündigt wird oder still im DOM erscheint. Ob eine Bewegung nach fünf Sekunden stoppt. Nichts davon ist ein Randfall, alles davon ist Alltag.

Wie viel von der Website wird überhaupt geprüft?

Neben der Frage, was geprüft wird, gibt es eine zweite, die noch seltener gestellt wird: wo geprüft wird.

Hier trennt sich, was in einen Topf geworfen wird. Ein Klick auf „Lighthouse“ in den DevTools prüft eine URL, in dem Zustand, in dem sie nach dem Laden ist. Was danach passiert, sieht dieser Lauf nicht. Das offene Menü nicht, das Modal nicht, den Fokus nach dem Schließen nicht, das Formular im Fehlerzustand nicht.

Und er kommt in weite Teile der Anwendung gar nicht erst hinein. Alles hinter einem Login, die Warenkorb- und Checkout-Strecke, der Bereich nach der Terminbuchung, das Kundenkonto: also genau die Stellen, an denen eine Barriere nicht nur nervt, sondern jemanden davon abhält, ein Geschäft abzuschließen. Genau diese Prozesse stehen im BFSG im Mittelpunkt.

Technisch ist das lösbar. Ein Crawler kann die ganze Domain abgehen statt einer Seite, und mit einem Setup wie Playwright lässt sich vor der Prüfung einloggen, ein Formular absenden oder ein Dialog öffnen. Dann läuft die Analyse auf einem Zustand, an den ein einfacher Scan nie kommt. Das ist aber kein Automatismus, sondern Arbeit: Jeder dieser Zustände muss vorher jemand beschrieben haben. Wenn also jemand sagt, seine Seite sei automatisiert getestet, ist die erste Rückfrage nicht womit, sondern wie viel davon.

Das relativiert auch die großen Erhebungen. Der WebAIM Million Report (öffnet in neuem Tab) untersucht jedes Jahr eine Million Startseiten, im Februar 2026 mit einem unerfreulichen Ergebnis: 95,9 Prozent der Startseiten hatten automatisch erkennbare WCAG-Verstöße, durchschnittlich 56 Fehler pro Seite. Erstmals seit sechs Jahren wurde die Lage wieder schlechter statt besser. Das sind Startseiten, mit einem automatisierten Werkzeug geprüft. Der Rest der Website und der Rest der Anforderungen sind in dieser Zahl nicht enthalten.

Was nur ein Mensch prüfen kann

Je nach Quelle lassen sich etwa 30 bis 40 Prozent der Anforderungen automatisiert prüfen. Die Spanne schwankt, weil unterschiedlich gezählt wird: mal Erfolgskriterien, mal Fehlerinstanzen, mal Prüfschritte. Die Größenordnung ist aber unstrittig. Die Mehrheit der Anforderungen braucht eine Bewertung, und Bewertung heißt: ein Mensch, der den Kontext versteht.

Für ein vollständiges Barrierefreiheits-Audit ist manuelles Prüfen deshalb keine Ergänzung, sondern der Hauptteil der Arbeit. Ein Beispiel für die Größenordnung: Der BIK BITV-Test, eines der etablierten Verfahren in Deutschland, umfasst inzwischen 98 Prüfschritte und wird von qualifizierten Prüfenden durchgeführt, unterstützt durch Bookmarklets und Werkzeuge, aber nicht ersetzt durch sie. Er ist nicht der einzige Weg. Geprüft werden kann ebenso direkt gegen die EN 301 549 oder nach einer anderen dokumentierten Methodik.

Wichtig ist dabei, was „manuell“ nicht heißt: nach Gefühl. Wie eine Konformitätsprüfung abläuft, ist selbst standardisiert. Die Website Accessibility Conformance Evaluation Methodology (WCAG-EM) (öffnet in neuem Tab) des W3C beschreibt die Schritte: Geltungsbereich festlegen, das Angebot erkunden, eine repräsentative Stichprobe von Seiten ziehen, prüfen, dokumentieren. Der Punkt mit der Stichprobe ist der, der in der Praxis am häufigsten schiefgeht. Wer nur die Startseite und zwei Textseiten prüft, hat keine Aussage über das Angebot, sondern über drei Seiten.

Dazu kommt, dass sich ein Teil der Anforderungen pro Seite überhaupt nicht beantworten lässt. Ob die Navigation an derselben Stelle in derselben Reihenfolge steht, ob dieselbe Funktion überall gleich heißt, ob es mehr als einen Weg zu einer Seite gibt, ob Hilfe und Kontakt durchgängig erreichbar sind: Das sind Aussagen über das Angebot, nicht über ein Dokument. Sie ergeben sich erst aus dem Vergleich mehrerer Seiten. Ein Werkzeug, das eine URL nach der anderen abarbeitet, kann diese Frage von seiner Anlage her nicht stellen, und dasselbe gilt für eine Prüfung, die zwar manuell ist, aber jede Seite isoliert betrachtet.

Entscheidend ist am Ende nicht das Etikett des Verfahrens, sondern dass die Auswahl begründet, jeder Prüfschritt bewertet und die Bewertung nachvollziehbar ist.

Die Fragen, um die es dabei geht, sind inhaltliche:

• Beschreibt der Alternativtext das Bild in diesem Kontext richtig? Dasselbe Foto braucht im Teamporträt einen anderen Text als im Artikel über Arbeitsschutz.
• Gibt die Überschrift wieder, was darunter steht?
• Ist die Tastaturreihenfolge nicht nur technisch gültig, sondern auch logisch?
• Funktioniert die selbst gebaute Komponente wirklich, oder sieht sie nur richtig aus?

Der letzte Punkt ist der teuerste. Ein Werkzeug prüft, ob ein tabindex-Wert zulässig gesetzt ist. Ob das JavaScript dahinter die Pfeiltasten korrekt behandelt, den Fokus beim Schließen zurückgibt und den Zustand über aria-expanded sauber kommuniziert, prüft es nicht. Dafür braucht es jemanden, der die Komponente bedient und den Code liest.

Wofür automatisierte Tests unverzichtbar sind

Nach all dem könnte man sie für nutzlos halten. Das wäre falsch, und es wäre auch nicht die Konsequenz, die ich Kunden empfehle.

Automatisierte Tests haben eine Stärke, die manuelles Prüfen nie haben wird: Sie skalieren. Ein Mensch prüft eine repräsentative Auswahl von Seiten. Ein Skript prüft zehntausend, jede Nacht, und meldet Abweichungen.

Der Wert liegt dabei weniger in der absoluten Zahl als in ihrer Veränderung. Wenn eine Website über Monate bei einer stabilen Größenordnung liegt und die Fehlerzahl von einem Tag auf den anderen um ein Vielfaches hochgeht, ist das ein klares Signal. Meistens steckt etwas Banales dahinter: ein Plugin-Update, ein neues Theme, eine geänderte Designvariable die den Kontrast auf allen Buttons kippt, ein Komponenten-Refactoring das Beschriftungen verschluckt. Kein Werkzeug sagt einem, wie schlimm das ist. Aber es sagt einem, dass man hinschauen sollte, und zwar am selben Tag statt beim nächsten Audit in achtzehn Monaten. Für diese Art von Frühwarnung gibt es keinen manuellen Ersatz.

Der zweite Punkt ist der Zeitpunkt. Ein Audit findet einen Fehler, wenn er schon live ist. Ein Test in der Pipeline findet ihn im Pull Request, also bevor er überhaupt jemanden erreicht und solange die Änderung noch offen auf dem Tisch liegt. Wer Barrierefreiheit dauerhaft halten will, braucht diese Ebene.

Der Einstieg ist dabei niedriger, als viele denken. axe-core lässt sich in Playwright oder Cypress einhängen, pa11y-ci prüft eine Liste von URLs gegen einen Schwellwert und bricht den Build ab, wenn etwas dazukommt. Einmal eingerichtet läuft das von allein weiter. Während der Entwicklung tut es die Browser-Erweiterung: einmal draufhalten, bevor die Komponente in den Review geht. Das findet keine Konzeptfehler, aber es verhindert, dass dasselbe fehlende Label fünfzigmal ins Repository wandert.

Und der dritte, unbequeme Punkt: Angesichts der WebAIM-Zahlen scheitern die meisten Websites schon an dem, was Automaten finden. Fehlende Beschriftungen, zu geringe Kontraste, leere Links. Wer dort anfängt, hat noch keine barrierefreie Website, aber den größten Teil des offensichtlichen Schadens beseitigt. Das ist kein Grund, beim Score stehenzubleiben. Es ist ein guter Grund, dort anzufangen.

import { test, expect } from "@playwright/test";
import AxeBuilder from "@axe-core/playwright";

test("Startseite ohne automatisch erkennbare Verstöße", async ({ page }) => {
    await page.goto("/");

    const ergebnis = await new AxeBuilder({ page })
        .withTags(["wcag2a", "wcag2aa", "wcag21aa", "wcag22aa"])
        .analyze();

    expect(ergebnis.violations).toEqual([]);
});

Und in Zeiten von KI?

Die naheliegende Frage: Wenn Sprachmodelle immer besser werden, warum nicht gleich die Prüfung an sie abgeben?

Ein Teil der Aufgabe passt tatsächlich gut. Ein Modell kann Code lesen, Muster erkennen, Formulierungsvorschläge für Alternativtexte machen und eine zweite Meinung liefern, wenn man an einer Komponente feststeckt. Als Sparringspartner ist das nützlich, und ich nutze es selbst so.

Das Problem liegt woanders. Ein Sprachmodell erzeugt plausible Ausgaben, keine überprüften. Es kann eine Komponente als konform bewerten, die es nicht ist, und diese Bewertung mit einer erfundenen Kriteriumsnummer belegen. Ein automatisierter Test ist im Zweifel stumpf, aber deterministisch: Dieselbe Seite ergibt dasselbe Ergebnis, und die Regel ist nachlesbar. Bei einem Modell ist beides nicht garantiert.

Dazu kommt die Frage der Grundlage. Ein Modell kennt die WCAG aus Trainingsdaten und aus dem, was ihm im Kontext mitgegeben wird. Fälle, die aus dem Schema ausbrechen, also selbst gebaute Widgets, ungewöhnliche Interaktionsmuster, branchenspezifische Anwendungen, sind genau die Fälle, in denen ein Audit gebraucht wird. Und es sind die, in denen ein Modell am ehesten daneben liegt.

Der praktisch wichtigste Punkt: Eine Konformitätsbewertung ist eine Aussage, für die jemand geradesteht. Ein Modell kann das nicht. Es ersetzt, Stand Spätsommer 2026, keine manuelle Prüfung. Was es sehr wohl tut: massenhaft Code erzeugen, der Barrieren enthält. Der Prüfbedarf wird durch KI nicht kleiner.

Werkzeuge sind nicht dasselbe wie Nutzende

Egal ob KI oder axe-core, WAVE und ARC Toolkit: Sie alle gleichen gegen Regeln und Listen ab. Wie eine Seite tatsächlich ausgegeben wird, zeigen sie nicht.

Ein Screenreader ist mehr als eine Vorlesefunktion. Er gibt Text als Sprache oder auf einer Braillezeile aus, er navigiert über Überschriften, Landmarks, Links und Formularelemente, und er interpretiert dabei den Accessibility-Tree. Genutzt wird er von blinden und sehbehinderten Menschen, in Teilen auch von Menschen mit Lese- oder Konzentrationsschwierigkeiten. Wie das Ergebnis klingt, unterscheidet sich zwischen NVDA, JAWS und VoiceOver, zwischen Browsern und zwischen Versionen. Das lässt sich nur feststellen, indem man es tut.

Und dann kommt die Stufe darüber. Wer täglich mit einem Screenreader arbeitet, benutzt ihn anders als ich in einem Test. Deutlich höhere Sprechgeschwindigkeit, eingespielte Tastenkürzel, andere Erwartungen an die Struktur. Braillezeilen, Tastersteuerung oder individuell angepasste Eingabegeräte lassen sich sinnvoll nur von den Menschen bewerten, die sie benutzen.

Ein Screenreader-Test durch eine sehende Person ist deshalb kein Nutzertest. Er ist ein Werkzeugtest, und als solcher ist er unverzichtbar. Er beantwortet zwei Fragen: Funktioniert das technisch, und kommt dabei ein brauchbares Ergebnis heraus? Heißt der Button „Warenkorb öffnen“ oder „Grafik Link“? Wird die Fehlermeldung angekündigt oder erscheint sie stumm? Das ist Bewertung, und die setzt Fachkenntnis voraus, keine eigene Behinderung.

Was dieser Test nicht beantwortet, ist die dritte Frage: Kommt jemand im Alltag damit ans Ziel? Bei doppelter Sprechgeschwindigkeit, mit eingespielten Tastenkürzeln, unter Zeitdruck, auf einer Seite die man nicht kennt.

Umgekehrt gilt genauso: Ein Nutzertest mit drei Personen ersetzt kein Audit. Er findet die Stellen, die im Prüfkatalog nicht vorkommen, und er sagt nichts über die Konformität aus. Die Stufen ersetzen einander nicht, sie bauen aufeinander auf.

Damit kein falscher Eindruck entsteht: Eine Prüfung setzt keine eigene Behinderung voraus. Ob eine Anforderung erfüllt ist, entscheidet sich an der Norm, am Code und am Verhalten der Hilfsmittel. Das ist Fachkompetenz, und die erwirbt man durch Ausbildung, Prüfverfahren und tägliche Arbeit mit den Werkzeugen. Wer ein Haus statisch berechnet, muss nicht darin wohnen. Was eine prüfende Person nicht leisten kann, ist die andere Frage: wie sich die Benutzung anfühlt, wo jemand mit zwanzig Jahren Screenreader-Routine aussteigt, welcher Umweg im Alltag akzeptabel ist und welcher nicht. Wobei „nicht leisten“ zu hart formuliert ist. Erfahrung aus Gesprächen, aus Schulungen, aus dem Austausch mit Nutzenden und aus früheren Projekten fließt in jede Bewertung ein, und sie gehört zur Fachkompetenz dazu. Ich weiß aus solchen Gesprächen, welche Muster regelmäßig für Ärger sorgen, und das prüfe ich entsprechend.

Nur ist das Erfahrungswissen, kein Befund an Ihrem Produkt. Es sagt, worauf zu achten ist, nicht ob es hier funktioniert. Dafür gibt es Nutzertests. Sie beantworten eine zusätzliche Frage, nicht dieselbe noch einmal.

Was das für BFSG und BITV bedeutet

Für alle, die unter das Barrierefreiheitsstärkungsgesetz oder die BITV fallen, hat das eine handfeste Konsequenz: Ein Score ist kein Nachweis.

Verlangt wird die Erfüllung der zugrunde liegenden Standards, in der Praxis also der EN 301 549 mit den WCAG-Anforderungen auf Stufe AA. Die lässt sich mit einem automatisierten Werkzeug schlicht nicht feststellen, weil die Mehrheit der Anforderungen eine Bewertung braucht. Öffentliche Stellen müssen zusätzlich eine Erklärung zur Barrierefreiheit veröffentlichen, in der der Stand benannt wird, einschließlich der Bereiche die nicht konform sind. Wer diese Erklärung auf einen Lighthouse-Lauf stützt, gibt eine Aussage ab, die sich nicht belegen lässt.

Für Unternehmen unter dem BFSG ist die Lage ähnlich: Die Marktüberwachung fragt im Zweifel nicht nach dem Score, sondern nach der Bewertung. Und sie fragt nach den Prozessen, also Kaufabschluss, Terminbuchung, Kundenkonto. Genau die Bereiche, die ein automatisierter Scan nicht erreicht.

Dasselbe gilt außerhalb der Pflicht. Wer einem Kunden, einem Auftraggeber oder der eigenen Konzernmutter den Stand belegen soll, braucht zwei Angaben. Erstens den Maßstab: WCAG 2.2 auf Stufe AA oder die EN 301 549, die für den Webbereich auf die WCAG verweist und darüber hinaus weitere Anforderungen enthält. Zweitens das Verfahren, nach dem geprüft wurde, und wer dafür geradesteht. In der Praxis heißt das ein Audit durch eine fachkundige Person: geprüft wird gegen einen Katalog, jeder Prüfschritt wird bewertet, und heraus kommt ein Bericht mit Befunden, Verortung und Handlungsempfehlung.

Was am Ende zählt, ist in allen Fällen dasselbe: eine Bewertung pro Anforderung statt einer Zahl. Ein Score-Screenshot beantwortet keine einzige Frage, die in so einem Bericht steht.

Wie ich es Kunden erkläre

Drei Ebenen, in dieser Reihenfolge.

Automatisiert läuft dauerhaft mit. In der Pipeline, im Monitoring, über alle Seiten. Das hält die Basis sauber und fängt Rückschritte ab, bevor sie live gehen.

Manuell geprüft wird an einer repräsentativen Auswahl, von einem Menschen, gegen einen Prüfkatalog. Hier fällt der Großteil der Befunde an, und hier entsteht die Aussage, die für BFSG oder BITV trägt.

Mit echten Nutzenden getestet wird da, wo es wirklich drauf ankommt: an den Prozessen, mit denen Ihr Geschäft steht und fällt. Das ist die aufwendigste Stufe und die einzige, die beantwortet, ob jemand tatsächlich ans Ziel kommt.

Diese Ebenen greifen ineinander, und sie tun es in beide Richtungen. Der automatisierte Lauf verkürzt die manuelle Prüfung, weil das Offensichtliche schon weg ist. Die manuelle Prüfung sagt umgekehrt, worauf das Monitoring künftig achten muss und welche Meldungen keine sind. Und was im Nutzertest auffällt, landet als Prüfschritt im nächsten Audit. Was keine der Ebenen kann, ist die anderen ersetzen.

Der grüne Score ist nicht wertlos. Er ist der Anfang. Nur eben nicht der Beweis.