Tools

Pa11y

Ein quelloffener Barrierefreiheits-Tester für die Kommandozeile. Der CI-freundliche Begleiter zur axe-core CLI; pa11y-ci treibt die nächtlichen Site-weiten Regressionstests in den meisten großen Barrierefreiheitsprogrammen an.

Pa11y ist ein quelloffenes automatisiertes Barrierefreiheits-Testwerkzeug. Ursprünglich bei Nature Publishing Group entwickelt und heute von einer unabhängigen Community gepflegt, ist Pa11y seit einem Jahrzehnt das bevorzugte Werkzeug für „Barrierefreiheitstests in der CI“.

Was Pa11y leistet

Pa11y nimmt an der Kommandozeile eine URL entgegen, führt Barrierefreiheitsprüfungen auf der gerenderten Seite durch und gibt eine Liste der Verstöße aus:

$ pa11y https://example.com
Welcome to Pa11y

> Running Pa11y on 1 URLs:
...

Error: This element does not have an attribute "alt".
   • Element: <img src="..." />
   • Code: HTML_CS.Principle1.Guideline1_1.1_1_1.H37
   • Selector: body > section:nth-child(2) > img

Pa11y läuft in einem Headless-Browser (intern Puppeteer oder Playwright), sodass es den gerenderten DOM analysiert — nicht nur das HTML-Quellcode. Dadurch können JavaScript-gerenderte Inhalte genauso geprüft werden, wie sie Nutzenden begegnen würden.

Unterstützte Regel-Engines

Pa11y hat historisch zwei Regel-Engines unterstützt:

  • HTML_CodeSniffer (der Standard; das ursprüngliche Rückgrat von Pa11y).
  • axe-core (über pa11y --runner axe).

Beide können gleichzeitig ausgeführt und die Ergebnisse zusammengeführt werden — ein Modus nach dem Motto „alles, was ich automatisch erkennen kann“. Die meisten modernen Pa11y-Deployments verwenden ausschließlich die axe-core-Engine, da axe-core die aktivste Regelentwicklung aufweist.

pa11y-ci — der Multi-URL-Workflow

Der Hauptanwendungsfall ist pa11y-ci, ein Wrapper, der Pa11y auf viele URLs gleichzeitig anwendet und mit einem für die CI geeigneten Exit-Code beendet:

$ pa11y-ci --sitemap https://example.com/sitemap.xml

Dies ist genau der Workflow, den die meisten Barrierefreiheitsprogramme für nächtliche Regressionstests einsetzen: Die Sitemap der Website wird auf einem Cron-Schedule in pa11y-ci eingespeist, der Build schlägt fehl, wenn neue Verstöße auftreten, und es wird eine Meldung ausgegeben, wenn die Anzahl der Verstöße steigt.

Die Konfiguration liegt in .pa11yci (oder einer JSON-Datei) und erlaubt URL-spezifische Ausnahmen, Schweregrad-Schwellwerte, Viewport-Größen, benutzerdefinierte Aktionen (Anmeldung, Click-Through) und weitere Automatisierungsoptionen.

Pa11y im Vergleich zu axe-core und Lighthouse

Ein sinnvolles mentales Modell:

  • axe-core ist die Regel-Engine — die zugrundeliegende Erkennungsbibliothek. Sie wird über einen Wrapper verwendet.
  • Lighthouse ist ein solcher Wrapper, optimiert für vollständige Site-Qualitätsprüfungen (Performance + Barrierefreiheit + Best Practices + SEO).
  • Pa11y ist ein weiterer Wrapper, optimiert für barrierefreiheitsspezifisches CI-Gating über viele URLs hinweg.
  • axe-core CLI ist die dritte Variante — reines axe, ohne Pa11y-Wrapper, ebenfalls CI-geeignet.

Für detaillierte Einzelseitenanalysen ist Lighthouse besser geeignet. Für Site-weite Regressionstests mit vielen URLs ist Pa11y der praktische Standard. Für build-blockierende PR-Prüfungen auf einer einzelnen URL funktionieren axe-core CLI und Lighthouse-CI gleichermaßen gut.

Einschränkungen

Pa11y übernimmt alle Einschränkungen automatisierter Werkzeuge:

  • 30–40 % der WCAG-Probleme sind automatisch erkennbar; der Rest erfordert menschliches Urteilsvermögen.
  • Tastaturnavigation, Fokusreihenfolge und das Verhalten von Screenreadern können nicht getestet werden.
  • Da Pa11y in einem Headless-Browser läuft, werden Probleme, die nur bei echter Nutzerinteraktion auftreten (Rage-Clicks, Formularabbrüche, unerwartete Modal-Stapelung), nicht erfasst.

Innerhalb der Grenzen automatischer Erkennung ist Pa11y das operativ flexibelste Werkzeug unter den großen Optionen — insbesondere wenn der Prüfungsumfang „die gesamte Website, jede Nacht“ lautet und nicht „dieser spezifische Pull Request“.