Pa11y

Kurzfazit

Pa11y ist der beste Weg, Barrierefreiheit automatisch und kostenlos in die Entwicklungs-Pipeline einzubauen. Wo kommerzielle Tools wie Siteimprove oder axe DevTools Pro mit Abogebühren und Cloud-Anbindung kommen, ist Pa11y vollständig Open Source, läuft auf deiner eigenen Infrastruktur und schickt keine Daten an Dritte. 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 der zuverlässigsten kostenlosen Barrierefreiheits-Lösungen am Markt. 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 lässt sich in GitHub Actions, GitLab CI oder Jenkins einbinden und prüft bei jedem Pull Request eine definierte Liste von URLs oder eine komplette Sitemap. Führt ein Commit ein neues Barrierefreiheits-Problem ein, scheitert der Build automatisch, 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, das keine Daten an US-Anbieter sendet. 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. Es gibt keinen Anbieter, der Daten verarbeitet; du betreibst alles selbst.

Open-Source-erste Tech-Stacks: Teams, die ohnehin auf freie Software setzen und kein Budget für Enterprise-Lizenzen haben, finden in Pa11y eine ausgereifte, seit 2013 gepflegte Lösung mit aktiver Community (rund 4.500 Sterne 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 (Siteimprove deckt das ab), 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, Docker, 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, das Dashboard unter der etwas strengeren 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 typischerweise 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 Siteimprove (vierstellige Jahresgebühren) oder axe DevTools Pro (Abo pro Nutzer) ist die Ersparnis erheblich, 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 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 ohne Datenabfluss. Anders als bei Cloud-basierten Scannern verlassen deine URLs, Crawl-Daten und Test-Ergebnisse niemals deine Infrastruktur. Es gibt keinen Auftragsverarbeiter, keine US-Server, keine Datenschutz-Folgenabschätzung für einen externen Dienstleister. Für Behörden und regulierte Branchen ist das oft der entscheidende Grund, überhaupt zu Pa11y zu greifen.

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 GitHub Actions, GitLab CI oder Jenkins ein. 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 auch axe DevTools, Lighthouse und viele andere Tools antreibt. Du kannst pro Test entscheiden, welche Engine läuft, oder beide kombinieren, um ein breiteres Spektrum an Regeln abzudecken. Geprüft wird gegen die üblichen Standards (WCAG 2.x Level A, AA, AAA).

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: Die CLI erschien zuletzt als v9.1.1 (Februar 2026, Node 20/22/24), Pa11y CI als v4.1.1 (Mai 2026), das Dashboard als v5.2.0 (März 2026). Eine klare Support-Policy regelt, wie lange alte Major-Versionen Sicherheits-Fixes bekommen.

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: Branchenübliche Schätzungen gehen davon aus, dass automatische Prüfungen nur etwa 30 bis 40 Prozent aller WCAG-Verstöße erkennen. 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.

Keine deutschsprachige Oberfläche oder Support. Dokumentation, Fehlermeldungen und Community sind englisch. Für eingespielte Entwickler kein Problem, für gemischte Teams oder Behörden mit Sprachanforderungen ein Reibungspunkt. Einen kommerziellen Support-Vertrag gibt es nicht, du bist auf GitHub-Issues und Community angewiesen.

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. Viele Teams nutzen deshalb nur CLI und CI und verzichten auf das Dashboard.

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 solche Anforderungen sind kommerzielle Plattformen wie Siteimprove oder Dienstleister-Audits die passendere Wahl.

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 die beste 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: Node.js 20, 22 oder 24). 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 GitHub-Actions- oder GitLab-CI-Pipeline ein. Ab jetzt scheitert jeder Pull Request, der neue Barrierefreiheits-Probleme einführt.

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 verhindert, dass bestehende Altlasten den Build sofort rot färben, während neue Probleme den Merge blockieren. 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. Seitdem führt kein neuer Release mehr versehentlich Barrierefreiheits-Regressionen ein.

DSGVO & Datenschutz

• Datenhosting: Vollständig self-hosted. Pa11y läuft auf deiner eigenen Infrastruktur (Entwicklungsrechner, CI-Runner, eigener Server). Es gibt keinen externen Anbieter, der Daten verarbeitet, du bestimmst, wo alles läuft (z. B. deutsche Rechenzentren).
• Datennutzung: Keine. Pa11y sendet keine Telemetrie und keine Test-Ergebnisse an Dritte. Die geprüften URLs, Crawl-Daten und Reports bleiben vollständig in deiner Hand.
• Auftragsverarbeitung (AVV): Nicht erforderlich und nicht vorgesehen, da kein Auftragsverarbeiter existiert. Das vereinfacht die Compliance gegenüber Cloud-Scannern erheblich.
• Engines: Sowohl axe-core (Deque) als auch HTML_CodeSniffer laufen lokal als Bibliotheken, auch hier kein Datenabfluss.
• Empfehlung für Unternehmen: Für DSGVO-sensible Branchen (Gesundheit, Finanzen, Behörden) ist Pa11y gerade wegen des fehlenden Datenabflusses eine der unkompliziertesten Optionen. 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 zertifizierte Reports für das Management gebraucht werden. Pa11y deckt die technische CI-Ebene kostenlos ab, Siteimprove die organisatorische und berichtspflichtige Ebene.

Unser Testurteil

Pa11y verdient 4 von 5 Sternen. Für seinen Kernzweck, automatisierte WCAG-Tests fest in die Entwicklungs-Pipeline einbauen, kostenlos und ohne Datenabfluss, ist es eine der besten verfügbaren Lösungen überhaupt. Die Kombination aus freier Lizenz, echtem Self-Hosting, sauberer CI-Integration und Wahl zwischen zwei bewährten Engines ist im Open-Source-Bereich kaum zu schlagen, und das Projekt 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, ohne deutschsprachigen Support 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

• Mai 2026, Pa11y CI ist in Version 4.1.1 erschienen, das Dashboard kurz zuvor in v5.2.0 (März 2026) und die CLI in v9.1.1 (Februar 2026). Alle drei Hauptkomponenten werden also weiterhin aktiv weiterentwickelt, bei einem seit 2013 laufenden Open-Source-Projekt keine Selbstverständlichkeit.
• 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 ist mit v5.2.0 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.
• 2026, Pa11y 9 setzt mindestens Node.js 20 voraus (unterstützt 20, 22, 24). Wer noch auf älteren Node-Versionen unterwegs ist, muss vor dem Upgrade die Laufzeitumgebung aktualisieren, ein typischer 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 profitiert automatisch von den Regel-Updates dieser etablierten Bibliotheken, ist aber auch an deren Grenzen gebunden. Wichtig zu wissen: Beide Engines arbeiten regelbasiert, nicht mit KI. Der Anteil automatisch erkennbarer WCAG-Verstöße liegt branchenweit weiter bei rund einem Drittel, daran ändert auch ein gepflegtes Pa11y nichts.