Barrierefreiheits-Monitoring als Kategorie wurde in den letzten vierundzwanzig Monaten durch drei Kräfte neu gestaltet, und die Kaufentscheidung im Jahr 2026 sieht anders aus als die von 2023. Erstens wurde der European Accessibility Act (Europäischer Rechtsakt zur Barrierefreiheit, EAA) im Juni 2025 durchsetzbar, und die darauf folgenden Beschaffungswellen in allen siebenundzwanzig Mitgliedstaaten haben den EU-Anteil am Monitoring-Markt erstmals über den US-Anteil gehoben. Zweitens hat die DOJ-Title-II-Regel von 2024 die US-Anforderung für den öffentlichen Sektor verschärft und einen Beschaffungszyklus über staatliche und lokale Behörden ausgelöst, der noch im Gange ist. Drittens hat das Feld schließlich die unbequeme empirische Tatsache verinnerlicht, dass automatisiertes Scanning allein nur irgendwo zwischen dreißig und vierzig Prozent der WCAG 2.2 Erfolgskriterien erkennt — was bedeutet, dass die Wahl einer Plattform jetzt viel weniger von der „Scanner-Genauigkeit“ abhängt und viel mehr vom Workflow. Die Frage lautet: Wie wird aus Scan-Output Triage, aus Triage Behebung und aus Behebung eine verifizierte, verteidigungsfähige, veröffentlichbare Erklärung zur Barrierefreiheit?

Dieser Leitfaden richtet sich an die Beschaffungsverantwortlichen, die Engineering-Direktorin oder den Engineering-Direktor, die Compliance-Beauftragte oder den Compliance-Beauftragten und die Barrierefreiheits-Fachkraft, die gebeten wurde, Plattformen in die engere Auswahl zu nehmen. Er vergleicht sechs namentlich genannte Anbieter nach den Kriterien, die tatsächlich über den Vertrag entscheiden. Zuvor lohnt es sich, präzise zu klären, was „Barrierefreiheits-Monitoring“ ist und was nicht — denn die Anbieter verwischen die Kategorien absichtlich. Wer eine Basiskenngröße für die eigene Website haben möchte, bevor es weitergeht: der kostenlose Disability-World-Scanner liefert in unter einer Minute eine Zahl.

Die Kategorie ist jünger als ihr Vokabular vermuten lässt, und vier verschiedene Produkte werden routinemäßig unter überlappenden Bezeichnungen verkauft. Sie zu trennen ist der erste nützliche Schritt in jedem Käufergespräch.

Ein Scanner ist eine einmalige URL-Prüfung. Eine einzelne Seite wird eingegeben, das Tool ruft sie ab, führt ein Regelwerk aus — üblicherweise axe-core oder ein Derivat — und gibt eine Liste von Verstößen aus. Browser-Erweiterungen wie axe DevTools, Lighthouses Barrierefreiheits-Audit, die WAVE-Toolbar und die meisten kostenlosen Online-Scanner gehören in diese Kategorie. Scanner sind ein Massenprodukt. Die zugrundeliegenden Regelwerke sind größtenteils dieselben Open-Source-Engines unter verschiedenen Oberflächen, und die Ergebnisse der wichtigsten Scanner auf einer bestimmten Seite weichen selten um mehr als wenige Prozent voneinander ab.

Monitoring ist die kontinuierliche Version. Eine Monitoring-Plattform crawlt eine Website oder App nach einem Zeitplan, baut eine Basislinie auf und meldet dann Diffs, wenn Deploys eintreffen. Während ein Scanner die Frage beantwortet „Was ist auf dieser Seite falsch?“, beantwortet eine Monitoring-Plattform die Frage „Was hat sich seit Dienstag verändert?“ — und diese Diff-Ansicht ist das, was die Engineering-Organisation tatsächlich nutzt. Monitoring skaliert Scanner-Output auf einen Bestand von Seiten, eine Organisation mit mehreren Eigenschaften oder eine Produktoberfläche, die zwanzigmal täglich ausgeliefert wird.

Ein Audit ist die manuelle Überprüfung. Eine Fachkraft — zunehmend eine Testerin oder ein Tester mit einer Behinderung, die oder der den Screenreader nutzt, den sie oder er täglich verwendet — geht das Produkt von Anfang bis Ende durch und meldet die Probleme, die Automatisierung nicht erkennen kann. Tastaturbarrieren, Fokusreihenfolge-Qualität, Screenreader-Lesbarkeit, die tatsächliche Bedeutsamkeit von Alternativtext, das Verhalten dynamischer Inhaltsaktualisierungen, die Verständlichkeit von Fehlermeldungen. Der Audit ist die Schicht, die die sechzig bis siebzig Prozent der WCAG-Probleme erkennt, die Scanner übersehen.

Eine Erklärung oder ein Compliance-Dashboard ist das veröffentlichte Artefakt und der Workflow, der es erstellt. Unter dem EAA, unter den Vorschriften für öffentliche Stellen im Vereinigten Königreich, unter der Section-508-Beschaffung und im Rahmen von EN 301 549 muss die kaufende Partei etwas veröffentlichen — eine Erklärung zur Barrierefreiheit, die für eine Regulierungsbehörde klar lesbar ist, die Konformitätsstufe nennt, die bekannten Probleme aufführt und das Datum der nächsten Überprüfung angibt. Ein „Compliance-Dashboard“ ist die interne Version, die dieselbe Haltung für das Führungsteam verfolgt.

Eine Monitoring-Plattform — was dieser Leitfaden vergleicht — ist das Produkt, das Scanner-Output, kontinuierlichen Crawl, Triage, optionalen manuellen Audit und Erklärungsgenerierung in einen einzigen Workflow zusammenführt. Die Scanner-Schicht ist ein Massenprodukt. Die Plattform-Schicht ist der Ort, an dem die Differenzierung und der Wert des Vertrags liegen.

Acht Kriterien unterscheiden die Plattformen im Jahr 2026. Die Anbieter werden die Antworten nicht immer freiwillig liefern; nachfragen lohnt sich trotzdem.

Die einzelne diagnostischste Frage. WCAG 2.2 wurde im Oktober 2023 zur W3C-Empfehlung und fügt neun Erfolgskriterien hinzu — Fokuserscheinung, Ziehbewegungen, Zielgröße, zugängliche Authentifizierung, redundante Eingabe, konsistente Hilfe. Einige Anbieter scannen weiterhin gegen Version 2.1 und nennen das Dashboard trotzdem „2.2-bereit“, ohne die neuen Kriterien zu unterstützen. Die ehrliche Antwort lautet, dass die meisten automatisierten Regelwerke nur einen Teil der 2.2-Kriterien abdecken, weil mehrere der neuen Kriterien (z. B. zugängliche Authentifizierung, konsistente Hilfe) für statische Analyse nicht geeignet sind. Die Plattform sollte angeben, welche 2.2-Kriterien sie automatisch abdeckt, welche sie für manuelle Überprüfung bereitstellt und auf welche Version von EN 301 549 sie ihre Berichterstattung ausrichtet.

Eine Plattform, die zweihundert Seiten einmal pro Woche crawlen kann, ist ein anderes Produkt als eine, die hunderttausend Seiten bei jedem Deploy crawlen kann. Das Crawl-Häufigkeitsziel der kaufenden Partei sollte sich aus dem Deploy-Rhythmus ergeben. Eine Marketing-Website, die zweimal pro Woche aktualisiert wird, benötigt mindestens einen nächtlichen Crawl; eine Produktoberfläche, die kontinuierlich ausgeliefert wird, benötigt eine CI-Integration, die commit-weise läuft. Die Seitenvolumen-Obergrenze der Plattform, das Tiefenlimit des Crawls und das Limit für parallele Crawls entscheiden darüber, ob der Vertrag in Jahr drei noch trägt, wenn die Website gewachsen ist.

Der Posten, der den Preis still multipliziert. „PDF-Unterstützung“ kann drei verschiedene Dinge bedeuten. Es kann bedeuten, dass die Plattform PDF-Links erkennt und zählt, was keine Prüfung ist. Es kann bedeuten, dass die Plattform Text extrahiert und auf ein Inhaltsverzeichnis, eine Sprachdeklaration und grundlegendes Tagging prüft, was nur einen kleinen Bruchteil der PDF/UA-Fehler erkennt. Oder es kann bedeuten, dass die Plattform einen echten PDF/UA-Validator gegen den Dokumentenbaum ausführt, was eine verteidigungsfähige PDF-Compliance-Haltung tatsächlich erfordert. Nachfragen lohnt sich.

Die meisten modernen Produktoberflächen sind SPAs hinter einem Login. Ein Crawler, der keine JavaScript-Laufzeitumgebung betreiben und keine authentifizierte Sitzung aufrechterhalten kann, ist ein Crawler, der die Marketing-Broschüre scannt und nichts über die Anwendung berichtet. Die technische Frage lautet, ob die Plattform Headless Chromium mit Cookie-Injektion oder einem gespeicherten Sitzungstoken verwendet, wie sie SSO-Flows handhabt und ob sie einen mehrstufigen OAuth-Prozess abschließen kann. Die Beschaffungsfrage lautet, ob dieser Workflow selbst eingerichtet werden muss oder ob das Onboarding des Anbieters dies erledigt.

Native iOS- und Android-Apps fallen unter dieselben rechtlichen Regime wie das Web, und die meisten Monitoring-Plattformen decken sie nicht ab. Anbieter, die mobiles Scanning anbieten, berechnen es in der Regel separat und verwenden ein anderes Regelwerk gegen die plattformspezifischen Barrierefreiheits-APIs. Wenn native Apps ausgeliefert werden, wird eine Frage nach iOS UIAccessibility und Android AccessibilityNodeInfo die Auswahlliste schnell kürzen.

Scan-Output, der nicht im vorhandenen Workflow der Entwicklerin oder des Entwicklers landet, wird ignoriert. Das Mindest-Integrations-Set im Jahr 2026 umfasst Jira, GitHub oder GitLab, Slack und einen CI-Hook. Die besseren Plattformen liefern Linear, Azure DevOps, Microsoft Teams und eine Webhook-API. Die Integrationsfrage lautet nicht nur „Erstellt es ein Ticket“, sondern „Enthält das Ticket die Seiten-URL, den Verstoßcode, das WCAG-Kriterium, den vorgeschlagenen Fix und einen reproduzierbaren Selektor oder Screenshot?“

Das Kriterium, das die Plattform-Tier von der Scanner-mit-Dashboard-Tier trennt. Ein echter Handoff-Workflow ermöglicht es, einen Seitensatz auszuwählen, eine Überprüfung einzugrenzen, eine menschliche Auditorin oder einen menschlichen Auditor (intern oder vom Anbieter gestellt) einzuweisen, den Audit durch Review-Zustände zu verfolgen und die Befunde in dasselbe Dashboard zurückzubringen, zusammen mit den automatisierten Ergebnissen. Das Vorhandensein oder Fehlen dieses Workflows ist der beste Einzelprädiktor dafür, ob die Plattform eine verteidigungsfähige EAA- oder ADA-Compliance-Haltung unterstützen kann, weil die manuelle Schicht unter beiden Regime nicht optional ist.

EAA-Artikel 13 verlangt eine in maschinenlesbarer Form veröffentlichte Erklärung zur Barrierefreiheit. Die UK- und EU-Public-Sector-Vorschriften verlangen eine solche. Die DOJ-Title-II-Regel erwartet eine solche. Die Plattform sollte ein Erklärungsartefakt erzeugen — ein veröffentlichungsfähiges Dokument, nicht nur einen Dashboard-Screenshot —, das die Konformitätsstufe benennt, bekannte Probleme auflistet, den Audit datiert und sich aktualisiert, wenn sich die Monitoring-Daten ändern. Anbieter, die dies als erstklassiges Ergebnis behandeln, sparen der kaufenden Partei erheblich an Rechtsberatungszeit bei der Verlängerung.

Das Scan-Dashboard, das das Engineering-Team nutzt, ist nicht das Dashboard, das die CFO oder der Prüfungsausschuss sehen möchte. Die Plattform sollte beides liefern — eine Engineering-taugliche Triage-Ansicht mit Selektoren und Code-Ausschnitten sowie eine vorstandstaugliche Ansicht, die Problemanzahlen nach Schweregrad, Deploy-über-Deploy-Trend, Konformitätsprozentsatz nach Eigenschaft und voraussichtliche Abschlussdaten ausweist. Plattformen, die nur eine der beiden Ansichten liefern, werden mit einem separaten BI-Tool verbunden, was zusätzliche Kosten verursacht.

Das Preismodell selbst ist ein Signal. Pro-Domain-Preisgestaltung ist transparent hinsichtlich des Umfangs. Pro-Seite-Preisgestaltung skaliert mit dem Wachstum der kaufenden Partei und ist tendenziell teuer. Pro-Scan-Preisgestaltung belohnt effizientes Crawling. Pro-Nutzer-Preisgestaltung ist ein weicher Cap, der umgangen wird. Die Unterscheidung zwischen transparenter veröffentlichter Preisgestaltung und ausschließlich auf Anfrage verfügbarer Preisgestaltung ist eine Marktteilung: Die meisten Enterprise-Anbieter verstecken die Preisgestaltung hinter einem Angebot, während die Engineering-geführten Tools ein Tier veröffentlichen. Ein Anbieter, der beim Entdeckungsgespräch keinen Einstiegspreis nennt, signalisiert, dass der Vertrag größer sein wird, als die kaufende Partei erwartet.

Die sechs Plattformen unten decken die praktische Enterprise-Auswahlliste im Jahr 2026 ab. Die Fair-Comparison-Tabelle kommt zuerst, darunter folgt die anbieter-spezifische Darstellung.

Für Teams, deren Situation anders ist, lautet die faire Auswahlliste wie folgt. Ein reiner Engineering-Shop mit einer starken CI/CD-Kultur und einer Barrierefreiheits-Fachkraft, die im Developer-Toolchain lebt, wird besser von axe Monitor bedient, weil Deques Stärke die Engineering-Erfahrung und die Deploy-weise Regressionsansicht ist. Eine Marketing-geführte Organisation, bei der das Barrierefreiheits-Budget im Digital-Experience-Team neben SEO und Content-Qualität angesiedelt ist, wird besser von Siteimprove bedient, weil die Marketing-tauglichen Dashboards das Zentrum dieses Produkts sind und das modul-übergreifende Reporting wichtig ist. Ein Enterprise mit hohem US-Klagerisiko und einer Rechtsabteilung, die die rechtliche Absicherung in den Vordergrund stellen möchte, wird besser von Level Access bedient, weil die interne Audit-Praxis sowie die VPAT- und Sachverständigen-Infrastruktur am tiefsten am Markt sind.

Keine dieser Optionen ist eine schlechte Wahl für den jeweiligen Anwendungsfall. Die falsche Wahl ist die Plattform, die zur Situation einer anderen Organisation passt als der eigenen. Die Beschaffung sollte vor der Demo gegen die oben genannten Kriterien erfolgen, nicht danach.

Der wichtigste ehrliche Vorbehalt in jedem Monitoring-Gespräch. Automatisiertes Scanning erkennt unter großzügigen Annahmen etwa dreißig bis vierzig Prozent der WCAG-Probleme. Die verbleibenden sechzig bis siebzig Prozent erfordern menschliches Urteilsvermögen — und keine Menge zusätzlicher Regelentwicklung wird diese Lücke schließen, weil das, was Automatisierung übersieht, kategorisch nicht für statische Analyse geeignet ist.

Automatisierung kann nicht beurteilen, ob Alternativtext bedeutungsvoll ist — sie kann nur prüfen, ob Alternativtext vorhanden ist. Ein Foto einer Person, das mit „Bild“ beschriftet ist, besteht die automatisierte Prüfung und scheitert bei der Nutzerin oder dem Nutzer. Automatisierung kann eine Tastaturbarriere in einem benutzerdefinierten Widget nicht erkennen, es sei denn, die Barriere ist struktureller statt verhaltensbasierter Natur. Automatisierung kann die Fokusreihenfolge-Qualität nicht bewerten — sie kann fehlende Fokusindikatoren markieren, aber nicht erkennen, dass der Fokus auf der Seite unlogisch springt. Automatisierung kann die Screenreader-Lesbarkeit nicht gegen den realen assistiven Technologie-Stack testen — was NVDA, JAWS, VoiceOver und TalkBack bei einer bestimmten Komponente tatsächlich ansagen, kann nur ein Mensch überprüfen. Automatisierung kann nicht testen, ob eine dynamische Inhaltsaktualisierung einem Screenreader angekündigt wird; sie kann auf aria-live-Attribute prüfen, aber nicht, ob sie zum richtigen Zeitpunkt ausgelöst werden. Automatisierung kann keine Gebärdensprachinterpretation, kognitive Barrierefreiheits-Lesbarkeit, die Verständlichkeit von Fehlermeldungen, die Navigierbarkeit eines komplexen Formulars durch eine Switch-Control-Nutzerin oder einen Switch-Control-Nutzer oder den Farbkontrast von Text testen, der vor einem Videohintergrund dargestellt wird.

Das ist die Schicht, über die das Monitoring-Dashboard nichts aussagen kann. Eine Website kann einen grünen automatisierten Scan haben und von einer Screenreader-Nutzerin oder einem Screenreader-Nutzer von Anfang bis Ende unbrauchbar sein, und diese Versagenssituation ist so häufig, dass sie im Fachbereich eine eigene Kurzform hat: die Lücke zwischen Konformität und Barrierefreiheit. Plattformen, die dies anerkennen — und den manuellen Audit-Handoff in den Workflow einbauen — handeln im Interesse der kaufenden Partei. Plattformen, die automatisiertes Scanning als „Compliance“ ohne die Audit-Schicht verkaufen, verkaufen eine Haltung, die den Kontakt mit einer realen Nutzerin oder einem realen Nutzer assistiver Technologie nicht überstehen wird oder — zunehmend — den Kontakt mit einer Regulierungsbehörde, die das Seminar besucht hat.

Diese Liste ausdrucken. Zur Demo mitbringen. Den Folgeanruf erst terminieren, wenn jede Antwort schriftlich vorliegt.

Anbieter, die jede dieser Fragen klar und schriftlich beantworten, sind Anbieter, deren Vertrag unkompliziert ist. Anbieter, die bei den Fragen zurückrudern, signalisieren, dass die Beziehung mehr Klärungsbedarf beinhalten wird, als die kaufende Partei wünscht.

Nein. Monitoring ist die kontinuierliche, überwiegend automatisierte Schicht, die gegen eine Website oder App läuft und Regressionen meldet, sobald sie auftreten. Ein Audit ist eine zeitpunktbezogene manuelle Überprüfung durch eine Fachkraft, meist einschließlich Testerinnen und Testern mit Behinderungen, die Probleme erkennt, die Automatisierung nicht entdecken kann — Tastaturbarrieren, Fokusreihenfolge-Qualität, Screenreader-Lesbarkeit, bedeutungsvoller Alternativtext, dynamische Inhaltsaktualisierungen. Eine verteidigungsfähige Compliance-Haltung benötigt beides. Die beiden Schichten beantworten unterschiedliche Fragen, und keine ersetzt die andere.

Nein, und jeder Anbieter, der das Gegenteil behauptet, verkauft automatisiertes Scanning als Compliance, was es nicht ist. Automatisierte Scanner erkennen unter großzügigen Annahmen etwa 30 bis 40 Prozent der WCAG-Probleme — Farbkontrast, fehlender Alternativtext, fehlende Labels, Dokumentstruktur. Die verbleibenden 60 bis 70 Prozent erfordern menschliches Urteilsvermögen. Die besten Monitoring-Plattformen erkennen dies an und stellen einen Workflow bereit, um Scan-Ergebnisse an manuelle Auditorinnen und Auditoren weiterzuleiten; die schlechtesten tun so, als sei das kein Problem.

Für eine sich schnell verändernde Produktoberfläche bei jedem Deploy über CI, mit einem vollständigen Crawl mindestens wöchentlich. Für eine Marketing-Website, die zweimal pro Woche aktualisiert wird, ist ein nächtlicher oder commit-weiser Crawl der übliche Rhythmus. Für ein stabiles Public-Sector-Portal ist ein wöchentlicher Crawl plus ein Deploy-weiser Regressions-Scan in der Regel verteidigungsfähig. Die Falle liegt darin, Compliance als vierteljährlichen Schnappschuss zu behandeln — jeder Push ist eine Gelegenheit, ein Label zu beschädigen, einen Fokusring zu verlieren oder eine Komponente auszuliefern, die sich selbst als Div ankündigt.

Nein. Weder die US-Justizministeriums-Regel von 2024 zu Title II noch der European Accessibility Act behandelt einen automatisierten Scan-Bericht allein als Konformitätsnachweis. Die DOJ-Regel benennt WCAG 2.1 Level AA als inhaltlichen Standard; der EAA verweist auf den harmonisierten EN 301 549, der seinerseits auf WCAG 2.1 AA verweist. Beide Regime sehen ein Programm vor, das automatisiertes Monitoring, manuelles Audit und eine veröffentlichte Erklärung zur Barrierefreiheit kombiniert. Ein grünes Scanner-Dashboard ist notwendig, aber nicht hinreichend.

Enterprise-Listenpreise im Jahr 2026 liegen typischerweise zwischen ungefähr 15.000 und 120.000 US-Dollar pro Jahr, wobei die Spanne durch Domain-Anzahl, Crawl-Häufigkeit, Seitenvolumen und die Frage bestimmt wird, ob manuelle Audit-Stunden im Paket enthalten sind. Mid-Market-Pläne bei ungefähr 6.000 bis 18.000 Dollar pro Jahr sind für dieselben Plattformen mit kleineren Crawl-Caps üblich. PDF-Barrierefreiheit, Mobile-Native-Scanning und gebündelte manuelle Audits sind die drei Posten, die den Preis am stärksten verschieben. Fast jede Enterprise-Plattform erfordert ein Verkaufsgespräch für ein reales Angebot.

Möglicherweise nicht, wenn der Umfang eine einzelne Web-Präsenz ist, die Engineering-Organisation die Disziplin hat, Builds bei axe-Regressionen fehlschlagen zu lassen, und eine separate manuelle Audit-Beziehung für die 60 bis 70 Prozent Automatisierungs-Lücken besteht. Die meisten Organisationen entwachsen diesem Muster. Eine Monitoring-Plattform fügt den Crawl über Seiten hinzu, die kein CI-Lauf erfasst, das für die Führungsebene lesbare Dashboard, die Regressionsansicht über Deploys hinweg, die PDF-Abdeckung, den Workflow zur Erstellung der Barrierefreiheitserklärung und — bei den besseren Plattformen — den manuellen Audit-Handoff. Die Frage ist der Workflow, nicht die Scanner-Genauigkeit.

Mindestens: WCAG-Versionsunterstützung, Crawl-Häufigkeit und Seitenvolumen-Caps, Single-Page-App- und Authentifizierungs-Handling, PDF-Barrierefreiheit (eine echte Prüfung, keine Dateitypenerkennung), Mobile-Native-iOS- und Android-Abdeckung, Integration mit dem Issue-Tracker und CI der kaufenden Partei, der Workflow für den manuellen Audit-Handoff, ein Muster-Barrierefreiheitserklärung, Executive- und Engineering-Dashboards sowie das Preismodell explizit benannt — pro Domain, pro Seite, pro Scan, pro Nutzer. Ein Anbieter, der sich gegen transparente Preisgestaltung sperrt, ist ein Warnsignal bei der Beschaffung.

Drei konkrete nächste Schritte. Erstens: den kostenlosen Disability-World-Scanner gegen die am stärksten frequentierte Seite und die geschäftskritischste authentifizierungsgeschützte Seite ausführen, um eine Basiskenngröße zu erhalten — das ist die Zahl, nach der jeder Anbieter beim Entdeckungsgespräch fragen wird, und es ist nützlicher, sie vor dem Gespräch zu haben als während. Zweitens, falls noch nicht geschehen: die Primer zu European Accessibility Act, ADA Title III und WCAG 2.2 Erfolgskriterien lesen, damit das Beschaffungsgespräch auf den tatsächlichen Standards basiert und nicht auf den Marketing-Zusammenfassungen der Anbieter. Drittens: zwei oder drei Plattformen aus der obigen Tabelle anhand des Empfehlungsrahmens in die engere Auswahl nehmen und Demos anfragen — aber die Beschaffungs-Checkliste als Agenda für die Demo verwenden, nicht die Folien des Anbieters. Die gekaufte Plattform ist die Plattform, mit der mindestens drei Jahre gelebt wird; die Stunde, die vorab für die Kriterien aufgewendet wird, ist die günstigste Stunde des gesamten Projekts.