Welche WCAG-Aufgaben man mit TypeScript und Sprachmodellen lösen kann

Der WCAG-Katalog ist gleichzeitig Leitfaden und Stolperstein: Viele Anforderungen lassen sich sehr gut automatisiert prüfen, andere sind bewusst so formuliert, dass sie menschliches Urteil benötigen. Aus meiner Erfahrung: Mit TypeScript für stabile, wiederholbare Checks und Sprachmodellen für semantische Bewertung bekommt man heute eine Kombination, die einen großen Teil der täglichen Accessibility-Arbeit spürbar beschleunigt.

Ein pragmatisches Modell: Drei Klassen von WCAG-Aufgaben

In der Praxis lohnt es sich, WCAG-Aufgaben in drei Klassen zu teilen. Das ist keine offizielle WCAG-Kategorisierung, aber sehr hilfreich für Tooling und Projektplanung:

• Vollautomatisierbar: Die Regel ist aus DOM, Styles oder Laufzeitverhalten eindeutig ableitbar.
• Teilautomatisierbar: Das Tool findet Auffälligkeiten, ein Mensch entscheidet über Kontext und Absicht.
• Semantisch: Qualität, Verständlichkeit oder Zweck müssen bewertet werden – hier helfen Sprachmodelle.

1. Vollautomatisierbar mit TypeScript

TypeScript ist ideal, weil du damit browsernahe Prüfungen mit Playwright oder Puppeteer, DOM-Analysen mit jsdom, CSS-Auswertungen und CI-Integrationen sehr sauber bauen kannst. Folgende WCAG-nahe Aufgaben lassen sich zuverlässig automatisieren:

Kontrastmessung (Text/Icons)

Kontrast ist eine klassische Regel, die sich gut automatisieren lässt, sofern Vorder- und Hintergrundfarbe bestimmt werden können. Die Herausforderung ist weniger die Mathematik, sondern die Ermittlung der tatsächlich gerenderten Farben bei Overlays, Transparenzen oder Hintergrundbildern. Trotzdem liefert ein automatisierter Check für die meisten UI-Elemente schnell wertvolle Trefferlisten.

Form-Labels und programmatische Namen

Für Inputs, Buttons, Links und Controls kann man systematisch prüfen: Label vorhanden, aria-label sinnvoll gesetzt, aria-labelledby referenziert gültige IDs, und ob der accessible name leer ist. Das ist für WCAG sehr relevant, aber gleichzeitig hervorragend aus DOM/ARIA ableitbar.

Semantik und Struktur

Viele Struktur-Checks sind deterministisch: genau eine Hauptüberschrift, Überschriftenhierarchie ohne Sprünge, Landmarks vorhanden (header, nav, main, footer), korrekte Listensemantik, Tabellenheader korrekt markiert.

Tastaturfokus und Fokusfallen

Mit Playwright lassen sich Tab-Sequenzen automatisiert ablaufen, Fokusindikatoren prüfen (sichtbar oder effektiv unsichtbar), und es lassen sich Fokusfallen in Dialogen erkennen (Tab bleibt hängen, Escape schließt nicht, Fokus kehrt nicht zurück).

// Beispielidee (gekürzt): Playwright + axe-core in TypeScript
// Ziel: Automatisch auffällige WCAG-Probleme pro Seite sammeln und als Report ausgeben

import { chromium } from "playwright";
import AxeBuilder from "@axe-core/playwright";

async function run(url: string) {
  const browser = await chromium.launch();
  const page = await browser.newPage();
  await page.goto(url, { waitUntil: "networkidle" });

  const results = await new AxeBuilder({ page })
    .disableRules([]) // optional
    .analyze();

  // results.violations enthält Regeln, Knoten, Hinweise und HTML-Snippets
  console.log(JSON.stringify(results.violations, null, 2));

  await browser.close();
}

run("https://example.com");

Solche Reports sind in CI besonders effektiv: jede Pull-Request bekommt sofort Feedback zu regressiven Problemen. Das ersetzt kein Accessibility-Audit, reduziert aber die Anzahl wiederkehrender Basics enorm.

2. Teilautomatisierbar: TypeScript findet Kandidaten, Menschen entscheiden

Viele WCAG-Punkte sind technisch prüfbar, aber nur im Kontext bewertbar. Hier ist die produktive Strategie: Tooling erzeugt eine Liste von Kandidaten mit Begründung, ein Reviewer bestätigt oder verwirft.

• Alternativtexte: Ob sie vorhanden sind, ist automatisierbar. Ob der Text korrekt und zweckmäßig ist, nicht vollständig.
• Linktexte: Das Tool erkennt generische Texte wie „hier“ oder „mehr“. Ob es im Kontext passt, braucht eine Blickprüfung.
• Fehlermeldungen: DOM-Checks finden Fehlerzustände. Ob die Meldungen hilfreich und eindeutig sind, ist semantisch.
• Heading-Struktur: Technisch prüfbar, aber ob die Gliederung inhaltlich sinnvoll ist, bleibt teilweise subjektiv.

3. Wo Sprachmodelle sinnvoll helfen (und wo nicht)

Sprachmodelle sind keine WCAG-Automaten. Ihr Nutzen entsteht dort, wo Text, Bedeutung oder Absicht bewertet werden muss. In einem guten Setup entscheidet das Modell nicht "besteht oder nicht besteht", sondern liefert Vorschläge, Begründungen, Alternativen und konsistente Formulierungen für Redaktion und Development.

Alt-Text-Qualität und Zweckorientierung

Ein Modell kann vorhandene Alt-Texte nach Mustern klassifizieren: zu lang, redundant, "Bild von", unkonkret. Es kann bessere Vorschläge machen, abgestimmt auf den Kontext wie umliegenden Text, Button-Labels oder Seitenabschnitt. Ohne Bildverständnis kann ein reines Textmodell nur begrenzt helfen, ist aber trotzdem sehr effektiv bei redaktioneller Qualität.

Formulierungen für Labels, Hilfetexte und Fehlermeldungen

Gute Labels und Anleitungen sind ein großer Hebel für Barrierefreiheit. Ein Modell kann aus technischen Feldnamen (z.B. customerAddressLine2) bessere, nutzerorientierte Labels und Validierungsfeedback formulieren. Kombiniert mit TypeScript kannst du direkt Vorschläge in Tickets, Pull-Requests oder Content-Systeme schreiben lassen.

Lesbarkeit und Vereinfachung von Texten

Anforderungen rund um Verständlichkeit, klare Sprache und konsistente Begriffe lassen sich nicht rein mechanisch prüfen. Sprachmodelle können hier vereinfachen, zusammenfassen, Varianten liefern und auf Fachjargon hinweisen. Das ist kein "WCAG automatisch bestanden", aber ein massiver Produktivitätsgewinn in der Content-Pipeline.

Navigation, Orientierung und Erwartungskonformität

Ob eine Navigation „konsistent“ ist, ob ein Seitenaufbau erwartungskonform wirkt oder ob ein Prozessschritt logisch benannt ist, hängt stark am Inhalt. Ein Sprachmodell kann hier heuristisch prüfen, Inkonsistenzen markieren und Alternativen vorschlagen. Das ersetzt kein Nutzertesting, ist aber eine gute Vorprüfung.

// Beispielidee (Prompt-Strategie):
// TypeScript sammelt Kandidaten (Linktexte, Alt-Texte, Fehlermeldungen),
// das Sprachmodell liefert Vorschläge + kurze Begründung.
// Ergebnis: Review-Liste, die ein Mensch nur noch abnicken/ändern muss.

/*
Eingabe pro Kandidat:
- Typ: "link" | "alt" | "errorText" | "label"
- Text: "Mehr"
- Kontext: "Abschnitt: Zahlungsarten. Zielseite: Versandkosten"
- Regeln: "Linktext soll Ziel/Zweck verständlich machen"
Ausgabe:
- Bewertung: "auffällig"
- Problem: "zu generisch"
- Vorschlag: "Versandkosten und Lieferzeiten anzeigen"
- Hinweis: "im gleichen Menü existiert bereits 'Lieferzeiten', konsistent bleiben"
*/

Ein umsetzbarer Workflow für Teams

In Projekten hat sich eine Pipeline bewährt, die TypeScript und Sprachmodelle klar trennt:

1. Crawling und Messung mit TypeScript: Seiten erfassen, DOM und Styles extrahieren, automatische Regeln ausführen.
2. Kandidatenliste erstellen: Alles, was nicht eindeutig ist, als "Review erforderlich" markieren.
3. Semantik-Vorschläge vom Sprachmodell: Für Kandidaten Texte verbessern, Alternativen liefern, kurz begründen.
4. Review und Freigabe durch Menschen: Entscheidungen treffen, weil Verantwortung und Kontext nicht delegierbar sind.
5. Regression verhindern in der CI: Die automatisierbaren Regeln als Gate in Pull-Requests laufen lassen.

Grenzen und Risiken, die man ernst nehmen sollte

• Sprachmodelle halluzinieren: Aussagen über Konformität müssen prüfbar sein. Darum Vorschläge statt Urteile.
• Kontext ist entscheidend: Ohne UI- und Domänenwissen sind Empfehlungen oft formal korrekt, aber praktisch falsch.
• Visuelle und dynamische Effekte: Manche Probleme erkennt man nur mit echten Interaktionen und echten Assistive-Tech-Tests.
• Datenschutz: Inhalte wie Formulare, Kundendaten oder interne Texte dürfen nicht ungepüft in externe Modelle wandern.

Fazit

TypeScript löst die harten, deterministischen Teile: Struktur, ARIA und Labels, Kontrastmessung, Tastaturtests und CI-Regression. Sprachmodelle sind dort stark, wo WCAG in Richtung Verständlichkeit, Zweck und Textqualität geht – Alt-Texte, Linktexte, Fehlermeldungen, Hilfetexte und Konsistenz. Zusammen ergibt das ein Setup, das Accessibility nicht automatisch erledigt, aber den Anteil repetitiver Arbeit drastisch reduziert und Reviews deutlich schneller macht.