Barrierefreiheit-Checker-API: WCAG-Prüfungen aus Ihren eigenen Tools

Die Pandus-API liefert Ihnen dieselben automatischen Barrierefreiheitsprüfungen wie das Kundenkonto, aber aus Ihren eigenen Tools heraus: aus einem Deployment-Skript, einem Agentur-Dashboard oder einem Ticketsystem. Sie prüft WCAG 2.2 Stufe A und AA mit der Engine axe-core in einem echten Browser über die Seiten einer Website hinweg und liefert Ergebnisse mit verständlichen Erklärungen in sieben Berichtssprachen.

Alles auf dieser Seite stammt aus unserer veröffentlichten OpenAPI-Spezifikation. Die Ergebnisse sind eine automatische Prüfung, kein vollständiges Audit und keine Rechtsberatung.

Jeder Endpunkt mit Parametern, Antwortbeispielen, Fehlern und Codebeispielen in curl, JavaScript, PHP und Python steht in der API-Dokumentation.

Was die API kann

Die Basis-URL lautet https://pandus.online/api/v1. Bericht und PDF akzeptieren den optionalen Parameter lang: en, uk, de, pl, cs, ro oder ru. Ohne ihn wird die Berichtssprache der Website verwendet.

Der JSON-Bericht enthält die Problemgruppen mit ihren Regelkarten, Beispiele, betroffene Seiten, Summen nach Schweregrad, einen Vorher-nachher-Vergleich mit der vorherigen Prüfung und den Trend. Eine Prüfung hat den Status queued, running, completed oder failed; die Bericht-Endpunkte antworten mit 409, bis sie abgeschlossen ist.

Authentifizierung und Limits

Erstellen Sie im Kundenkonto unter API und Webhooks ein Token und senden Sie es als Bearer-Token:

curl -H "Authorization: Bearer $PANDUS_TOKEN" \
     https://pandus.online/api/v1/sites

• Ein Token gehört zum Team, nicht zu einer Person, und funktioniert daher weiter, wenn jemand das Unternehmen verlässt.
• Berechtigungen: read umfasst alle GET-Anfragen, write umfasst das Anlegen und Löschen von Websites und das Starten von Prüfungen. Für ein Dashboard genügt ein Token nur mit Leserechten.
• Rate Limit: 60 Anfragen pro Minute und Token. Darüber erhalten Sie HTTP 429 mit einem Retry-After-Header.
• Tariflimits gelten wie im Kundenkonto: Anzahl der Websites, Seiten pro Prüfung, Verlauf und wie oft eine Prüfung von Hand gestartet werden darf. Eine Anfrage über dem Limit liefert HTTP 422 mit einer Meldung.
• Die API ist in den Tarifen Pro und Agency enthalten – siehe Preise.

Website anlegen und Prüfung starten

curl -X POST https://pandus.online/api/v1/sites \
     -H "Authorization: Bearer $PANDUS_TOKEN" \
     -H "Content-Type: application/json" \
     -d '{"url": "shop.example", "report_locale": "de", "platform": "shopify", "tags": ["client-a"]}'

url und report_locale sind Pflichtfelder. Mit platform (shopify, woocommerce, prestashop, shoptet oder other) zeigt der Bericht Korrekturanleitungen für diese Plattform; mit tags können Agenturen Websites nach Kunden sortieren. Die Antwort ist 201 mit der neuen Website, und ihre erste Prüfung wird in die Warteschlange gestellt.

Um später erneut zu prüfen, zum Beispiel nach einem Release:

curl -X POST https://pandus.online/api/v1/sites/$SITE_ID/scans \
     -H "Authorization: Bearer $PANDUS_TOKEN"

Die Antwort ist 202 mit der eingereihten Prüfung. Fragen Sie dann entweder GET /scans/{scan} ab oder warten Sie besser auf einen Webhook.

Webhooks

Es werden zwei Ereignisse gesendet: scan.completed und issues.new. Jedes ist ein JSON-POST der Form {id, type, created_at, data: {scan, site, new_issues}} mit diesen Headern:

• Pandus-Event – der Ereignistyp;
• Pandus-Delivery – die Zustell-ID;
• Pandus-Signature: t=<unix>,v1=<hex> – v1 ist ein HMAC-SHA256 aus "<t>.<unveränderter Body>" mit dem Secret Ihres Endpunkts.

Antworten Sie innerhalb von 10 Sekunden mit einem 2xx-Status. Fehlgeschlagene Zustellungen werden etwa einen Tag lang wiederholt; im Kundenkonto können Sie ein Testereignis senden und eine Zustellung von Hand erneut auslösen. Eine minimale Prüfung in Node.js:

import crypto from 'node:crypto';

function verify(rawBody, header, secret) {
    const parts = Object.fromEntries(
        header.split(',').map((p) => p.split('=')),
    );
    const expected = crypto
        .createHmac('sha256', secret)
        .update(`${parts.t}.${rawBody}`)
        .digest('hex');
    const given = Buffer.from(parts.v1 ?? '');
    return (
        given.length === expected.length &&
        crypto.timingSafeEqual(Buffer.from(expected), given)
    );
}

Verwenden Sie den unveränderten Request-Body, kein neu serialisiertes JSON-Objekt, und lehnen Sie alte Zeitstempel ab, um Replay-Angriffe zu verhindern.

Die API in der CI nutzen

Die API prüft die öffentliche Website und passt daher nach einem Deployment in die Produktion oder auf eine öffentlich erreichbare Vorschau:

1. Ihre Pipeline führt das Deployment aus.
2. Ein Job ruft POST /sites/{site}/scans auf.
3. Ihr Endpunkt erhält scan.completed oder issues.new, liest GET /scans/{scan}/report und öffnet ein Ticket oder postet in einen Chat.

Lassen Sie einen Merge nicht auf eine Prüfung der gesamten Website warten; eine ganze Website kann einige Zeit dauern. Für schnelles Feedback bei jedem Pull Request führen Sie axe-core in Ihren eigenen Tests aus – siehe Barrierefreiheitstests mit Playwright – und lassen Pandus die Produktionswebsite jede Woche und nach Releases beobachten.

Localhost, Staging und Seiten hinter einem Login

Unser Scanner öffnet nur öffentliche Adressen. Er blockiert private und lokale Netze, einschließlich localhost, vor und nach jeder Weiterleitung – eine Sicherheitsmaßnahme, keine Lücke, die wir schließen wollen. Für alles, was nicht öffentlich ist:

• Die Browser-Erweiterung für Chrome, Edge und Firefox prüft die Seite so, wie Ihr Browser sie anzeigt: einen lokalen Entwicklungsserver, eine passwortgeschützte Staging-Website, den Warenkorb, den Checkout, das Kundenkonto. Eine Prüfung kann in Pandus bei der Website gespeichert werden.
• Ihre eigenen Playwright-Tests mit @axe-core/playwright erreichen alles, was Ihre CI erreicht.
• Bevor Sie ein Konto anlegen, testen Sie den kostenlosen WCAG-Checker auf einer beliebigen öffentlichen Seite.

Was die API nicht tut

Sie führt kein manuelles Audit durch, sie „repariert“ eine Website nicht mit einem Skript, und sie entscheidet nicht, ob ein Gesetz für Sie gilt. Sie liefert automatische Befunde mit den Verweisen auf WCAG und EN 301 549 aus unserer Regelbibliothek und einen Bericht, den ein Shop-Inhaber oder der Kunde einer Agentur lesen kann. Für eine WordPress-Website gibt es zusätzlich das WordPress-Plugin, das ein eigenes, an die Website gebundenes Token verwendet.

Häufige Fragen

Hat Pandus eine API für Barrierefreiheitsprüfungen?

Ja. Mit der REST-API v1 können Sie Websites auflisten und anlegen, Prüfungen starten, deren Status abfragen, den Bericht als JSON oder PDF abrufen und Screenshots herunterladen. Webhooks melden, wann eine Prüfung fertig ist und wann neue Probleme auftauchen.

In welchen Tarifen ist die API enthalten?

Im Pro-Tarif und in den Agency-Tarifen. Im Free-Tarif und beim Express-Bericht ist die API nicht enthalten; Tokens eines Teams, das in einen solchen Tarif wechselt, funktionieren nicht mehr, bis der Tarif die API wieder einschließt.

Kann die API localhost oder einen Staging-Server prüfen?

Nein. Unser Scanner öffnet aus Sicherheitsgründen nur öffentliche Adressen und blockiert private und lokale Netze. Für localhost, Staging und Seiten hinter einem Login nutzen Sie die Browser-Erweiterung oder führen axe-core in Ihren eigenen Playwright-Tests aus.

Wie werden Webhooks abgesichert?

Jede Zustellung enthält einen Pandus-Signature-Header mit Zeitstempel und einem HMAC-SHA256 aus Zeitstempel und unverändertem Body, erzeugt mit dem Secret Ihres Endpunkts. Vergleichen Sie ihn, bevor Sie dem Payload vertrauen.

Ist ein API-Ergebnis ein WCAG-Audit?

Nein. Die API liefert die Ergebnisse einer automatischen Prüfung, kein vollständiges Audit und keine Rechtsberatung. Viele WCAG-Kriterien erfordern weiterhin eine manuelle Prüfung.