Barrierefreiheitstests mit KI-Unterstützung: Claude für WCAG-konforme Prüfungen

1. Warum Accessibility-Testing oft zu kurz kommt

Barrierefreiheit wird in vielen Projekten erst spät im Entwicklungsprozess berücksichtigt, meist dann, wenn ein Audit oder eine gesetzliche Anforderung wie das Barrierefreiheitsstärkungsgesetz einen konkreten Termin setzt. Bis dahin sammeln sich in typischen Frontend-Codebasen zahlreiche kleinere Verstöße an: fehlende Alternativtexte, unzureichende Farbkontraste, interaktive Elemente ohne Tastaturfokus, Formulare ohne verknüpfte Labels. Jede einzelne Stelle wirkt klein, in Summe entsteht aber eine Anwendung, die für Menschen mit Behinderung schwer oder gar nicht nutzbar ist.

Ein zentrales Problem ist der Ressourcenmangel: Spezialisierte Accessibility-Tester sind selten, und die meisten Entwicklerteams haben weder die Zeit noch das tiefe Fachwissen, um jede WCAG-Erfolgskriterium händisch zu prüfen. Barrierefreiheitstests mit KI-Unterstützung setzen genau hier an: Claude kennt die WCAG-Richtlinien im Detail und kann als ständig verfügbarer Sparringspartner fungieren, der Verstöße benennt, bevor ein externes Audit sie teurer aufdeckt.

Wichtig ist von Anfang an die Erwartungshaltung: Claude ersetzt weder automatisierte Scanner noch die Erfahrung echter Nutzer assistiver Technologien. KI-gestützte Barrierefreiheitstests ergänzen beide, indem sie Struktur- und Codeanalyse leisten, Testfälle formulieren und WCAG-Kriterien systematisch abgleichen, in einer Tiefe und Geschwindigkeit, die im Entwickleralltag sonst kaum erreichbar wäre.

2. Was Claude bei Barrierefreiheitstests leisten kann und was nicht

Claude kann HTML-Markup und ARIA-Attribute lesen und daraus ableiten, ob die semantische Struktur den WCAG-Anforderungen entspricht: korrekte Überschriftenhierarchie, sinnvolle Landmark-Regionen, passende Rollen für interaktive Komponenten. Diese statische Analyse ist eine der Stärken von Claude, weil sie auf Textverständnis basiert und keine tatsächliche Ausführung im Browser erfordert.

Was Claude nicht leisten kann, ist die tatsächliche Wahrnehmung mit einem echten Screenreader oder die taktile Erfahrung der Tastaturbedienung durch einen Menschen, der auf diese Bedienung angewiesen ist. Claude kann vorhersagen, wie ein Screenreader ein bestimmtes Markup wahrscheinlich vorliest, aber diese Vorhersage ersetzt keinen tatsächlichen Test mit NVDA, JAWS oder VoiceOver. Ebenso kann Claude keine visuellen Kontrastwerte aus einem Screenshot exakt messen, sondern verlässt sich auf explizit angegebene Farbwerte im Code.

3. Automatisierte Checks vs. manuelle Prüfung: die Rolle von Claude

Automatisierte Scanner wie axe-core oder Lighthouse Accessibility decken zuverlässig etwa dreißig bis vierzig Prozent aller WCAG-Verstöße ab, konzentriert auf mechanisch prüfbare Kriterien wie fehlende Alt-Attribute oder unzureichenden Farbkontrast. Die verbleibenden Verstöße, etwa ob eine Fehlermeldung tatsächlich verständlich ist oder ob eine komplexe Interaktion für Screenreader-Nutzer logisch nachvollziehbar bleibt, erfordern Urteilsvermögen, das automatisierte Tools grundsätzlich nicht liefern können.

Genau in dieser Lücke zwischen mechanischer Prüfung und vollständiger manueller Begutachtung positioniert sich Claude: Es kann Urteilsvermögen simulieren, das über reine Mustererkennung hinausgeht, etwa einschätzen, ob eine Fehlermeldung für einen Screenreader-Nutzer ausreichend Kontext liefert, ohne dabei die Endgültigkeit einer echten Nutzerprüfung zu beanspruchen. Diese Zwischenposition macht Claude zu einem wertvollen ersten Filter, der die Anzahl der Fälle reduziert, die tatsächlich mit echten Screenreadern und echten Nutzern geprüft werden müssen.

4. HTML- und ARIA-Struktur mit Claude analysieren

Der direkteste Einsatz von Claude bei Barrierefreiheitstests ist die statische Analyse von Templates und Komponenten. Ein Prompt, der ein Hyvä-Template übergibt und nach WCAG-Verstößen in der ARIA-Struktur fragt, findet häufig Probleme, die im täglichen Entwicklungsbetrieb übersehen werden: ein <div> mit Klick-Handler statt eines echten <button>-Elements, ein aria-label, das den sichtbaren Text widersprüchlich überschreibt, oder eine Modal-Komponente ohne role="dialog" und ohne Fokus-Trap.

Diese Analyse funktioniert am besten, wenn Claude explizit gebeten wird, jedes gefundene Problem mit der zugehörigen WCAG-Erfolgskriteriumsnummer zu benennen, etwa 4.1.2 Name, Role, Value oder 2.4.6 Headings and Labels. Diese Zuordnung macht die Ergebnisse direkt in ein Ticket-System übertragbar und ermöglicht es dem Team, Prioritäten anhand der WCAG-Konformitätsstufe A, AA oder AAA zu setzen, statt eine unstrukturierte Liste vager Beobachtungen abzuarbeiten.

<!-- WRONG: clickable div, no keyboard access, no semantic role -->
<div class="btn-primary" onclick="submitForm()">Absenden</div>

<!-- WRONG: aria-label contradicts the visible text content -->
<button aria-label="Löschen">Bearbeiten</button>

<!-- RIGHT: native button, keyboard accessible by default, no ARIA needed -->
<button type="submit" class="btn-primary">Absenden</button>

<!-- RIGHT: modal with proper role, labelledby, and focus trap target -->
<div role="dialog" aria-modal="true" aria-labelledby="modal-title" tabindex="-1">
  <h2 id="modal-title">Adresse bearbeiten</h2>
  <!-- Alpine.js x-trap directive handles the focus trap here -->
</div>

5. Testfälle für Tastaturbedienung generieren

Tastaturbedienbarkeit ist eines der am häufigsten übersehenen WCAG-Kriterien, weil die meisten Entwickler und Tester primär mit der Maus arbeiten. Claude kann aus einer Beschreibung der Komponente konkrete Tastatur-Testfälle ableiten: Ist jedes interaktive Element per Tab erreichbar, folgt die Tab-Reihenfolge der visuellen Reihenfolge, lässt sich ein Dropdown mit Pfeiltasten bedienen, schließt Escape ein geöffnetes Modal, ist der Fokus nach dem Schließen wieder auf dem auslösenden Element.

Diese Testfälle lassen sich direkt als manuelle Prüfschritte oder als automatisierte End-to-End-Tests mit Playwright oder Cypress formulieren. Besonders wertvoll ist, dass Claude systematisch alle interaktiven Elemente einer Komponente durchgeht und für jedes einzelne die erwartete Tastaturinteraktion benennt, statt sich auf die offensichtlichsten Fälle wie Buttons und Links zu beschränken und komplexere Widgets wie Tabs oder Accordions zu übersehen.

// Keyboard accessibility test cases generated with Claude
// for a custom accordion component (Playwright)

test('accordion is fully keyboard operable', async ({ page }) => {
  await page.goto('/faq');

  // Tab order should follow visual order
  await page.keyboard.press('Tab');
  await expect(page.locator('[data-accordion-trigger]').first()).toBeFocused();

  // Enter or Space should toggle the panel
  await page.keyboard.press('Enter');
  await expect(page.locator('[data-accordion-panel]').first()).toBeVisible();

  // Escape should not be required to close an accordion panel,
  // but focus must remain on the trigger after toggling
  await expect(page.locator('[data-accordion-trigger]').first()).toBeFocused();

  // Arrow keys should move between accordion triggers (WAI-ARIA pattern)
  await page.keyboard.press('ArrowDown');
  await expect(page.locator('[data-accordion-trigger]').nth(1)).toBeFocused();
});

6. Screenreader-Szenarien mit Claude durchdenken

Ohne Zugriff auf einen echten Screenreader kann Claude dennoch wertvolle Vorarbeit leisten, indem es beschreibt, wie ein bestimmtes Markup wahrscheinlich vorgelesen wird, basierend auf dem dokumentierten Verhalten von NVDA, JAWS und VoiceOver bei Standard-ARIA-Mustern. Diese Vorhersage hilft, offensichtliche Probleme vorab zu identifizieren, etwa eine Bildergalerie, deren Alt-Texte alle identisch "Bild" lauten, oder eine Live-Region, die Änderungen ankündigt, aber kein aria-live-Attribut trägt.

Ein bewährtes Vorgehen ist, Claude zu bitten, den wahrscheinlichen Vorlesetext einer Komponente Schritt für Schritt zu simulieren, so wie ein Screenreader durch die Seite navigieren würde. Diese Simulation ersetzt keinen echten Test, deckt aber häufig auf, dass etwa wichtige Statusänderungen, wie das erfolgreiche Hinzufügen eines Produkts zum Warenkorb, für Screenreader-Nutzer völlig unbemerkt bleiben, weil keine Live-Region existiert, die diese Änderung ankündigt.

<!-- WRONG: cart update happens silently, no announcement for screen reader users -->
<div id="cart-count">3</div>

<!-- RIGHT: aria-live region announces the change automatically -->
<div id="cart-count" aria-live="polite" aria-atomic="true">3</div>

<!-- Simulated Claude screen reader walkthrough for the RIGHT version:
     "Region updated: 3. Warenkorb." spoken automatically after the
     product is added, without the user needing to navigate to the cart. -->

7. WCAG-Kriterien systematisch mit Claude abgleichen

WCAG 2.2 umfasst über achtzig Erfolgskriterien, verteilt auf die Konformitätsstufen A, AA und AAA. Eine vollständige manuelle Prüfung gegen jedes einzelne Kriterium ist zeitaufwendig, besonders wenn ein Team mit den Kriterien noch wenig Erfahrung hat. Claude kann eine Komponente oder Seite systematisch gegen eine priorisierte Teilmenge der Kriterien abgleichen, etwa die Stufe AA, die in den meisten gesetzlichen Anforderungen als Zielniveau gilt.

Der praktische Wert dieses Abgleichs liegt in der Struktur: Statt einer offenen Prüfung "ist das barrierefrei" liefert Claude für jedes geprüfte Kriterium einen klaren Status, erfüllt, nicht erfüllt oder nicht anwendbar, mit kurzer Begründung. Diese strukturierte Ausgabe lässt sich direkt in eine Konformitätsmatrix übertragen, wie sie für Barrierefreiheitserklärungen nach der EU-Richtlinie ohnehin benötigt wird.

{
  "component": "Checkout address form",
  "wcag_level_checked": "AA",
  "results": [
    {
      "criterion": "1.3.1 Info and Relationships",
      "status": "fail",
      "reason": "Street and house number fields share one unlabeled fieldset"
    },
    {
      "criterion": "3.3.1 Error Identification",
      "status": "pass",
      "reason": "Invalid postal code shows inline text error, not color alone"
    },
    {
      "criterion": "2.4.6 Headings and Labels",
      "status": "not_applicable",
      "reason": "Form has no section headings by design"
    }
  ]
}

8. Integration in CI: axe-core plus Claude-Review

Der praktikabelste Workflow kombiniert axe-core als automatisierten Check in jeder CI-Pipeline mit einem periodischen, tiefergehenden Claude-Review für neue oder geänderte Komponenten. axe-core läuft bei jedem Pull Request und blockiert bei eindeutigen, mechanisch prüfbaren Verstößen. Claude wird gezielt bei neuen interaktiven Komponenten hinzugezogen, bei denen mechanische Checks grundsätzlich an ihre Grenzen stoßen, etwa bei einem neuen Custom-Dropdown oder einem mehrstufigen Formular.

Diese zweistufige Pipeline verhindert, dass Barrierefreiheit nur einmal jährlich im Rahmen eines externen Audits geprüft wird, und verteilt die Prüfung stattdessen kontinuierlich über den Entwicklungsprozess. Das Ergebnis ist eine Codebasis, in der neue Verstöße früh und günstig behoben werden, statt sich über Monate anzusammeln und am Ende ein kostspieliges Nacharbeiten zu erfordern.

# CI pipeline step: automated axe-core scan on every pull request
npx @axe-core/cli http://localhost:8080/checkout --exit

# Separate, less frequent step: Claude review for new interactive components
claude -p "Review app/design/frontend/Mironsoft/default/Magento_Checkout/
templates/form/element/dropdown.phtml against WCAG 2.2 Level AA.
List each violated criterion with its number and a one-sentence reason." \
  --file app/design/frontend/Mironsoft/default/Magento_Checkout/templates/form/element/dropdown.phtml

9. Grenzen und Vergleich: automatisiert, KI-gestützt, manuell

Claude kann keine echte Bildschirmlese-Erfahrung ersetzen. Ob eine Ansage in der Praxis tatsächlich verwirrend klingt oder eine Interaktion sich unnatürlich anfühlt, lässt sich letztlich nur durch Tests mit echten Nutzern assistiver Technologien beantworten, idealerweise mit Menschen, die diese Technologien im Alltag verwenden. Auch bei komplexen visuellen Aspekten wie tatsächlich gerenderten Kontrastwerten nach CSS-Kaskade und Theme-Overrides bleibt Claude auf die im Code sichtbaren Werte beschränkt.

Die Tabelle oben zeigt deutlich: Keiner der drei Ansätze allein erreicht eine verlässlich hohe Abdeckung. Erst die Kombination aus automatisierten Checks für mechanisch prüfbare Kriterien, Claude für schnelle, breite Struktur- und Codeanalyse, und echter manueller Prüfung für die verbleibenden Urteils-Kriterien liefert eine Barrierefreiheitsprüfung, der man tatsächlich vertrauen kann.

10. Zusammenfassung

Barrierefreiheitstests mit KI-Unterstützung schließen die Lücke zwischen mechanischen Scannern wie axe-core, die nur einen Teil der WCAG-Kriterien abdecken, und einer vollständigen manuellen Prüfung, für die den meisten Teams die Zeit fehlt. Claude analysiert ARIA-Struktur, generiert konkrete Tastatur-Testfälle, simuliert Screenreader-Vorlesetext und gleicht Komponenten systematisch gegen priorisierte WCAG-Kriterien ab, mit klarer Zuordnung zu Erfolgskriteriumsnummern.

Entscheidend bleibt, Claude als Ergänzung statt als Ersatz zu verstehen: Automatisierte Tools decken mechanisch prüfbare Kriterien zuverlässig ab, Claude beschleunigt die urteilsbasierte Analyse und liefert strukturierte Zwischenergebnisse, echte Nutzer assistiver Technologien liefern die finale Bestätigung. Wer diese drei Ebenen in die CI-Pipeline integriert statt Barrierefreiheit nur einmal jährlich zu prüfen, reduziert nachträgliche Korrekturen erheblich.

11. FAQ: Barrierefreiheitstests mit KI-Unterstützung