Prüfen, wo die Seite
wirklich läuft
LiveAudit ist ein eingebetteter Accessibility-Inspector: ein Script-Tag auf der eigenen Seite, Befunde direkt am betroffenen Element statt in einem externen Report. Der gemeinsame Regelkern ist veröffentlicht, die Browser-Anbindung entsteht gerade.
{ "rule_id": "images/alt-suspicious", "outcome": "review", "severity": "medium", "message": "Der Alt-Text „foto1.jpg" beschreibt das Bild vermutlich nicht.", "location": { "node": "1843" }, "wcag": ["1.1.1"] }
Stand der Umsetzung (18.09.2026)
Architektur entschieden
Drei Schichten: TypeScript sammelt den DOM, Rust wertet aus, TypeScript zeigt an. Entscheidungen und Grenzen sind im Repository dokumentiert.
Tragfähigkeit belegt
Fünf reale Dokumente von 1.244 bis 723.613 Knoten gemessen. Der Übergang nach WASM kostet 0,5 ms bei 31.000 Knoten — der Engpass liegt woanders.
a11y-core veröffentlicht
Vier Crates auf crates.io: a11y-report, a11y-dom, accname, a11y-rules. Derselbe Regelbestand bedient Build-Zeit, CI und die laufende Seite.
Collector und WASM-Anbindung
Der DOM der laufenden Seite wird einmal in den WASM-Speicher überführt, danach wertet Rust aus. Prototyp gemessen, Produktionsfassung offen.
Inspector-Layer
Rahmen, Marker und Seitenleiste über der Seite — ohne den geprüften Teilbaum zu verändern.
Kontrast, Fokus, Live-Modus
Prüfungen, die Rendering-Daten oder echte Interaktion brauchen: Kontrast, Tabreihenfolge, Zielgrößen, veränderlicher DOM.
Ein Report sagt was.
Die Seite zeigt wo.
Klassische Prüfwerkzeuge erzeugen eine Liste, die neben der Seite liegt. Wer sie abarbeitet, sucht jedes Mal das gemeinte Element. LiveAudit dreht das um: Der Befund sitzt am Element, auf der Seite, im echten Zustand nach allen Skripten und Einbindungen.
Konzept und Entscheidungen →- 01Läuft auf der Seite selbst — kein Nachbau, kein zweiter Renderer
- 02Verändert den geprüften Teilbaum nicht: keine Attribute, keine Inline-Styles
- 03Prüft und repariert nicht — ausdrücklich kein Accessibility-Overlay
- 04Für Entwickelnde gedacht, nicht als Ersatz für manuelle Prüfung
Ein Prozentwert verschleiert,
was man wissen will
FAIL
Automatisch festgestellt. Die Regel konnte das Problem eindeutig belegen — ein alt fehlt, eine ID kommt doppelt vor.
REVIEW
Heuristisch vermutet. Ein Alt-Text ist vorhanden, sieht aber nach einem Dateinamen aus. Braucht menschliche Bestätigung.
PASS
Bestanden. Wird intern geführt, aber standardmäßig nicht angezeigt — sonst geht der eigentliche Befund unter.
UNTESTED
Automatisiert nicht beurteilbar. Erzeugt einen Punkt auf der manuellen Prüfliste statt eines Urteils, das keines ist.
„Lief nicht" ist nicht
„bestanden"
Eine Kontrastprüfung ohne Rendering-Zugriff liest sich in den meisten Werkzeugen wie eine bestandene Prüfung. LiveAudit hält getrennt fest, ob eine Regel überhaupt laufen konnte, und warum nicht.
Derselbe Befund,
egal woher er kommt
{
"rule_id": "images/alt-suspicious",
"outcome": "review",
"severity": "medium",
"message": "Der Alt-Text „foto1.jpg" beschreibt
das Bild vermutlich nicht.",
"location": { "node": "1843" },
"wcag": ["1.1.1"]
}{
"rule_id": "contrast/text",
"not_run": "capability_missing",
"reason": "Host liefert keine Rendering-Werte"
}Dieselben Regelkennungen
vom Build bis in die Seite
Ein Befund heißt im Build, in der CI und im Browser gleich. Das ist der eigentliche Grund für den Rust-Kern — nicht Geschwindigkeit.
- Build-Zeit
astro-post-audit
Liest das erzeugte HTML nach jedem
astro build. Struktur und Semantik, kein Browser. - CI und Crawl
auditmysite
Steuert Chrome fern und nutzt dessen nativen Accessibility-Tree. Zusätzlich Rendering und Interaktion.
- Laufende Seite
LiveAudit
Sitzt in der Seite selbst. Kann Ereignisse real auslösen und veränderlichen DOM beobachten.
Automatisierung endet
an einer klaren Stelle
Diese Bereiche sind nicht zuverlässig automatisierbar. LiveAudit meldet sie als UNTESTED mit einer Prüfliste, statt ein Urteil zu behaupten.
Screenreader-Erfahrung
Ein technisch korrektes Dokument kann sich trotzdem schlecht bedienen lassen.
Inhaltliche Qualität
Ob ein Alt-Text das Bild angemessen beschreibt oder ein Linktext im Kontext trägt, entscheidet ein Mensch.
Lesereihenfolge
Die technische Tabreihenfolge ist bestimmbar. Ob sie inhaltlich sinnvoll ist, nicht.
Komplexe Widgets
ARIA-Syntax ist prüfbar. Ob sich ein Widget für Screenreader sinnvoll verhält, zeigt erst der Test damit.
Nutzbar, auch ohne
das fertige Werkzeug
use a11y_dom::Arena;
use a11y_rules::run;
let report = run(&dokument);
// Gefunden: Bild ohne Alternativtext.
assert!(report.findings.iter()
.any(|f| f.rule_id == "images/alt-missing"));
// Nicht beurteilt: Regeln, für die dieser Host
// keine Rolle und keinen Namen liefert.
assert_eq!(report.summary.rules_not_run, 4);use accname::{name, IdIndex};
// <span id="l">Vorname</span>
// <input aria-labelledby="l">
let ids = IdIndex::build(dokument.root());
assert_eq!(name(feld, &ids).as_deref(), Some("Vorname"));Vier Crates auf crates.io
a11y-report
Befund- und Berichtsmodell. Zwei Achsen: Zustand und Schweregrad.
Cratea11y-dom
Dokumentmodell plus Fähigkeits-Tiers. Regeln laufen über verschiedene Substrate.
Crateaccname
Accessible Name und Rolle nach WAI-ARIA und HTML-AAM. Gegen die Spezifikation geschrieben.
Cratea11y-rules
Die Regeln selbst, generisch über das Dokumentmodell. 13 strukturelle, 4 semantische.
bei 31.000 Knoten
bei 31.000 Knoten
gzip
gemessenen Dokument
Was LiveAudit ist
und was nicht
Ist das ein Accessibility-Overlay?
Nein. Overlay-Anbieter versprechen, eine Seite per JavaScript zu reparieren. LiveAudit prüft und verändert nichts an der Seite — es zeigt Befunde in einer eigenen Schicht darüber an.
Kann ich es heute schon einsetzen?
Noch nicht. Der gemeinsame Regelkern ist als Rust-Crates veröffentlicht und nutzbar; die Browser-Anbindung und die Anzeige entstehen gerade. Der Stand oben zeigt, was fertig ist.
Was unterscheidet es von einer Browser-Erweiterung?
Eine Erweiterung muss jede prüfende Person installieren. LiveAudit bindet der Seitenbetreiber selbst ein — damit funktioniert es auch in einer Vorschau, auf Staging oder in einem Redaktionssystem, ohne dass jemand etwas installiert.
Ersetzt das eine manuelle Prüfung?
Nein, und es tut auch nicht so. Was sich nicht zuverlässig automatisieren lässt, wird als `UNTESTED` ausgewiesen und landet auf einer Prüfliste statt in einer Bestanden-Statistik.
Warum Rust und WASM?
Damit derselbe Regelbestand im Build, in der CI und im Browser läuft und Befunde überall gleich heißen. Die Messung hat gezeigt, dass Geschwindigkeit dafür nicht das Argument ist — die Wiederverwendung ist es.
Derselbe Kern,
andere Oberfläche
Entwicklung offen mitverfolgen
Konzept, Architekturentscheidungen, Messungen und der veröffentlichte Kern liegen öffentlich. MIT-Lizenz.