Manuelle Accessibility-Audits systematisch durchführen

1. Warum manuelle Audits automatisierte Scanner ergänzen müssen

Automatisierte Testwerkzeuge wie axe-core, Lighthouse oder WAVE prüfen zuverlässig maschinell erkennbare Muster: fehlende alt-Attribute, ungültige ARIA-Kombinationen, doppelte IDs oder unzureichenden Farbkontrast bei statischem Text. Unabhängige Untersuchungen zeigen jedoch immer wieder dasselbe Bild: Automatisierte Scanner decken realistisch nur etwa 30 bis 40 Prozent der WCAG-Erfolgskriterien ab, die in einer echten Anwendung relevant sind. Der Rest erfordert menschliches Urteilsvermögen, weil er kontextabhängig ist.

Ob eine Fokusreihenfolge logisch ist, ob eine Screenreader-Ansage tatsächlich verständlich klingt oder ob ein Alternativtext den Bildinhalt sinnvoll beschreibt, kann kein Regelwerk allein entscheiden. Ein manueller Accessibility-Audit ergänzt genau diese Lücke: Er prüft die tatsächliche Bedienbarkeit mit Tastatur, Screenreader und veränderten Darstellungsbedingungen, statt nur den DOM-Baum gegen eine Regelliste abzugleichen. Beide Testarten schließen sich nicht aus, sondern ergänzen sich: Automatisierung deckt Breite schnell und günstig ab, der manuelle Audit deckt Tiefe und reale Nutzungsszenarien ab.

2. Der strukturierte Audit-Workflow im Überblick

Ein wiederholbarer Audit-Workflow braucht eine feste Struktur, sonst hängt das Ergebnis vom Zufall ab, welche Seite der Tester gerade öffnet. Bewährt hat sich eine Reihenfolge aus vier aufeinanderfolgenden Durchgängen, sogenannten Pässen: Keyboard-Only-Pass, Screenreader-Pass, Zoom- und Kontrast-Pass sowie Reduced-Motion-Pass. Jeder Pass simuliert eine andere reale Nutzungssituation und deckt dadurch unterschiedliche Barrieren auf. Vor dem ersten Pass wird eine feste Seitenliste definiert: kritische Nutzerflüsse wie Login, Warenkorb, Checkout und Formulare priorisiert vor Randseiten.

Wichtig ist, jeden Pass isoliert durchzuführen, statt Tastatur, Screenreader und Zoom gleichzeitig zu testen. Vermischte Tests führen zu unvollständigen Notizen, weil sich Symptome überlagern. Jeder Pass endet mit einer eigenen Rohliste an Beobachtungen, die erst im Anschluss gemeinsam mit den automatisierten Scan-Ergebnissen bewertet und priorisiert wird. Ein vollständiger Durchlauf über alle vier Pässe für einen typischen Checkout-Flow dauert erfahrungsgemäß zwischen vier und acht Stunden, abhängig von der Anzahl der Templates und Formularschritte.

3. Keyboard-Only-Pass: Tab-Reihenfolge, Fokus und Bedienbarkeit

Beim Keyboard-Only-Pass wird die Maus physisch beiseitegelegt oder deaktiviert und die gesamte Seite ausschließlich mit Tab, Shift+Tab, Enter, Leertaste und den Pfeiltasten bedient. Geprüft wird: Erreicht der Fokus jedes interaktive Element in einer logischen Reihenfolge? Ist der Fokusindikator jederzeit deutlich sichtbar? Lässt sich jede Aktion, die mit der Maus möglich ist, auch per Tastatur auslösen? Besonders kritisch sind Modals, Dropdown-Menüs und Custom-Widgets: Landet der Fokus beim Öffnen eines Dialogs automatisch im Dialog, und bleibt er dort gefangen, bis der Dialog geschlossen wird?

Ein häufiger Befund ist die sogenannte Keyboard-Trap, bei der der Fokus in einer Komponente hängen bleibt und mit Tab nicht mehr herausführt. Ebenso häufig: tabindex-Werte größer als null, die die natürliche DOM-Reihenfolge überschreiben und zu einer für Tastaturnutzer unvorhersehbaren Sprungreihenfolge führen. Der Test dauert pro Seite selten länger als fünf Minuten, deckt aber oft die schwerwiegendsten Befunde des gesamten Audits auf, weil ein blockierter Checkout-Schritt eine Transaktion vollständig verhindert.

<!-- Skip link must be the first focusable element in the DOM -->
<a href="#main-content" class="skip-link">Zum Hauptinhalt springen</a>

<style>
.skip-link {
  position: absolute;
  left: -9999px;
  top: 0;
  z-index: 999;
  background: #000;
  color: #fff;
  padding: 0.75rem 1rem;
}
/* Skip link becomes visible only when it receives keyboard focus */
.skip-link:focus {
  left: 0;
}
</style>

<!-- WRONG: positive tabindex overrides natural DOM order -->
<button tabindex="3">Speichern</button>
<button tabindex="1">Abbrechen</button>

<!-- RIGHT: rely on DOM order, tabindex="0" only for custom widgets -->
<div role="button" tabindex="0" aria-pressed="false" id="toggle-filter">
  Filter umschalten
</div>

<!-- Modal must trap focus while open and restore it on close -->
<div role="dialog" aria-modal="true" aria-labelledby="dialog-title">
  <p id="dialog-title" class="dialog-heading">Löschen bestätigen</p>
  <button id="dialog-confirm">Löschen</button>
  <button id="dialog-cancel">Abbrechen</button>
</div>

4. Screenreader-Pass: NVDA, VoiceOver und JAWS im Vergleich

Der Screenreader-Pass testet, ob Inhalte und Interaktionen verständlich vorgelesen werden, wenn der Bildschirm nicht als visuelle Referenz dient. In der Praxis empfiehlt sich mindestens eine Kombination aus NVDA mit Firefox unter Windows, weil diese Paarung kostenlos ist und die größte Marktverbreitung hat, sowie VoiceOver mit Safari unter macOS oder iOS für Apple-Nutzer. JAWS bleibt in Unternehmensumgebungen relevant, ist aber kostenpflichtig und verhält sich in Details anders als NVDA, weshalb kritische Flows idealerweise mit beiden getestet werden.

Getestet wird die Navigation über Überschriften (H-Taste in NVDA), Landmarken, Formularfelder und Links, jeweils ohne auf den Bildschirm zu schauen. Wichtige Prüfpunkte: Hat jeder interaktive Kontrollpunkt einen aussagekräftigen zugänglichen Namen? Werden dynamische Statusänderungen wie Warenkorb-Updates automatisch angesagt? Wird der Zustand von Checkboxen, Schaltern und Akkordeons korrekt kommuniziert? Ein Icon-Button ohne aria-label wird von NVDA oft nur als „Schaltfläche“ ohne weiteren Kontext vorgelesen, was ihn faktisch unbenutzbar macht.

<!-- WRONG: icon-only button has no accessible name -->
<button class="icon-btn">
  <svg aria-hidden="true"><!-- cart icon --></svg>
</button>

<!-- RIGHT: accessible name via aria-label, including dynamic state -->
<button class="icon-btn" aria-label="Warenkorb öffnen (3 Artikel)">
  <svg aria-hidden="true"><!-- cart icon --></svg>
</button>

<!-- Live region for asynchronous status updates -->
<!-- Must already exist in the DOM before the update happens -->
<div aria-live="polite" aria-atomic="true" class="sr-only" id="cart-status"></div>

<!-- Clearing before writing ensures identical consecutive messages -->
<!-- are still announced by the screen reader -->
<!-- element.textContent = ''; requestAnimationFrame(() => element.textContent = text); -->

5. Zoom- und Kontrast-Pass: 200 % Zoom und WCAG-Kontrastwerte

Der Zoom- und Kontrast-Pass prüft WCAG-Kriterium 1.4.4 (Textgröße anpassbar): Die Seite wird im Browser auf 200 Prozent gezoomt, ohne dass Inhalte abgeschnitten werden, sich überlappen oder horizontales Scrollen erzwungen wird. Ergänzend prüft der Reflow-Test nach 1.4.10 die Darstellung bei 400 Prozent Zoom in einem auf 320 Pixel Breite reduzierten Viewport, was einer typischen Smartphone-Ansicht bei starker Vergrößerung entspricht. Beide Tests decken zuverlässig starre Pixelbreiten, feste Container-Höhen und abgeschnittene Dropdown-Menüs auf.

Parallel wird der Farbkontrast gemessen: normaler Text benötigt mindestens 4,5:1 gegenüber dem Hintergrund, großer Text (ab 24px oder 19px fett) mindestens 3:1, und nicht-textuelle UI-Komponenten wie Fokusringe oder Icon-Buttons ebenfalls mindestens 3:1 nach Kriterium 1.4.11. Werkzeuge wie der Colour Contrast Analyser oder die Kontrastprüfung in den Chrome-DevTools messen dabei tatsächlich gerenderte Farben, inklusive Verläufen und Hintergrundbildern, die automatisierte Scanner oft nicht korrekt erfassen. Ein zusätzlicher Blick in den Dark Mode lohnt sich, weil invertierte Farbschemata häufig eigene Kontrastprobleme einführen.

6. Reduced-Motion-Pass: Animationen und Bewegungstrigger

Der Reduced-Motion-Pass prüft, ob eine Seite die Systemeinstellung prefers-reduced-motion respektiert, die Nutzer mit vestibulären Störungen oder Migräne aktivieren, um durch Bewegung ausgelöste Übelkeit oder Schwindel zu vermeiden. Getestet wird, indem die Einstellung in den Betriebssystem-Bedienhilfen aktiviert wird (macOS: Bedienungshilfen, Anzeige, Bewegung reduzieren; Windows: Erleichterte Bedienung, Anzeige) und anschließend Karussells, Parallax-Effekte, automatisch abspielende Videos und animierte GIFs erneut durchlaufen werden.

Ein häufiger Befund: CSS-Animationen respektieren die Media Query korrekt, aber ein per JavaScript gesteuertes Karussell prüft matchMedia('(prefers-reduced-motion: reduce)') nicht und läuft trotz aktivierter Einstellung unverändert weiter. Auch automatisch abspielende Hintergrundvideos ohne Pause-Steuerung sind ein wiederkehrendes Muster, das Kriterium 2.2.2 (Pausieren, Stoppen, Ausblenden) verletzt. Der Pass dauert pro Seite wenige Minuten, deckt aber Probleme auf, die für betroffene Nutzergruppen den Unterschied zwischen nutzbar und gesundheitlich riskant machen.

/* Respect user preference: disable non-essential animation */
@media (prefers-reduced-motion: reduce) {
  * {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }

  .hero-carousel {
    animation: none;
  }
}

/* Default: animation only runs when explicitly allowed by the user */
@media (prefers-reduced-motion: no-preference) {
  .fade-in {
    animation: fadeIn 400ms ease-out;
  }
}

@keyframes fadeIn {
  from { opacity: 0; transform: translateY(8px); }
  to   { opacity: 1; transform: translateY(0); }
}

7. Priorisierung nach echtem Nutzerimpact statt Regelverstoßzahl

Ein Bericht mit 200 automatisiert erkannten Verstößen wirkt bedrohlich, ist aber oft irreführend: 150 davon können identische, geringfügige Kontrastabweichungen in Fußzeilen-Links sein, während ein einziger Befund, eine Keyboard-Trap im Checkout, den Kaufabschluss für alle Tastaturnutzer vollständig verhindert. Die reine Anzahl an Regelverstößen ist deshalb kein geeignetes Priorisierungskriterium. Entscheidend ist der tatsächliche Nutzerimpact: Blockiert der Befund eine Kernaufgabe vollständig, erschwert er sie erheblich, oder ist er lediglich ein Komfortproblem ohne Aufgabenblockade?

Eine praktikable Priorisierungsmatrix kombiniert drei Faktoren: Schweregrad der Auswirkung (blockierend, erschwerend, kosmetisch), Reichweite (globale Navigation und Checkout wiegen schwerer als eine selten besuchte Unterseite) und WCAG-Konformitätsstufe (A-Verstöße vor AA vor AAA). Ein Befund, der WCAG-A verletzt und in jedem Checkout-Schritt auftritt, erhält die Stufe „kritisch“, unabhängig davon, wie viele automatisierte Regeln er im Scanner-Report auslöst. Diese Priorisierung sollte gemeinsam mit dem Entwicklungsteam kalibriert werden, damit Kapazität dort investiert wird, wo der Effekt für Nutzer am größten ist.

8. Befunde dokumentieren, die Entwickler wirklich umsetzen können

Ein Befund wie „Kontrast zu niedrig“ ohne Seitenangabe, Screenshot oder konkreten Farbwert ist für ein Entwicklungsteam kaum verwertbar und führt zu Rückfragen, die den gesamten Fix verzögern. Eine verwertbare Audit-Dokumentation enthält mindestens: exakte Reproduktionsschritte, den betroffenen WCAG-Erfolgskriterium samt Konformitätsstufe, erwartetes gegenüber tatsächlichem Verhalten, die genaue Code-Stelle oder Komponente, einen konkreten Lösungsvorschlag und die betroffene Nutzergruppe. Screenshots oder kurze Bildschirmaufnahmen sind besonders bei Fokus- und Screenreader-Befunden hilfreich, weil sie sonst schwer nachvollziehbar sind.

Ein strukturiertes, maschinenlesbares Format für jeden Befund erleichtert zusätzlich die spätere Auswertung, das Tracking im Ticketsystem und die Wiederverwendung in Regressionstests. Statt Freitext in einer Tabelle empfiehlt sich ein einheitliches Schema, das für jeden Befund dieselben Felder erzwingt, unabhängig davon, welcher Pass ihn aufgedeckt hat. So lassen sich Befunde aus verschiedenen Audits vergleichen und Wiederholungen über Releases hinweg erkennen.

{
  "id": "A11Y-0042",
  "wcag_criterion": "2.4.7 Focus Visible",
  "wcag_level": "AA",
  "pass_type": "keyboard",
  "severity": "critical",
  "user_impact": "Tastaturnutzer verlieren die Orientierung im Checkout, weil der Fokusring per CSS entfernt wurde.",
  "affected_pages": ["/checkout", "/checkout/payment"],
  "steps_to_reproduce": [
    "Seite ausschließlich per Tab-Taste bedienen, keine Maus verwenden",
    "Zum Button 'Zahlungspflichtig bestellen' tabben",
    "Fokusindikator visuell prüfen"
  ],
  "expected": "Deutlich sichtbarer Fokusring um den aktiven Button",
  "actual": "Kein sichtbarer Unterschied zwischen fokussiertem und nicht fokussiertem Zustand",
  "recommended_fix": "outline: none entfernen, stattdessen :focus-visible mit 3px Kontrastring definieren",
  "code_location": "web/css/source/_buttons.css:112",
  "source": "manual",
  "status": "open"
}

9. Manuelle und automatisierte Befunde in einem Report kombinieren

Getrennte Reports für automatisierte Scanner-Ergebnisse und manuelle Audit-Befunde führen fast immer dazu, dass ein Team nur die automatisierten Ergebnisse konsequent bearbeitet, weil sie leichter in die CI-Pipeline und das Ticketsystem integriert sind. Der wirksamere Ansatz ist ein kombinierter Report: axe-core-Ergebnisse aus dem CI-Lauf werden auf dasselbe Schema normalisiert wie die manuellen Befunde, mit einem gemeinsamen Schweregrad-Modell, einer Quellenkennzeichnung (automatisiert oder manuell) und einer einzigen priorisierten Liste als Grundlage für die Sprint-Planung.

Wichtig ist die Deduplizierung: Ein automatisiert erkannter Kontrastfehler und ein manuell dokumentierter Befund zur selben Komponente sollten zu einem Eintrag zusammengeführt werden, nicht doppelt im Backlog landen. Die folgende Übersicht zeigt, welche Prüfbereiche sich nicht allein durch Automatisierung abdecken lassen und warum der jeweilige manuelle Testschritt notwendig bleibt.

// Merge axe-core CI results with manually documented findings into one unified report
import axeResults from './reports/axe-ci-run.json' assert { type: 'json' };
import manualFindings from './reports/manual-audit.json' assert { type: 'json' };

function normalizeAxeViolation(violation) {
  return {
    id: `AXE-${violation.id}`,
    wcag_criterion: violation.tags.find(t => t.startsWith('wcag2')) ?? 'unmapped',
    severity: mapImpactToSeverity(violation.impact),
    source: 'automated',
    affected_pages: violation.nodes.map(n => n.target.join(' ')),
    status: 'open',
  };
}

function mapImpactToSeverity(impact) {
  // axe-core impact levels do not map 1:1 to real user severity
  const map = { critical: 'critical', serious: 'high', moderate: 'medium', minor: 'low' };
  return map[impact] ?? 'medium';
}

const unifiedReport = [
  ...axeResults.violations.map(normalizeAxeViolation),
  ...manualFindings,
].sort((a, b) => severityRank(a.severity) - severityRank(b.severity));

function severityRank(severity) {
  return { critical: 0, high: 1, medium: 2, low: 3 }[severity] ?? 4;
}

console.log(`Unified report: ${unifiedReport.length} findings`);

10. Zusammenfassung

Manuelle Accessibility-Audits schließen die Lücke, die automatisierte Scanner systematisch offenlassen. Vier aufeinanderfolgende Pässe, Keyboard-Only, Screenreader, Zoom- und Kontrast sowie Reduced-Motion, decken jeweils eigene Barrieren auf, die sich nur durch reale Nutzung erschließen. Entscheidend für den praktischen Nutzen ist die Priorisierung nach echtem Nutzerimpact statt nach der reinen Anzahl an Regelverstößen, damit Entwicklungsressourcen dort investiert werden, wo Nutzer tatsächlich blockiert sind.

Eine strukturierte, schemabasierte Dokumentation macht Befunde für Entwicklungsteams direkt umsetzbar, statt Rückfragen und Verzögerungen zu erzeugen. Der größte Hebel liegt darin, automatisierte und manuelle Ergebnisse in einem einzigen, deduplizierten Report zusammenzuführen, statt zwei getrennte Backlogs zu pflegen, von denen langfristig nur einer konsequent bearbeitet wird.

11. FAQ: Manuelle Accessibility-Audits systematisch durchführen