Barrierefreiheit kontinuierlich verbessern statt Einmal-Projekt

1. Warum ein einmaliges Audit nicht ausreicht

Viele Unternehmen behandeln Barrierefreiheit wie ein Projekt mit Start- und Enddatum: Eine Agentur wird beauftragt, ein Audit-Bericht mit hundert Fundstellen kommt zurück, das Entwicklungsteam arbeitet die Liste ab, und das Ticket wird geschlossen. Aus Sicht des Managements ist Barrierefreiheit damit erledigt. Tatsächlich ist ein Accessibility-Audit aber immer nur eine Momentaufnahme des Codes zum Zeitpunkt der Prüfung, keine dauerhafte Eigenschaft der Anwendung. Sobald sich die Codebasis weiterentwickelt, verändert sich auch der WCAG-Konformitätsstatus, ohne dass es jemand bemerkt.

Der Effekt zeigt sich in der Praxis zuverlässig: Sechs Monate nach einem erfolgreichen Audit führt ein neues Feature auf der Produktdetailseite fehlende Alternativtexte, eine unterbrochene Fokusreihenfolge oder einen Kontrastfehler im neuen Badge-Design wieder ein. Ohne automatisierte Absicherung bemerkt das niemand, bis eine Beschwerde eingeht oder das nächste Audit ansteht, oft ein bis zwei Jahre später. Barrierefreiheit verhält sich damit strukturell wie Sicherheit oder Performance: eine Eigenschaft, die ohne kontinuierliche Pflege systematisch verfällt, nicht weil das Team nachlässig ist, sondern weil jede Codeänderung ein potenzielles Regressionsrisiko trägt.

2. Barrierefreiheit als Prozess statt Projekt etablieren

Der entscheidende Perspektivwechsel besteht darin, Barrierefreiheit nicht als abschließbares Projekt, sondern als fortlaufende Praxis zu verstehen, vergleichbar mit Security-Monitoring oder Performance-Budgets. Ein Prozess hat kein Enddatum, sondern wiederkehrende Aktivitäten mit klaren Verantwortlichkeiten. Drei Bausteine ergänzen sich dabei gegenseitig: automatisierte Checks in der CI-Pipeline, die bei jedem Commit strukturelle Fehler abfangen, periodische manuelle Audits, die interaktive und Screenreader-spezifische Probleme aufdecken, und ein Feedback-Kanal, der reale Nutzungsprobleme sichtbar macht, die kein Test vorhersehen konnte.

Diese drei Bausteine decken unterschiedliche Fehlerklassen ab und ersetzen sich nicht gegenseitig. Automatisierte Tools wie axe-core erkennen zuverlässig fehlende Labels, ungültige ARIA-Attribute und Kontrastverstöße, sind aber blind für schlechte Lesereihenfolge oder verwirrende Screenreader-Ansagen. Manuelle Audits mit echten Hilfsmitteln decken genau diese Lücke ab, sind aber zu aufwändig für jeden Commit. Der Feedback-Kanal schließlich fängt Randfälle ab, die weder Automatisierung noch Stichproben-Audits abdecken, etwa spezifische Kombinationen aus Betriebssystem, Screenreader und Browser, die im Testlabor nie zusammenkommen.

3. Automatisierte Checks in der CI-Pipeline

Automatisierte Accessibility-Tests gehören in dieselbe CI-Pipeline wie Unit- und Integrationstests, nicht in ein separates, selten ausgeführtes Audit-Skript. Bibliotheken wie axe-core lassen sich direkt in Playwright- oder Cypress-Tests einbinden und prüfen automatisch generiertes HTML gegen WCAG-2.2-Regeln. Der entscheidende Vorteil gegenüber einem manuellen Audit: Ein Verstoß wird erkannt, bevor er in den Hauptzweig gemerged wird, nicht erst Monate später bei der nächsten externen Prüfung. Für Hyvä-Shops bietet es sich an, die wichtigsten Templates wie Produktdetailseite, Kategorieseite, Warenkorb und Checkout in die automatisierte Prüfung aufzunehmen, da dort die meisten Nutzerinteraktionen stattfinden.

Wichtig ist, den Build bei kritischen Verstößen tatsächlich fehlschlagen zu lassen, nicht nur eine Warnung im Log zu hinterlassen, die niemand liest. Gleichzeitig muss das Team wissen, dass automatisierte Tools laut gängigen Schätzungen nur etwa 30 bis 50 Prozent aller WCAG-Erfolgskriterien zuverlässig prüfen können. Kontrast, fehlende Labels und strukturelle ARIA-Fehler sind automatisierbar, Lesereihenfolge, sinnvolle Fokusreihenfolge bei komplexen Interaktionen und die Qualität von Screenreader-Ansagen bleiben Aufgabe der manuellen Prüfung. CI-Checks sind damit ein notwendiges Sicherheitsnetz gegen Regressionen, kein Ersatz für menschliche Prüfung.

// tests/a11y/pdp.spec.ts
// Fails the CI build when axe-core finds critical or serious violations
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test.describe('Accessibility: product detail page', () => {
  test('has no critical or serious WCAG 2.2 violations', async ({ page }) => {
    await page.goto('/catalog/product/view/id/42');
    await page.waitForSelector('[data-test="product-add-to-cart"]');

    const results = await new AxeBuilder({ page })
      .withTags(['wcag2a', 'wcag2aa', 'wcag22aa'])
      .analyze();

    const blocking = results.violations.filter(
      (violation) => violation.impact === 'critical' || violation.impact === 'serious'
    );

    // Print full detail for debugging, but only fail on blocking severity
    if (blocking.length > 0) {
      console.log(JSON.stringify(blocking, null, 2));
    }

    expect(blocking, 'blocking accessibility violations found').toHaveLength(0);
  });
});

4. Periodische manuelle Audits: Screenreader, Tastatur, Kontrast

Manuelle Audits bleiben unverzichtbar, weil sie Probleme aufdecken, die kein automatisierter Test erkennen kann: eine Screenreader-Ansage, die technisch korrekt, aber inhaltlich verwirrend ist, eine Tastaturfalle in einem Alpine.js-Dropdown, oder ein Fokusindikator, der zwar den Kontrastwert erfüllt, aber bei schnellem Tabben kaum wahrnehmbar ist. Ein vollständiges Audit mit NVDA, VoiceOver und reiner Tastaturnavigation über den gesamten Shop ist aufwändig und lohnt sich deshalb nicht bei jedem Release, wohl aber in einem festen Rhythmus, etwa vierteljährlich oder nach größeren Redesigns.

Effizienter als ein vollständiges Audit bei jedem Zyklus ist ein diff-basierter Ansatz: Statt den gesamten Shop erneut zu prüfen, wird gezielt geprüft, welche Templates und Komponenten sich seit dem letzten Audit verändert haben, und nur diese werden manuell nachgeprüft. Das reduziert den Prüfaufwand erheblich, ohne blinde Flecken bei neuen Features zu riskieren. Ergänzend hilft eine rollierende Stichprobe: Jeden Monat wird ein anderer Bereich des Shops vollständig mit Screenreader getestet, sodass über ein Jahr verteilt der gesamte Shop mindestens einmal gründlich geprüft wurde, ohne dass ein einzelner Sprint überlastet wird.

// scripts/audit-scope.js
// Lists templates changed since the last recorded manual audit,
// so reviewers can focus manual testing on real risk instead of the whole shop
import { execSync } from 'node:child_process';
import fs from 'node:fs';

const lastAudit = JSON.parse(fs.readFileSync('accessibility-debt.json', 'utf8')).lastManualAudit;
const changedFiles = execSync(`git diff --name-only ${lastAudit.commit}..HEAD`)
  .toString()
  .split('\n')
  .filter((file) => file.includes('/templates/') && file.endsWith('.phtml'));

console.log(`Templates changed since last manual audit (${lastAudit.date}):`);
changedFiles.forEach((file) => console.log(` - ${file}`));
console.log(`\nTotal: ${changedFiles.length} template(s) require targeted re-audit.`);

5. Feedback-Kanal für Nutzer mit Assistenztechnologien

Kein Audit-Team und keine automatisierte Testsuite kann jede reale Nutzungssituation vorhersehen. Ein direkter Feedback-Kanal für Barrierefreiheitsprobleme schließt genau diese Lücke, vorausgesetzt er ist selbst barrierefrei erreichbar und wird tatsächlich überwacht. In der Praxis bedeutet das: ein klar beschrifteter Link im Footer, erreichbar per Tastatur und mit korrektem ARIA-Label, der zu einem einfachen Formular oder einer dedizierten E-Mail-Adresse führt, nicht ein generisches Kontaktformular, in dem Accessibility-Meldungen zwischen Rückgabeanfragen untergehen.

Damit der Kanal funktioniert, braucht er einen klaren Prozessverantwortlichen und eine definierte Reaktionszeit, ähnlich wie bei Sicherheitsmeldungen. Eine Meldung über einen unbenutzbaren Checkout-Schritt sollte innerhalb weniger Werktage bestätigt und priorisiert werden, nicht in einem allgemeinen Support-Postfach versickern. Wichtig ist außerdem, eingehende Meldungen strukturiert in das Accessibility-Backlog zu überführen, mit Angabe des betroffenen WCAG-Kriteriums, der genutzten Hilfstechnologie und der Schwere, damit die Meldung nicht isoliert bleibt, sondern in denselben Tracking-Prozess einfließt wie automatisiert und manuell gefundene Probleme.

<!-- Hyva phtml: accessible footer link for accessibility feedback -->
<div class="border-t border-gray-200 pt-4 mt-4">
  <a
    href="mailto:barrierefreiheit@mironsoft.de"
    class="inline-flex items-center gap-2 text-sm text-gray-700 underline hover:text-gray-900 focus-visible:outline focus-visible:outline-2 focus-visible:outline-offset-2"
    aria-label="Barrierefreiheitsproblem melden per E-Mail"
  >
    <svg class="w-4 h-4" aria-hidden="true" fill="none" stroke="currentColor" viewBox="0 0 24 24">
      <path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M3 8l7.89 5.26a2 2 0 002.22 0L21 8M5 19h14a2 2 0 002-2V7a2 2 0 00-2-2H5a2 2 0 00-2 2v10a2 2 0 002 2z"/>
    </svg>
    Barriere gefunden? Jetzt melden
  </a>
</div>

6. Barrierefreiheits-Schulden wie technische Schulden verfolgen

Der wirksamste Hebel gegen das Einmal-Projekt-Denken ist, gefundene Accessibility-Probleme genauso zu behandeln wie technische Schulden: als lebendiges, priorisiertes Backlog, nicht als geschlossenes Audit-Ticket. Jeder Fund, ob aus CI, manuellem Audit oder Feedback-Kanal, bekommt einen Eintrag mit betroffenem WCAG-Kriterium, Schweregrad, betroffener Komponente und Fundzeitpunkt. Dieses Backlog wird regelmäßig priorisiert, ähnlich wie ein Sicherheits-Backlog, und nicht erst wieder angeschaut, wenn das nächste externe Audit ansteht.

In der Praxis lässt sich dieses Backlog entweder im bestehenden Ticket-System als eigenes Label führen oder, für bessere Automatisierbarkeit, als strukturierte Datei im Repository, die von CI-Skripten gelesen und aktualisiert werden kann. Der Vorteil einer versionierten Datei: Sie lässt sich in Reports auswerten, in Dashboards visualisieren und mit dem letzten manuellen Audit-Zeitpunkt verknüpfen, wie im diff-basierten Audit-Ansatz aus Abschnitt vier bereits gezeigt. Wichtig ist, dass ein Eintrag erst geschlossen wird, wenn ein automatisierter oder manueller Test seine Behebung tatsächlich bestätigt, nicht wenn der zuständige Entwickler die Änderung lediglich für erledigt hält.

{
  "lastManualAudit": {
    "date": "2026-04-15",
    "commit": "a3f9c21",
    "auditor": "external-agency"
  },
  "debtItems": [
    {
      "id": "A11Y-0142",
      "wcagCriterion": "1.4.3 Contrast (Minimum)",
      "severity": "serious",
      "component": "catalog/product/card",
      "source": "ci-axe-core",
      "discovered": "2026-06-02",
      "status": "open",
      "description": "Badge text on sale price uses #ffffff on #f59e0b, ratio 2.1:1"
    },
    {
      "id": "A11Y-0143",
      "wcagCriterion": "2.4.3 Focus Order",
      "severity": "moderate",
      "component": "checkout/shipping-step",
      "source": "manual-audit",
      "discovered": "2026-04-15",
      "status": "in-progress",
      "description": "Tab order jumps from address field to promo code, skipping shipping method"
    }
  ]
}

7. Verantwortlichkeiten und Ownership im Team verankern

Prozesse ohne Ownership verfallen, weil Verantwortung, die niemandem konkret zugeordnet ist, in der Praxis niemandem gehört. Ein bewährtes Muster ist die Rolle des Accessibility Champions pro Team oder Squad: keine Vollzeitstelle, sondern eine benannte Person, die CI-Fehlschläge zuerst sichtet, das Debt-Backlog priorisiert und als Ansprechpartner für Rückfragen dient. Diese Rolle sollte rotieren oder zumindest regelmäßig überprüft werden, damit Wissen nicht bei einer einzelnen Person hängen bleibt und beim Teamwechsel verloren geht.

Zusätzlich gehören Accessibility-Kriterien in die Definition of Done und in die Pull-Request-Vorlage, als konkrete Checkbox statt als vage Erwartung. Eine PR-Vorlage mit den Punkten Tastaturbedienbarkeit geprüft, Kontrastwerte geprüft, axe-core-Check grün macht sichtbar, was sonst implizit bleibt, und verhindert, dass Barrierefreiheit im Zeitdruck als optional behandelt wird. Code-Reviews sollten mindestens eine Reviewer-Frage zur Barrierefreiheit enthalten, etwa ob interaktive Elemente per Tastatur erreichbar sind, damit die Prüfung Teil des normalen Review-Flusses wird, statt eine separate, oft übersprungene Aktivität zu bleiben.

8. Regressionsschutz durch Component-Tests und Design-System-Guards

Der wirksamste Regressionsschutz setzt nicht auf Seitenebene an, sondern auf Komponentenebene, weil dort die Wiederverwendung am größten ist. Ein ARIA-Muster, das einmal korrekt in der Basis-Dropdown-Komponente des Hyvä-Themes implementiert ist, schützt automatisch jede Stelle im Shop, die diese Komponente verwendet, solange niemand sie lokal überschreibt. Component-Tests, die gezielt Fokusverhalten, ARIA-Attribute und Tastaturinteraktion einer einzelnen Alpine.js-Komponente prüfen, laufen deutlich schneller als seitenweite End-to-End-Tests und lassen sich bei jedem Commit ausführen, nicht nur im nächtlichen Build.

Design-System-Guards gehen noch einen Schritt weiter: Kontrastwerte, Fokus-Styles und Mindestabstände für Klickflächen werden als Design-Token zentral definiert, sodass ein Entwickler sie gar nicht erst unterschreiten kann, ohne den Token bewusst zu überschreiben. Eine globale :focus-visible-Regel mit ausreichendem Kontrast, ein zentraler Skip-Link und respektiertes prefers-reduced-motion sind Beispiele für Schutzmechanismen, die auf CSS-Ebene greifen, bevor überhaupt ein Test laufen muss. Diese Kombination aus Component-Tests und CSS-Guards verhindert die meisten Regressionen strukturell, statt sie erst nachträglich per Audit zu entdecken.

/* tailwind.source.css: design-token-level accessibility guards */
@layer base {
  :focus-visible {
    outline: 2px solid #18181b;
    outline-offset: 2px;
  }

  .skip-link {
    position: absolute;
    left: -9999px;
    top: 0;
    z-index: 100;
    background: #18181b;
    color: #ffffff;
    padding: 0.75rem 1.5rem;
    border-radius: 0 0 0.5rem 0;
  }

  .skip-link:focus {
    left: 0;
  }

  @media (prefers-reduced-motion: reduce) {
    *, *::before, *::after {
      animation-duration: 0.01ms !important;
      animation-iteration-count: 1 !important;
      transition-duration: 0.01ms !important;
      scroll-behavior: auto !important;
    }
  }
}

9. Einmal-Audit vs. kontinuierlicher Prozess im Vergleich

Die Unterschiede zwischen einem einmaligen Audit-Projekt und einem kontinuierlichen Prozess zeigen sich am deutlichsten, wenn man beide entlang derselben Dimensionen vergleicht: Wann wird ein Problem erkannt, wer ist verantwortlich, und was passiert nach der ersten Behebung.

Kein Baustein des kontinuierlichen Prozesses ersetzt die anderen vollständig. Erst das Zusammenspiel aus automatisierten Checks, periodischen manuellen Audits, einem funktionierenden Feedback-Kanal und einem gepflegten Debt-Backlog macht aus einem punktuellen Audit-Ergebnis eine tatsächlich stabile, dauerhafte WCAG-Konformität, die auch nach dem zehnten Deployment nach dem letzten Audit noch Bestand hat.

10. Zusammenfassung

Ein einmaliges Accessibility-Audit beschreibt den Zustand einer Anwendung an einem einzigen Tag, nicht ihre dauerhafte Konformität. Automatisierte CI-Checks mit axe-core fangen strukturelle Regressionen bei jedem Commit ab, periodische manuelle Audits mit Screenreader und Tastatur decken Probleme auf, die kein Tool erkennen kann, und ein erreichbarer Feedback-Kanal schließt die verbleibende Lücke zu echten Nutzungssituationen. Zusammen ersetzen diese drei Bausteine das Einmal-Projekt durch einen fortlaufenden Prozess.

Der zweite entscheidende Baustein ist organisatorisch: Gefundene Probleme gehören in ein lebendiges Debt-Backlog mit Schweregrad und WCAG-Kriterium, nicht in eine abgehakte Audit-Liste. Ein benannter Accessibility Champion pro Team, Kriterien in der Definition of Done und Component-Tests auf Design-System-Ebene sorgen dafür, dass Barrierefreiheit Teil des normalen Entwicklungsalltags wird, statt eine wiederkehrende externe Sonderaufgabe zu bleiben.

11. FAQ: Barrierefreiheit kontinuierlich verbessern