| name | ux-audit |
| description | Reproduzierbares UX-Audit von Online-Lösungen (Websites, Web-Apps, Dashboards) gegen einen versionierten Best-Practice-Katalog (Nielsen-Heuristiken, WCAG 2.2 AA, Core Web Vitals) — mit Live-Browser-Begehung UND Code-Analyse, gefolgt von Remediation-Plan, Re-Audit und GitHub-Release. Verwende diesen Skill wenn der User (1) ein UX-, Usability- oder Accessibility-Audit einer Website oder Web-App will, (2) fragt «ist meine App benutzerfreundlich / barrierefrei / WCAG-konform / schnell genug», (3) Verbesserungsvorschläge oder einen Umsetzungsplan für ein Frontend möchte, (4) Begriffe wie «UX-Audit», «Usability-Test», «Barrierefreiheit», «eCH-0059», «Heuristik-Evaluation», «Lighthouse», «Core Web Vitals» erwähnt, (5) nach einem Re-Audit oder Vorher-Nachher-Vergleich nach UX-Fixes fragt, (6) UX-Findings dokumentieren oder abarbeiten will, oder (7) allgemein sagt «schau dir mal die Seite an», «was würdest du am UI verbessern?», «ist das gut bedienbar?». Auch bei Redesign-Vorhaben und vor jedem Release einer Web-Lösung diesen Skill anwenden. |
UX Audit — Standardisiertes Audit-Vorgehen für Online-Lösungen
Dieser Skill kodiert ein reproduzierbares UX-Audit-Verfahren für Websites, Web-Apps und Dashboards gegen den versionierten Check-Katalog in checks/ (~26 Checks in drei Kategorien: Usability, Accessibility, Performance). Ziel: dieselbe Methodik auf jede Online-Lösung im Portfolio anwenden, ohne dass der Auditor (oder Claude) die Kriterien jedes Mal neu erfindet — und den kompletten Lebenszyklus abdecken: Audit → Plan → Umsetzung → Re-Audit → Release.
Das Mantra in drei Zeilen:
- Begehen, nicht vermuten — jeder Befund braucht Browser-Evidenz (Screenshot, Selektor, Messwert) oder Code-Stelle
- Profil zuerst, Checks danach — applicability filtert alles
- Severity ohne Mitleid —
critical blockiert den Release, Punkt
Lebenszyklus-Übersicht
Phase A — AUDIT Schritte 1-6: Profil → Katalog → Filter → Checks → Findings → Report+Plan
Phase B — REMEDIATION Findings nach Plan abarbeiten (ein Finding = ein Commit)
Phase C — RE-AUDIT Fehlgeschlagene Checks erneut prüfen, Delta-Report, Score-Vergleich
Phase D — RELEASE Dokumentation nach GitHub, CHANGELOG, Version-Bump, Release
Jede Phase ist einzeln aufrufbar («mach den Re-Audit» springt direkt zu Phase C, sofern audit/ existiert). Abweichungen vom Vorgehen sind möglich, müssen aber im Audit-Report dokumentiert werden.
Phase A — Audit
Schritt 1: Profil laden oder erstellen
Ziel: Den Kontext der Lösung erfassen, damit nachfolgende Schritte die richtigen Checks filtern können. Das Profil lebt dateibasiert im auditierten Repo unter audit/profile.yaml. Existiert es nicht, wird es jetzt erstellt — Werte aus dem Repo/der URL ableiten wo möglich, den User nur für nicht ableitbare Felder fragen.
1.1 Pflichtfelder
| Feld | Werte | Verwendung im Audit |
|---|
name | Kurzname der Lösung | Dateinamen, Report-Titel |
solution_url | https://… / none | filtert Browser-Checks; none = nur Code-Analyse |
repo_path | lokaler Pfad / none | filtert Code-Checks; none = nur Browser-Audit |
app_type | website / web-app / dashboard | Gewichtung der Journeys |
target_audience | public / internal / expert | Strenge bei Sprache & Hilfe |
languages | Liste, z.B. [de] | Mehrsprachigkeits- und lang-Checks |
interaction | read-only / forms / transactional | filtert Formular- & Fehlerpräventions-Checks |
compliance | none / eCH-0059 | öffentliche Hand ⇒ A11Y-Severity eine Stufe strenger |
viewports | Subset von [mobile, tablet, desktop] | Responsive-Begehung |
baseline_report | Pfad / none | none = Erst-Audit; sonst Re-Audit-Vergleichsbasis |
Stopp-Regel: Sind solution_url UND repo_path beide none, wird der Audit gestoppt — es gibt nichts zu prüfen. Fehlt nur eines, läuft der Audit im reduzierten Modus und der Report vermerkt das prominent («Code-Analyse nicht möglich, Repo nicht verfügbar»).
1.2 Verzeichnisstruktur im Ziel-Repo
Der Audit legt (falls nicht vorhanden) diese Struktur an:
<ziel-repo>/audit/
├── profile.yaml # Schritt 1
├── findings/ # Schritt 5 — eine Datei pro Finding
│ └── 2026-07-13-A11Y-005.md
├── screenshots/ # Browser-Evidenz
├── remediation-plan.md # Schritt 6
└── reports/
├── 2026-07-13-audit.md
└── 2026-07-27-re-audit.md
Alles ist versioniert — der Re-Audit-Vergleich läuft über diese Dateien und die Git-Historie, kein externer Tracker nötig.
Schritt 2: Check-Katalog laden
Ziel: Den vollständigen Katalog (checks/*.md) parsen und nach category + severity indizieren. checks/MANIFEST.txt listet alle Checks mit einer Zeile Metadaten — zuerst lesen, dann nur die anwendbaren Check-Dateien vollständig laden.
2.1 Drei Kategorien
| Kategorie | Quelle | Checks |
|---|
USE | Nielsen-Heuristiken, adaptiert für Web-Lösungen | 10 |
A11Y | WCAG 2.2 AA, eCH-0059 | 10 |
PERF | Core Web Vitals, wahrgenommene Performance | 6 |
2.2 Severity-Stufen
| Stufe | Bedeutung | Konsequenz |
|---|
critical | Nutzergruppe komplett ausgeschlossen oder Kernaufgabe unlösbar | Blockiert Release. Muss vor Go-Live gefixt sein. |
high | Signifikante Hürde für viele Nutzer oder Compliance-Risiko | Im laufenden Sprint fixen. |
medium | Best-Practice-Verletzung, spürbare Reibung | Im nächsten Sprint planen. |
low | Polish, Feinschliff | Backlog. |
eCH-0059-Eskalation (differenziert nach WCAG-Level). eCH-0059 verpflichtet die öffentliche Hand auf WCAG 2.1 Level AA. Deshalb wird bei compliance: eCH-0059 ein A11Y-Check eine Stufe strenger bewertet (medium→high, high→critical) — aber nur, wenn der verletzte Aspekt auf Level A oder AA liegt (Feld wcag_level im Check). Ein Check, dessen Anforderung nur aus Level AAA stammt, wird nicht eskaliert — AAA ist über die gesetzliche Pflicht hinaus wünschenswert, aber kein Konformitätskriterium.
Checks mit gemischtem Level (wcag_level: A/AAA, z.B. A11Y-009) eskalieren nur, wenn der tatsächlich beobachtete Verstoss den A/AA-Anteil trifft. Der Check dokumentiert in seiner eCH-0059-Eskalation-Sektion, wie zu differenzieren ist. Das verhindert, dass eine pauschale Regel Findings härter blockiert, als die Rechtslage es verlangt.
2.3 Check-Schema
Jeder Check ist eine eigenständige Markdown-Datei:
---
id: A11Y-005
title: "Textkontrast mindestens 4.5:1"
category: A11Y
severity: high
applies_when: 'always'
wcag_ref: "1.4.3"
wcag_level: AA # nur A11Y: steuert die eCH-0059-Eskalation (A/AA eskaliert, AAA nicht)
evidence_required: 2
---
# Body mit Description, Verification (pro Modus), Pass Criteria, Remediation
Schritt 3: Applicability-Filter
Ziel: Aus dem Katalog nur die Checks auswählen, die für das Profil relevant sind. Ohne Filter überfluten irrelevante Findings den Report (z.B. Formular-Checks für eine read-only-Informationsseite).
3.1 applies_when-Auswertung
Boolean-Ausdruck gegen die Profil-Felder, gleiche Syntax wie bei mcp-audit: ==, !=, .includes(...), and / or, always. Beispiele:
| Klausel | Effekt |
|---|
always | Check läuft immer |
interaction != "read-only" | nur bei Formularen/Transaktionen |
solution_url != "none" | nur wenn Live-Begehung möglich |
languages.includes("de") and languages.includes("fr") | nur bei Mehrsprachigkeit |
3.2 Applicability-Report (vor Audit-Start)
Bevor der eigentliche Audit beginnt, diese Übersicht ausgeben:
=== Audit applicability for zuerich-schulen-dashboard ===
Profile: web-app, public audience, de, forms, eCH-0059,
URL: https://…, Repo: lokal verfügbar
Applicable checks: 24 / 26
USE: 9/10 (USE-007 Shortcuts: nur für expert audience)
A11Y: 10/10 (eCH-0059 ⇒ Severity-Eskalation aktiv)
PERF: 5/6 (PERF-005 Header: kein Repo-Zugriff auf Server-Config)
Severity breakdown: critical: 3 high: 12 medium: 7 low: 2
Nicht anwendbare Checks erscheinen gar nicht im Report — nicht einmal als «N/A».
Schritt 4: Check-Ausführung
Ziel: Jeden anwendbaren Check methodisch verifizieren. Das Hybrid-Modell kombiniert vier Verifikationsmodi:
| Modus | Wann | Werkzeug |
|---|
browser_test | Verhalten, Rendering, Interaktion | In-App-Browser: Accessibility-Tree (read_page), JS-Messung (javascript_tool: getComputedStyle, getBoundingClientRect), Konsole, Netzwerk, resize_window für Viewports; Screenshot wo möglich |
code_review | Semantik, Struktur, Patterns | Read/Grep im Repo |
automated | Pattern existiert/fehlt | grep nach alt=, aria-, lang=, prefers-reduced-motion … |
tooling | Messwerte und automatisierte A11Y-Prüfung | npx lighthouse <url> --only-categories=performance,accessibility --output=json — läuft in echtem Headless-Chrome, unabhängig vom Audit-Browser. Liefert nicht nur CWV, sondern auch color-contrast, button-name, heading-order, link-name, image-alt. Falls nicht verfügbar: Netzwerk-Panel + manuelle Messung, im Report als «approximiert» kennzeichnen |
Lighthouse ist bei client-gerenderten Apps kein Nice-to-have. Bei app_type: web-app / dashboard früh laufen lassen, nicht erst für PERF: Es rendert die Seite in einem echten Browser und liefert damit oft die einzige belastbare Evidenz, wenn der Audit-Browser die interaktive Ansicht nicht zum Laufen bringt (siehe 4.1.1). Sein A11Y-Teil deckt Kontrast, zugängliche Namen und Heading-Order automatisiert ab — genau die Checks, die sonst manuelle Interaktion bräuchten.
4.1 Browser-Begehungsprotokoll
Die Live-Begehung folgt einem festen Protokoll, damit Evidenz reproduzierbar ist:
- Kern-Journeys definieren (2–4 Stück, aus
app_type ableiten oder User fragen): z.B. «Startseite → Suche → Detailansicht», «Formular ausfüllen → absenden → Bestätigung»
- Pro Journey und Viewport durchklicken — an jedem Schritt:
read_page (Accessibility-Tree), Konsole auf Fehler prüfen, Screenshot wo möglich
- Tastatur-Durchgang — dieselbe Journey nur mit
Tab/Enter/Escape (Basis für A11Y-001/002)
- Messungen — Netzwerk-Panel für Asset-Gewichte, Lighthouse für CWV,
javascript_tool für Kontrast/Zielgrössen/Layout
Evidenz-Fallback (wichtig): Das Screenshot-Werkzeug im Browser-Pane ist nicht immer stabil (Timeouts bei schweren Seiten). Screenshots sind Best-Effort, keine Pflicht. Gleichwertige — oft präzisere — Evidenz liefern der Accessibility-Tree (read_page) und JS-Messungen (javascript_tool): Kontrast via getComputedStyle + WCAG-Formel, Zielgrössen via getBoundingClientRect, Fokus-Stil via document.activeElement, Reflow via scrollWidth-Vergleich. Diese sind reproduzierbar und zitierfähig (Selektor + Messwert). Wenn Screenshots scheitern, im Report unter «Abweichungen» vermerken und mit Tree/JS-Evidenz weiterarbeiten — der Audit ist deswegen nicht unvollständig.
Screenshots (falls erzeugt) mit sprechendem Namen in audit/screenshots/ ablegen (a11y-002-fokus-unsichtbar-suche.png).
4.1.1 Hydration-Probe: erst prüfen, ob die App überhaupt lebt
Vor dem ersten Interaktions-Check klären, ob die Seite im Audit-Browser tatsächlich hydriert ist. Sonst besteht die grösste Gefahr dieses Skills: ein Umgebungslimit als Produktfehler zu melden — «der Tooltip öffnet nicht» zu schreiben, obwohl der Tooltip tadellos ist und nur der Audit-Browser die App nicht mountet.
document.visibilityState
themeToggle.click(); document.documentElement.className
document.body.textContent.includes('Lade …')
Interpretation:
| Beobachtung | Bedeutung | Konsequenz |
|---|
| Ein simples Control reagiert, die Zielansicht aber nicht | Nur dieses Segment hydriert nicht (Suspense/Gating) | Interaktions-Checks dort → unverified, nicht fail |
| Kein einziges Control reagiert | Die ganze Seite hydriert nicht | Interaktions-Checks → unverified; ggf. echter App-Bug — nur dann Finding, wenn auch Lighthouse/echter Browser es zeigt |
| Alles reagiert | Normalbetrieb | Begehung wie gewohnt |
Eskalationsleiter, wenn die interaktive Ansicht nicht mountet (in dieser Reihenfolge, nicht überspringen):
- DOM/CSS-Evidenz — viele Checks brauchen gar keine Interaktion: gelieferte CSS-Regeln (
document.styleSheets), Heading-Ebenen, ARIA-Attribute, lang, Alt-Texte. Struktur-Fixes sind hier vollwertig verifizierbar.
- Lighthouse — echtes Headless-Chrome, rendert unabhängig vom Audit-Browser; deckt Kontrast, zugängliche Namen, Heading-Order, CWV ab.
- Build/Typecheck (falls Repo vorhanden) — belegt Kompilierbarkeit und, bei SSG, dass jede Route/Sprache serverseitig rendert.
- Hand-off an den Menschen — was danach übrig bleibt, wird als
unverified markiert und im Report §Vorbehalte konkret zur manuellen Prüfung übergeben («ⓘ per Tab fokussieren → Enter öffnet, Escape schliesst»).
Eselsbrücke: «Wenn der Patient nicht atmet, ist nicht das Stethoskop kaputt — aber prüf erst, ob du das Stethoskop richtig hältst.»
4.2 Reihenfolge: Severity descending
critical zuerst (Showstopper früh erkennen), dann high, medium, low. Wenn ein critical-Check fehlschlägt, kann der Audit nicht «pass» erhalten — egal wie gut der Rest ausfällt.
4.3 Evidenz-Sammlung pro Check
check_run:
id: A11Y-002
status: pass | fail | partial | unverified | skip
evidence_collected: 3
evidence_required: 2
findings:
- "Fokus-Indikator fehlt auf Such-Button — Screenshot a11y-002-fokus-unsichtbar-suche.png"
- "CSS: outline: none in src/styles/global.css:112 ohne Ersatz"
gaps:
- "Nur Desktop geprüft, Mobile-Tastatur (externe Tastatur am Tablet) offen"
evaluator_notes: |
Der Fokus-Stil wurde global entfernt, vermutlich aus ästhetischen
Gründen. Fix ist trivial, Impact hoch.
Browser-Evidenz referenziert URL + Selektor + (Screenshot oder Messwert), Code-Evidenz Datei + Zeile. Ein gemessener Wert (Kontrast 2.8:1 an button.search-submit) ist gleichwertig zu einem Screenshot — oft sogar stärker, weil objektiv. Ein Finding ohne jede Verankerung ist eine Meinung, kein Befund.
4.4 Pass-Criteria
Ein Check besteht nur dann als pass, wenn alle Pflicht-Pass-Criteria erfüllt sind, mindestens evidence_required Beobachtungen vorliegen und keine gaps der Severity ≥ Check-Severity offen sind. Sonst: partial (50%+ erfüllt) oder fail.
4.5 Der Status unverified
unverified heisst: Die Prüfung konnte nicht durchgeführt werden — nicht, dass sie fehlgeschlagen ist. Reserviert für Umgebungslimits (Zielansicht hydriert nicht, Werkzeug nicht verfügbar, Zugang fehlt), nachdem die Eskalationsleiter aus 4.1.1 abgearbeitet ist.
Regeln, die diesen Status vor Missbrauch schützen:
- Nie als Bequemlichkeits-Ausweg. Erst wenn alle vier Stufen der Leiter erschöpft sind. «Ich habs nicht hingekriegt» ist kein Umgebungslimit.
- Immer mit Ursache + Hand-off. Der Report nennt den technischen Grund (
visibilityState: hidden → Graph mountet nicht) und die konkrete manuelle Prüfanweisung.
- Teilverifikation ausweisen. Meist ist ein Teil belegt: «Struktur/ARIA bestätigt (Lighthouse
button-name: 1), Öffnen-Interaktion offen». Das gehört ins Finding, nicht in den Papierkorb.
- Zählt nicht in den Score (siehe 6.3) — weder als pass noch als fail. Ein unverifizierter Check darf den Score weder schönen noch strafen.
- Erscheint prominent im Report, nie stillschweigend. Ein verschwiegener
unverified-Check ist schlimmer als ein fail: er täuscht Abdeckung vor.
Ein unverified bei einem critical-Check blockiert «release-ready» genauso wie ein offenes fail. Bei Barrierefreiheit gilt: nicht nachgewiesen = nicht erfüllt.
Schritt 5: Finding-Dokumentation
Ziel: Pro fehlgeschlagenem Check (fail/partial) ein strukturiertes Finding nach templates/finding.md erzeugen, abgelegt als audit/findings/<datum>-<check-id>.md.
Kern-Felder: Severity, Status (open/in-remediation/accepted-risk/closed), Observed/Expected Behavior, Evidenz (Screenshot + Selektor und/oder Datei:Zeile), Risiko konkret («Screenreader-Nutzer können die Suche nicht bedienen» — nicht «Accessibility suboptimal»), Remediation mit Code-Diff, Effort S/M/L/XL, Verification-After-Fix.
Schritt 6: Audit-Report + Remediation-Plan
Ziel: Zwei Artefakte produzieren.
6.1 Audit-Report (templates/audit-report.md → audit/reports/<datum>-audit.md)
- Executive Summary (3 Sätze): Lösung X, Y Findings, Z davon critical/high. Release-ready: ja/nein.
- UX-Score (siehe 6.3) mit Kategorie-Breakdown und Anzahl verifizierter Checks
- Profil-Snapshot + Applicability-Übersicht
- Findings-Tabelle (sortiert nach Severity)
- Detail-Findings (Links auf die Finding-Dateien)
- Vorbehalte / offene Bestätigungen — jeder
unverified-Check mit technischer Ursache und konkreter manueller Prüfanweisung. Dieser Abschnitt entfällt nur, wenn es nichts zu berichten gibt — nicht, weil er unangenehm ist.
- Audit-Metadata (Datum, Auditor, Skill-Version, Katalog-Version, geprüfte Journeys & Viewports, Abweichungen vom Vorgehen)
6.2 Remediation-Plan (templates/remediation-plan.md → audit/remediation-plan.md)
Der Plan ist das Arbeitsdokument für Phase B — eine abarbeitbare, geordnete Liste:
- Reihenfolge: erst Severity, dann «Quick Wins zuerst» innerhalb gleicher Severity (critical-S vor critical-L)
- Abhängigkeiten explizit («A11Y-004 Landmarks vor A11Y-002, weil der Fokus-Stil aufs neue Markup muss»)
- Pro Eintrag: Checkbox, Finding-Link, Effort, konkreter erster Schritt
- Gruppiert in Wellen: Welle 1 = alle critical + high-S, Welle 2 = restliche high + medium, Welle 3 = low
6.3 UX-Score
Gewichtete Erfüllungsquote über die anwendbaren Checks — macht den Re-Audit-Fortschritt messbar:
Gewichte: critical=8 high=5 medium=2 low=1
Score = (Σ Gewicht[pass] + 0.5 × Σ Gewicht[partial]) / Σ Gewicht[verifiziert] × 100
wobei Σ Gewicht[verifiziert] = Σ Gewicht[anwendbar] − Σ Gewicht[unverified]
unverified-Checks fliegen aus Zähler und Nenner — sonst würde ein Umgebungslimit als Mangel der Lösung erscheinen (oder, schlimmer, ein 100er-Score Abdeckung vortäuschen, die es nicht gab). Dafür ist ihre Nennung im Report Pflicht: jeder Score wird mit der Anzahl verifizierter Checks ausgewiesen — Score 100 (22/23 Checks verifiziert, 1 unverified), nie nur Score 100.
Zusätzlich pro Kategorie ausweisen. Release-ready = Score ≥ 90 und null offene critical/high und kein unverified auf einem critical-Check.
Der Score ist Kommunikationsmittel für Stakeholder — die Findings bleiben die Wahrheit. Ein Score, der Vorbehalte verschweigt, ist eine Lüge mit Nachkommastelle.
Phase B — Remediation
Der User (oder Claude auf Zuruf) arbeitet den Plan ab. Regeln:
- Ein Finding = ein Commit (Commit-Message referenziert die Check-ID:
fix(a11y): sichtbarer Fokus-Indikator [A11Y-002]) — das macht den Re-Audit-Diff lesbar
- Nach jedem Fix: Finding-Status auf
in-remediation, Checkbox im Plan abhaken
accepted-risk ist erlaubt, braucht aber eine Begründung im Finding — stillschweigendes Ignorieren nicht- Severity-Eskalation während der Umsetzung ist okay; Down-Stufung erfordert Begründung im Finding
Wird Claude mit der Umsetzung beauftragt, arbeitet er den Plan wellenweise ab und stoppt nach jeder Welle für einen Zwischenstand.
Phase C — Re-Audit
Ziel: Verifizieren, dass die Fixes wirken — und nichts kaputtgegangen ist.
- Scope: Alle Checks mit vorherigem Status
fail/partial vollständig erneut prüfen (gleiche Journeys, gleiche Viewports, gleiche Verifikationsmodi)
- Regressionsstichprobe: Zusätzlich 3–5 vorher bestandene Checks erneut prüfen, bevorzugt aus Kategorien, in denen Code angefasst wurde
- Delta-Report (
audit/reports/<datum>-re-audit.md): Score vorher/nachher, pro Finding alt→neu (fail → pass), verbleibende offene Findings, neue Findings aus der Regressionsstichprobe
- Finding-Status pflegen: verifizierte Fixes auf
closed, mit Verweis auf Commit + neue Evidenz
baseline_report im Profil auf den neuen Report zeigen lassen
Ein Re-Audit, der nur die gefixten Checks prüft und keine Regressionsstichprobe zieht, ist unvollständig — UX-Fixes (CSS, Markup-Umbauten) haben notorisch Seiteneffekte.
Phase D — Dokumentation & Release
Nach erfolgreichem Re-Audit (keine offenen critical/high, oder explizit akzeptierte Risiken):
- Übergabe an den
github-repo-Skill mit diesem Paket:
audit/-Ordner committen (Reports, Findings, Plan, Screenshots)- CHANGELOG-Eintrag: Version, Datum, «UX-Audit v: Score X→Y, N Findings behoben» + Liste der Check-IDs
- Version-Bump: minor bei reinen UX-Fixes, major falls Breaking Changes dabei waren
- README ggf. um Audit-Badge/Abschnitt ergänzen
- Release erstellen (Tag + Release Notes aus dem Delta-Report)
- Offene
medium/low-Findings als GitHub-Issues anlegen (Labels ux-audit, severity:medium etc.), damit der Backlog nicht in Markdown-Dateien versauert
Vor Push und Release immer die User-Bestätigung einholen — der Audit-Ordner kann Screenshots mit internen Daten enthalten.
Anti-Patterns (vermeiden)
- «Ich schaue mir die Seite an und schreibe auf, was mir auffällt» — das ist Review, kein Audit. Ohne Katalog keine Reproduzierbarkeit, ohne Profil falsche Prioritäten.
- «Screenshot der Startseite reicht als Evidenz» — nein. Journeys begehen, Zustände provozieren (Fehler, leere Ergebnisse, langsames Netz), Viewports wechseln.
- «Kontrast sieht gut aus» — Kontrast wird gemessen (Farbwerte aus dem DOM ziehen, Ratio berechnen), nicht geschätzt.
- «Der Lighthouse-Score ist 94, also fertig» — Lighthouse deckt PERF und Teile von A11Y ab, aber keine einzige USE-Heuristik. Tooling ergänzt die Begehung, ersetzt sie nicht. (Umgekehrt gilt aber auch: wenn die Begehung am Umgebungslimit scheitert, ist Lighthouse die belastbarste verbleibende Evidenz — siehe 4.1.1.)
- «Der Tooltip öffnet nicht → Finding», obwohl der Audit-Browser die App gar nicht hydriert hat — der teuerste Fehler dieses Skills, weil er einen erfundenen Mangel in ein Ticket giesst und Vertrauen in den ganzen Report zerstört. Immer erst die Hydration-Probe (4.1.1). Ein Befund über Verhalten setzt voraus, dass Verhalten überhaupt stattfinden konnte.
- «Ich schreibe
unverified und bin fertig» — der Status ist ein Hand-off, keine Ablage. Ohne Ursache, Teilverifikation und konkrete Prüfanweisung ist er wertlos.
- «Findings direkt im Chat statt als Dateien» — flüchtig. Ohne
audit/-Ordner kein Re-Audit-Vergleich, keine Git-Historie, kein Release-Artefakt.
- «Re-Audit = alles nochmal» — verschwendet Zeit. Fail/partial + Regressionsstichprobe, fertig.
- «Audit-Report ohne Remediation-Plan» — wertlos. Findings ohne geordneten Fix-Vorschlag werden nicht angegangen.
Eselsbrücken
- Begehung: «Ein UX-Audit vom Sofa aus ist wie eine Wohnungsabnahme per Foto — die klemmende Tür findest du nur, wenn du sie anfasst.»
- Applicability: «Formular-Checks auf einer read-only-Seite sind wie Fahrstuhl-Prüfung im Bungalow.»
- Severity-Disziplin: «
critical heisst: jemand kann die Lösung nicht benutzen. Nicht: mir gefällt das Blau nicht.»
- Evidenz-Pflicht: «Ein Finding ohne Screenshot oder
file:line ist eine Meinung, kein Befund.»
- Hydration-Probe: «Wenn der Patient nicht atmet, ist nicht das Stethoskop kaputt — aber prüf erst, ob du das Stethoskop richtig hältst.»
unverified: «Nicht geprüft ist nicht bestanden — aber auch nicht durchgefallen. Wer das vermischt, produziert Fiktion.»
Qualitätschecklist vor Abschluss
Phase A
Phase C
Phase D
Versionierung des Check-Katalogs
Wenn neue Best Practices auftauchen (WCAG-Updates, neue CWV-Metriken):
- Neue
.md unter checks/ mit nächster ID, applies_when und evidence_required mit Sorgfalt befüllen
MANIFEST.txt und CHANGELOG aktualisieren- Bestehende Audits bleiben gültig; beim nächsten Re-Audit gilt der neue Katalog
- Severity-Änderungen an bestehenden Checks: bei
critical/high immer Re-Audit empfehlen
Eselsbrücke: «Ein neuer Check ist ein neuer Vertrag. Bestehende Audits sind nicht rückwirkend ungültig, aber beim nächsten Audit gilt der neue Katalog.»
