Pa11y

Kurzfazit

Pa11y ist ein Weg, Barrierefreiheit automatisch und kostenlos in die Entwicklungs-Pipeline einzubauen. Wo kommerzielle Tools wie Siteimprove oder axe DevTools Pro mit Abogebühren kommen, ist Pa11y vollständig Open Source und läuft auf deiner eigenen Infrastruktur; einen gehosteten Dienst oder Telemetrie nennt das Projekt nicht. Die drei Bausteine, die CLI für Einzelprüfungen, Pa11y CI für jeden Pull Request und das Dashboard für den Langzeit-Trend, decken den kompletten Entwickler-Workflow ab. Der Preis dafür: Pa11y ist ein Werkzeug für Entwickler, kein Klick-Tool für Marketing-Teams, und wie jeder automatische Scanner erwischt es nur einen Teil aller WCAG-Verstöße. Wer das versteht und Entwicklerkapazität hat, bekommt eine kostenlose Barrierefreiheits-Lösung für die Pipeline. Eines vorweg: Pa11y ist kein KI-Tool. Die Prüf-Engines axe-core und HTML_CodeSniffer arbeiten mit festen, regelbasierten Algorithmen, nicht mit maschinellem Lernen. Wir führen Pa11y trotzdem, weil es in vielen Tech-Stacks und Qualitäts-Workflows der richtige Griff ist, gerade dort, wo KI-gestützte Produkte ohnehin auf Barrierefreiheit geprüft werden müssen.

Für wen ist Pa11y?

Entwicklerteams mit CI/CD-Pipeline: Die Paradedisziplin. Pa11y CI ist für Continuous-Integration-Umgebungen gebaut (die Tutorial-Liste des Projekts nennt GitHub Actions, Travis und Drone) und prüft in der Pipeline eine definierte Liste von URLs oder eine komplette Sitemap. Mit dem Standard-Schwellenwert 0 scheitert der Lauf bei jedem gemeldeten Fehler mit Exit-Code 2, Barrierefreiheit wird damit zur Qualitätsanforderung wie Linting oder Unit-Tests.

Behörden und öffentliche Stellen: Wer unter die BITV 2.0 fällt und gesetzlich zur Barrierefreiheit verpflichtet ist, bekommt mit Pa11y ein kostenloses, self-hostbares Werkzeug, für das das Projekt keinen gehosteten Dienst nennt. Gerade für Verwaltungen mit strengen IT-Sicherheitsvorgaben ist der lokale Betrieb ein echtes Argument.

DSGVO-sensible Unternehmen: Banken, Versicherer, Gesundheitsdienstleister, überall dort, wo selbst Test-URLs und Crawl-Daten das Haus nicht verlassen dürfen, spielt Pa11y seine Stärke aus. Das Projekt nennt keinen Anbieter-Dienst, der Daten verarbeitet; du betreibst alles selbst, auf eigenen CI-Runnern statt bei einem gehosteten CI-Dienst.

Open-Source-erste Tech-Stacks: Teams, die ohnehin auf freie Software setzen und kein Budget für Enterprise-Lizenzen haben, finden in Pa11y eine Lösung, deren Copyright-Zeile 2013 bis 2026 nennt, mit 4,6k Sternen auf GitHub.

Agenturen mit vielen Kundenprojekten: Wer Dutzende Websites betreut, kann Pa11y CI als standardisierten Qualitäts-Check über alle Projekte ausrollen, ohne pro Kunde eine Lizenz zu bezahlen.

Weniger geeignet für: Marketing- und Redaktions-Teams ohne Technik-Hintergrund (für die ist WAVE oder axe DevTools als Browser-Erweiterung besser geeignet), Organisationen, die geführte manuelle Audits und zertifizierte Reports aus einer Hand erwarten, und alle, die ein fertiges Cloud-Dashboard ohne eigenen Server-Betrieb wollen.

Preise im Detail

Komponente	Preis	Was du bekommst
Pa11y (CLI)	0 €	Einzelseiten-Prüfung per Kommandozeile, JSON/CSV/HTML-Reporter, Actions (Klicks, Warten, Screenshots), Wahl der Engine
Pa11y CI	0 €	Batch-Prüfung von URL-Listen und Sitemaps, Schwellenwerte, Ignore-Regeln, parallele Tests
Pa11y Dashboard	0 €	Selbst gehostete Web-Oberfläche, tägliche automatische Tests, Trend-Grafiken über Zeit
Pa11y Webservice	0 €	JSON-API als Backend für das Dashboard oder eigene Oberflächen

Einordnung: Pa11y kostet keinen Cent an Lizenzgebühren, alle vier Komponenten sind frei verfügbar. CLI und Pa11y CI stehen unter LGPL-3.0, Dashboard und Webservice unter GPL-3.0, in der Praxis beim reinen Einsatz kein Unterschied. Die einzigen realen Kosten sind Setup und Pflege: Ein Entwickler braucht für die CLI-Einrichtung und eine erste CI-Integration nach unserer Schätzung (keine Projektangabe) einen halben bis ganzen Arbeitstag. Wer das Dashboard betreiben will, muss zusätzlich einen Server samt MongoDB bereitstellen und warten, das ist der einzige Posten, der echten laufenden Aufwand bedeutet. Im Vergleich zu kostenpflichtigen Plattformen wie Siteimprove oder axe DevTools Pro entfallen die Lizenzkosten, sofern die Entwicklerzeit ohnehin vorhanden ist. Für KMU ohne eigenes Dev-Team kann sich diese Rechnung allerdings umkehren: Dann ist ein bezahltes Klick-Tool günstiger als die internen Stunden für Betrieb und Pflege.

Stärken im Detail

Kostenlos und ohne Vendor-Lock-in. Pa11y steht komplett unter freien Lizenzen (CLI und CI unter LGPL-3.0, Dashboard und Webservice unter GPL-3.0). Es gibt keine Nutzergebühren, keine Volumenlimits, keinen Anbieter, der morgen die Preise erhöht oder das Produkt einstellt. Du kannst den Code forken, anpassen und auf beliebig vielen Projekten einsetzen. Für Agenturen und große Organisationen skaliert das ohne Zusatzkosten.

Echtes Self-Hosting. Anders als bei Cloud-basierten Scannern laufen die Werkzeuge dort, wo du sie installierst: Betreibst du sie auf eigener Infrastruktur, liegen URLs, Crawl-Daten und Prüfergebnisse dort, und das Projekt nennt keinen gehosteten Dienst, der sie erhält. Auf einem gehosteten CI-Runner wie GitHub Actions liegen sie dagegen auch bei dessen Betreiber.

CI/CD-Integration als Kerngedanke. Pa11y CI ist von Grund auf für Build-Pipelines gebaut. Du definierst in einer Konfigurationsdatei, welche Seiten geprüft werden, setzt einen Schwellenwert für tolerierte Probleme und bindest den Aufruf in deine CI-Pipeline ein (die Tutorial-Liste des Projekts nennt GitHub Actions, Travis und Drone). Ab da prüft jeder Pull Request automatisch, Barrierefreiheit wird zur harten Qualitätsanforderung statt einer einmaligen Aktion vor Launch. Sitemaps werden direkt unterstützt: --sitemap zieht alle URLs automatisch.

Zwei bewährte Prüf-Engines zur Wahl. Pa11y nutzt im Hintergrund entweder HTML_CodeSniffer (Default) oder axe-core von Deque, dieselbe Engine, die laut Deque die Axe Platform, Google Lighthouse und Tausende Testprogramme antreibt. Du kannst pro Test entscheiden, welche Engine läuft, oder beide kombinieren, um ein breiteres Spektrum an Regeln abzudecken. Als Standard wählst du WCAG2A, WCAG2AA (Default) oder WCAG2AAA; WCAG2AAA nutzt nur der HTML_CodeSniffer-Runner.

Flexible Actions für komplexe Strecken. Pa11y kann vor dem Test Aktionen ausführen: Login-Formulare ausfüllen, Buttons klicken, auf Elemente warten, Screenshots aufnehmen. So lassen sich auch geschützte Bereiche und mehrstufige Workflows prüfen, nicht nur öffentliche Landingpages.

Dashboard für den Langzeit-Blick. Das Pa11y Dashboard testet hinterlegte Seiten täglich automatisch und zeigt in Grafiken, wie sich die Anzahl der Probleme über Wochen und Monate entwickelt. Das macht Fortschritt sichtbar, und Rückschritte ebenfalls. Anders als die reine CLI ist das Dashboard auch für nicht-technische Stakeholder lesbar.

Aktiv gepflegt. Pa11y ist kein verwaistes Projekt: Aktuell sind die CLI in Version 10 (Node.js ab 22.13.0), Pa11y CI in Version 5 und das Dashboard in Version 5.2.1. Eine Support-Policy regelt, wie lange alte Major-Versionen Fixes bekommen: Die Vorversion wird nach einem neuen Major noch 6 Monate mit Fixes für kritische Bugs und Sicherheitslücken unterstützt.

Schwächen ehrlich betrachtet

Automatische Scans erwischen nur einen Teil. Das ist keine Pa11y-spezifische Schwäche, sondern gilt für jedes automatisierte Barrierefreiheits-Tool: Automatische Prüfungen erkennen nur einen Teil aller WCAG-Verstöße. Sinnvolle Alt-Texte, logische Lesereihenfolge, verständliche Sprache, Tastatur-Bedienbarkeit komplexer Widgets, vieles davon braucht weiterhin manuelle Prüfung durch Menschen. Wer glaubt, ein grüner Pa11y-Lauf bedeute volle Konformität, irrt gefährlich. Workaround: Pa11y als erste automatische Stufe nutzen, ergänzt durch manuelle Audits und Tests mit echten Screenreadern.

Reines Entwicklerwerkzeug. Es gibt keine schöne, geführte Oberfläche für Content-Teams. Die CLI gibt JSON oder Klartext aus, die Konfiguration läuft über Dateien, das Dashboard muss selbst aufgesetzt werden. Wer kein Dev-Team hat, kommt mit Pa11y nicht weit. Workaround: Für nicht-technische Kolleginnen ein Browser-Tool wie WAVE bereitstellen und Pa11y nur in der Pipeline laufen lassen.

Englische Projektseite und Dokumentation. Eine deutschsprachige Oberfläche nennt das Projekt nicht. Für eingespielte Entwickler kein Problem, für gemischte Teams oder Behörden mit Sprachanforderungen ein Reibungspunkt. Einen kommerziellen Support-Vertrag nennt das Projekt ebenfalls nicht; für Support verweist die Kontaktseite auf GitHub Issues und Slack.

Dashboard-Betrieb ist Zusatzaufwand. Das Dashboard und der Webservice brauchen einen eigenen Server inklusive MongoDB. Das einzurichten, abzusichern und aktuell zu halten ist nicht trivial und bindet laufend Betriebsressourcen.

Keine geführten Audits oder Reports aus einer Hand. Pa11y findet technische Verstöße, aber es führt dich nicht durch einen strukturierten Audit-Prozess, bietet keine Schulungen und liefert keine zertifizierten Konformitäts-Reports, die du einer Aufsichtsbehörde vorlegen könntest. Für strukturierte Audits und Reporting kommen kommerzielle Plattformen wie Siteimprove oder Audit-Dienstleister infrage.

Alternativen im Vergleich

Wenn du…	…nimm stattdessen
Ein Klick-Werkzeug für die Browser-Erweiterung willst	axe DevTools
Eine visuelle In-Browser-Prüfung für Nicht-Entwickler brauchst	WAVE
Eine Enterprise-Plattform mit Monitoring und Governance willst	Siteimprove
Laufendes Monitoring vieler Seiten mit Reports brauchst	Silktide

Erwähnenswert ohne aktive Empfehlung: Google Lighthouse nutzt im Hintergrund dieselbe axe-core-Engine und ist als schneller Smoke-Test in Chrome eingebaut, deckt aber Barrierefreiheit nur als Teilbereich ab. Pa11y ist kein Komplettpaket, es ist eine freie Engine-Integration für die Pipeline. Für manuelle Audits, Schulungen und nicht-technische Teams kombinierst du es mit den oben genannten Werkzeugen, statt es als alleinige Lösung zu betrachten.

So steigst du ein

Schritt 1: CLI lokal testen. Installiere Pa11y global mit npm install -g pa11y (Voraussetzung für Pa11y 10: eine stabile, gerade Node.js-Version ab 22.13.0; ältere Node-Versionen laufen mit Pa11y 9 oder früher). Dann pa11y https://deine-domain.de ausführen, Pa11y startet einen Headless-Chromium, prüft die Seite gegen WCAG 2 AA und listet die gefundenen Probleme als Klartext oder JSON. Spiele mit --runner axe und --runner htmlcs, um beide Engines zu vergleichen.

Schritt 2: In die Pipeline einbauen. Installiere pa11y-ci, lege eine .pa11yci-Konfigurationsdatei mit deinen wichtigsten URLs an (oder verweise per --sitemap auf deine Sitemap) und setze einen Schwellenwert (threshold) für tolerierte Probleme. Binde den Aufruf in deine CI-Pipeline ein. Ab jetzt scheitert der Lauf mit Exit-Code 2, sobald die gemeldeten Probleme den Schwellenwert erreichen; Seiten außerhalb deiner URL-Liste oder Sitemap bleiben ungeprüft.

Schritt 3: Ignore-Regeln und Actions pflegen. Markiere bekannte False Positives über die ignore-Liste, damit das Team nicht durch Rauschen abgestumpft wird. Für geschützte Bereiche definierst du Actions (Login ausfüllen, Button klicken, warten), damit auch Seiten hinter der Anmeldung geprüft werden.

Schritt 4 (optional): Dashboard aufsetzen. Wer Fortschritt über Zeit sichtbar machen will, installiert Pa11y Dashboard und Webservice auf einem eigenen Server mit MongoDB. Das Dashboard prüft hinterlegte Seiten täglich automatisch und liefert Trend-Grafiken, sinnvoll, um Stakeholdern den Verlauf zu zeigen, aber nur, wenn die Betriebsressourcen vorhanden sind.

Ein konkretes Beispiel

Ein Berliner SaaS-Anbieter mit 14 Entwicklern baut Pa11y CI in seine GitLab-Pipeline ein. In der .pa11yci-Datei sind 12 Hauptseiten und 3 mehrstufige Workflow-Strecken (inklusive Login per Actions) hinterlegt, geprüft wird gegen WCAG 2.1 AA mit der axe-core-Engine. Bei jedem Merge Request läuft der Scan automatisch; ein Schwellenwert knapp über den bekannten Altlasten verhindert, dass diese den Build sofort rot färben; kommen neue Probleme dazu, blockiert der Lauf den Merge. In den ersten zwei Wochen identifiziert das System 47 Verstöße, fehlende Formular-Labels, zu schwache Farbkontraste, Buttons ohne zugänglichen Namen. Das Team behebt 41 davon innerhalb eines Sprints, die restlichen sechs landen als Tickets im Backlog. Parallel prüft eine UX-Designerin die kritischen Strecken manuell mit einem Screenreader, weil der automatische Scan die Tastatur-Bedienbarkeit der Drag-and-Drop-Komponente nicht abdeckt. Laufende Lizenzkosten: 0 Euro. Setup-Aufwand: ein halber Entwickler-Tag.

Das Beispiel ist ein Szenario zur Veranschaulichung, keine Kundenangabe von Pa11y.

DSGVO & Datenschutz

• Datenhosting: Vollständig self-hosted. Pa11y läuft auf deiner eigenen Infrastruktur (Entwicklungsrechner, CI-Runner, eigener Server). Das Projekt nennt keinen externen Dienst, der Daten verarbeitet, du bestimmst, wo alles läuft (z. B. deutsche Rechenzentren). Wir führen das Datenhosting-Kennzeichen bewusst als „global” und nicht als „de”: Pa11y ist ein lokal laufendes Open-Source-Werkzeug ohne Anbieter-Cloud, es gibt also keine feste, vom Hersteller garantierte deutsche Hosting-Region. Der Datenschutz-Vorteil entsteht nicht durch ein deutsches Rechenzentrum des Anbieters, sondern dadurch, dass du den Betriebsort selbst kontrollierst und Daten das Haus gar nicht erst verlassen müssen.
• Datennutzung: Die README beschreibt Pa11y als Werkzeug für die Kommandozeile oder Node.js; Projektseite und README nennen weder einen gehosteten Dienst noch Telemetrie. Die geprüften URLs, Crawl-Daten und Reports liegen dort, wo du Pa11y betreibst. Der Quellcode ist offen, du kannst das selbst nachprüfen.
• Auftragsverarbeitung (AVV): Das Projekt nennt keinen Dienst, für den du einen AVV bräuchtest. Läuft Pa11y auf einem gehosteten CI-Dienst, betrifft der AVV dessen Betreiber.
• Empfehlung für Unternehmen: Für DSGVO-sensible Branchen (Gesundheit, Finanzen, Behörden) spricht der Selbstbetrieb für Pa11y. Wer das Dashboard betreibt, sollte den Server nach internen Sicherheitsvorgaben absichern (Zugriffsschutz, MongoDB-Härtung), der Datenschutz-Vorteil verlagert sich damit auf die eigene IT-Sicherheit.

Gut kombiniert mit

• axe DevTools, die Browser-Erweiterung für Entwickler und Designer, um einzelne Probleme während der Entwicklung interaktiv zu inspizieren. Pa11y prüft automatisch in der Pipeline, axe DevTools hilft beim gezielten Debugging einer konkreten Seite.
• WAVE, als visuelles Werkzeug für nicht-technische Kolleginnen aus Redaktion und Marketing. WAVE markiert Probleme direkt im gerenderten Layout; Pa11y bleibt die unsichtbare Wächter-Instanz in der Build-Pipeline.
• Siteimprove, wenn zusätzlich Governance, Monitoring und Reports für das Management gebraucht werden. Pa11y deckt die technische CI-Ebene kostenlos ab, Siteimprove die organisatorische und berichtspflichtige Ebene.

Unser Fazit

Pa11y verdient 4 von 5 Sternen. Für seinen Kernzweck, automatisierte WCAG-Tests fest in die Entwicklungs-Pipeline einbauen, kostenlos und im Selbstbetrieb, ist es eine überzeugende Lösung. Freie Lizenz, echtes Self-Hosting, CI-Integration und die Wahl zwischen zwei Engines sprechen für das Projekt, und es wird nachweislich aktiv gepflegt. Den fünften Stern verliert Pa11y nicht wegen Qualitätsmängeln, sondern wegen seiner bewussten Verengung: Es ist ein Entwicklerwerkzeug ohne Komfort für nicht-technische Teams, mit englischer Dokumentation und ohne geführte manuelle Audits. Und wie jeder automatische Scanner deckt es nur einen Teil der WCAG-Anforderungen ab, wer das nicht versteht, wiegt sich in falscher Sicherheit. Für Teams mit Entwicklerkapazität und ehrlichem Verständnis dieser Grenzen ist Pa11y die klare Empfehlung.

Was wir bemerkt haben

• November 2026, CLI, CI und Dashboard haben neue Versionen: Pa11y 10.0.0 (Node.js ab 22.13.0, Puppeteer 25, axe-core 4.13), Pa11y CI 5.0.0 (baut auf Pa11y 10) und Dashboard 5.2.1. Die Vorgängerversionen, die diese Seite zuvor nannte (CLI 9.1.1, CI 4.1.1, Dashboard 5.2.0), sind damit überholt. Die Support-Tabelle der README nennt für Pa11y 9 das Enddatum 2026-02-27. Zugleich sagt die README 6 Monate Unterstützung nach einem neuen Major zu, und die Release-Seite zeigt Pa11y 9.1.1 mit „26 Feb“ und Pa11y 10.0.0 mit „28 Aug“, beides ohne Jahr. Ob das Datum in der Tabelle stimmt, klärt das nicht. Pa11y CI 4 wird laut Tabelle noch bis 2027-04-05 unterstützt.
• Korrektur (Mai 2026), Eine verbreitete Annahme, das Pa11y Dashboard sei vom Hauptteam ausgemustert und nur noch lose von der Community gepflegt, trifft nach unserer Recherche nicht mehr zu: Das Dashboard 5 ist die aktuell offiziell unterstützte Major-Version und steht in der Support-Matrix als „current”. Wir hatten das in einer früheren Version dieser Seite falsch dargestellt.
• November 2026, Pa11y 10 verlangt eine stabile (gerade) Node.js-Version ab 22.13.0 (Pa11y CI 5: 22.13+, 24, 26). Node.js 20 geht nur noch mit Pa11y 9 oder früher, ein Stolperstein in CI-Pipelines mit eingefrorenen Node-Versionen.
• Juni 2026, Bei der Quellenprüfung haben wir eine Lizenz-Ungenauigkeit korrigiert: Frühere Versionen dieser Seite gaben für das gesamte Projekt LGPL-3.0 an. Tatsächlich stehen CLI und Pa11y CI unter LGPL-3.0-only, das Pa11y Dashboard aber unter der strengeren GPL-3.0. Für den reinen Einsatz macht das keinen Unterschied, für Weiterverteilung von Code-Anpassungen am Dashboard schon.
• Dauerhaft relevant, axe-core und HTML_CodeSniffer als Engines bedeuten: Pa11y übernimmt die Regel-Updates dieser etablierten Bibliotheken über eigene Releases (Pa11y 10 etwa axe 4.13), ist aber auch an deren Grenzen gebunden. Wichtig zu wissen: Beide Engines arbeiten regelbasiert, nicht mit KI. Automatische Prüfungen erkennen weiter nur einen Teil der WCAG-Verstöße, daran ändert auch ein gepflegtes Pa11y nichts.
• Juli 2026, Datenhosting-Kennzeichen von „de” auf „global” korrigiert. Frühere Versionen dieser Seite suggerierten mit dem „de”-Badge eine deutsche Anbieter-Cloud, die es bei Pa11y gar nicht gibt: Das Werkzeug läuft dort, wo du es installierst (Rechner, CI-Runner, eigener Server), eine Hersteller-Cloud nennt die Projektseite nicht. „global” ist hier ehrlicher und meint „keine feste Anbieter-Region”. Der DSGVO-Vorteil bleibt bestehen, er entsteht durch den selbst kontrollierten Betriebsort, nicht durch ein garantiertes deutsches Rechenzentrum.