CI/CD Integration - Accessibility-Tests in der Pipeline

Accessibility-Bugs zu finden nachdem die Seite live ist, ist teuer. Besser: Probleme erkennen bevor sie in Produktion gehen. So integrieren Sie automatische WCAG-Tests in Ihre CI/CD-Pipeline.

Warum Accessibility in der Pipeline?

Ohne CI/CD-Integration

1. Entwickler baut Feature
2. Feature geht in Produktion
3. Wochen später: Accessibility-Audit deckt Probleme auf
4. Entwickler muss zurück zum Feature, Kontext ist weg
5. Fix dauert Stunden statt Minuten

Mit CI/CD-Integration

1. Entwickler baut Feature
2. Pipeline läuft automatisch
3. Accessibility-Test schlägt fehl: "3 neue Violations"
4. Entwickler behebt sie sofort (Kontext ist noch frisch)
5. Feature geht barrierefrei in Produktion

Kosten für einen Fix:

• Während der Entwicklung: 5-15 Minuten
• Nach dem Launch: 2-8 Stunden
• Nach einem Audit: 1-3 Tage (Kontext fehlt, muss neu einarbeiten)

Native Integrationen

ScanClusive bietet fertige Integrationen für alle gängigen CI/CD-Plattformen - kein Shell-Scripting erforderlich.

GitHub Actions

Direkt aus dem GitHub Marketplace installieren:

name: Accessibility Scan
on: [push, pull_request]

permissions:
  pull-requests: write

jobs:
  accessibility:
    runs-on: ubuntu-latest
    steps:
      - uses: scanclusive/scanclusive-action@v1
        id: scan
        with:
          api-key: ${{ secrets.SCANCLUSIVE_API_KEY }}
          project-id: ${{ secrets.SCANCLUSIVE_PROJECT_ID }}
          threshold: 90
          fail-on-violations: true

      # Optional: Ergebnis als PR-Kommentar posten
      - name: Comment on PR
        if: github.event_name == 'pull_request' && always()
        uses: actions/github-script@v7
        with:
          script: |
            const score = '${{ steps.scan.outputs.compliance-score }}';
            const violations = '${{ steps.scan.outputs.total-violations }}';
            const reportUrl = '${{ steps.scan.outputs.report-url }}';
            const emoji = parseInt(score) >= 90 ? '✅' : parseInt(score) >= 70 ? '⚠️' : '❌';
            await github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: `## ${emoji} ScanClusive Accessibility Report\n\n| Metrik | Wert |\n|--------|------|\n| Compliance Score | **${score}%** |\n| Violations gesamt | ${violations} |\n\n[Vollständigen Bericht ansehen](${reportUrl})`
            });

GitLab CI

Wiederverwendbares Template aus scanclusive/ci-templates einbinden:

# Required CI/CD variables (Settings > CI/CD > Variables):
#   SCANCLUSIVE_API_KEY    - your API key (masked)
#   SCANCLUSIVE_PROJECT_ID - your project ID

include:
  - remote: 'https://gitlab.com/scanclusive/ci-templates/-/raw/main/.scanclusive-scan.yml'

accessibility_scan:
  extends: .scanclusive-scan
  variables:
    SCANCLUSIVE_THRESHOLD: "90"
    SCANCLUSIVE_FAIL_ON_VIOLATIONS: "true"
  rules:
    - if: $CI_MERGE_REQUEST_IID
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Bitbucket Pipelines

Docker Pipe aus scanclusive/scanclusive-pipe verwenden:

pipelines:
  default:
    - step:
        name: Accessibility Scan
        script:
          - pipe: docker://scanclusive/scanclusive-pipe:1.0.1
            variables:
              SCANCLUSIVE_API_KEY: $SCANCLUSIVE_API_KEY
              SCANCLUSIVE_PROJECT_ID: $SCANCLUSIVE_PROJECT_ID
              SCANCLUSIVE_THRESHOLD: "90"
              SCANCLUSIVE_FAIL_ON_VIOLATIONS: "true"
        artifacts:
          - scanclusive-results.json

Webhook API direkt nutzen

Für andere CI-Plattformen oder eigene Integrationen steht die REST API zur Verfügung:

curl -X POST https://scanclusive.com/api/webhooks/ci \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"projectId": "your-project-id"}'

Ergebnis abfragen:

curl "https://scanclusive.com/api/webhooks/ci?scanId=SCAN_ID" \
  -H "x-api-key: YOUR_API_KEY"

Die vollständige API-Dokumentation bietet alle verfügbaren Endpunkte.

Welche Violations sollten den Build brechen?

Nicht jede Violation sollte das Deployment blockieren. Wir empfehlen:

Impact	Build brechen?	Begründung
Critical	Ja	Blockiert Nutzer komplett
Serious	Optional	Starke Beeinträchtigung
Moderate	Nein	Warnung reichen
Minor	Nein	Nur informativ

Empfohlene Schwellenwerte

Die Schwellenwerte können Sie direkt im Shell-Skript Ihrer Pipeline prüfen (siehe Beispiele oben). Zum Beispiel:

• Streng (neue Projekte): Build fehlschlagen lassen bei criticalCount > 0 oder seriousCount > 0
• Moderat (bestehende Projekte): Build fehlschlagen lassen nur bei criticalCount > 0
• Weich (Einstieg): Nur Warnungen ausgeben, Build nicht blockieren

Best Practices

1. Klein anfangen

Starten Sie mit Warnungen, nicht mit Build-Blockern. Lassen Sie dem Team Zeit, sich an Accessibility-Feedback zu gewöhnen. Verschärfen Sie die Regeln schrittweise.

2. Nur relevante Seiten testen

Testen Sie in der Pipeline nicht die gesamte Website, sondern die Seiten, die sich geändert haben. Das spart Zeit und gibt gezieltes Feedback.

3. Ergebnisse sichtbar machen

Posten Sie die Ergebnisse als Kommentar in den Pull Request. So sieht der Entwickler sofort, was zu tun ist.

4. Baseline setzen

Bei bestehenden Projekten: Setzen Sie eine Baseline mit den aktuellen Violations. Neue Violations brechen den Build, bestehende werden als technische Schuld verwaltet.

5. Staging-Umgebung testen

Testen Sie gegen Ihre Staging-Umgebung, nicht gegen Produktion. So fangen Sie Probleme ab, bevor echte Nutzer betroffen sind.

Fazit

Accessibility-Tests in der CI/CD-Pipeline sind der effektivste Weg, Barrierefreiheit dauerhaft sicherzustellen. Einmal eingerichtet, laufen sie automatisch bei jedem Deployment und fangen Regressionen ab, bevor sie in Produktion gehen.

Richten Sie ScanClusive als Teil Ihrer Pipeline ein - CI/CD-Dokumentation ansehen.