ux-audit

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:

1. Begehen, nicht vermuten — jeder Befund braucht Browser-Evidenz (Screenshot, Selektor, Messwert) oder Code-Stelle
2. Profil zuerst, Checks danach — applicability filtert alles
3. 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:

1. 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»
2. Pro Journey und Viewport durchklicken — an jedem Schritt: read_page (Accessibility-Tree), Konsole auf Fehler prüfen, Screenshot wo möglich
3. Tastatur-Durchgang — dieselbe Journey nur mit Tab/Enter/Escape (Basis für A11Y-001/002)
4. 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.

// 1. Meldet sich der Tab überhaupt als sichtbar?
document.visibilityState   // "hidden" -> rAF-getriebene Views (Canvas, Cytoscape,
                           //    D3, WebGL, Karten) mounten evtl. nie
// 2. Hydriert React/Vue? Ein simples Client-Control klicken und Wirkung prüfen:
themeToggle.click(); document.documentElement.className   // ändert sich -> hydriert
// 3. Hängt die Seite in einem Route-Level-Loading/Suspense-Fallback?
document.body.textContent.includes('Lade …')   // + erwartete Container fehlen

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):

1. 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.
2. Lighthouse — echtes Headless-Chrome, rendert unabhängig vom Audit-Browser; deckt Kontrast, zugängliche Namen, Heading-Order, CWV ab.
3. Build/Typecheck (falls Repo vorhanden) — belegt Kompilierbarkeit und, bei SSG, dass jede Route/Sprache serverseitig rendert.
4. 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)

1. Executive Summary (3 Sätze): Lösung X, Y Findings, Z davon critical/high. Release-ready: ja/nein.
2. UX-Score (siehe 6.3) mit Kategorie-Breakdown und Anzahl verifizierter Checks
3. Profil-Snapshot + Applicability-Übersicht
4. Findings-Tabelle (sortiert nach Severity)
5. Detail-Findings (Links auf die Finding-Dateien)
6. 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.
7. 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:

1. Ein Finding = ein Commit (Commit-Message referenziert die Check-ID: fix(a11y): sichtbarer Fokus-Indikator [A11Y-002]) — das macht den Re-Audit-Diff lesbar
2. Nach jedem Fix: Finding-Status auf in-remediation, Checkbox im Plan abhaken
3. accepted-risk ist erlaubt, braucht aber eine Begründung im Finding — stillschweigendes Ignorieren nicht
4. 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.

1. Scope: Alle Checks mit vorherigem Status fail/partial vollständig erneut prüfen (gleiche Journeys, gleiche Viewports, gleiche Verifikationsmodi)
2. Regressionsstichprobe: Zusätzlich 3–5 vorher bestandene Checks erneut prüfen, bevorzugt aus Kategorien, in denen Code angefasst wurde
3. 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
4. Finding-Status pflegen: verifizierte Fixes auf closed, mit Verweis auf Commit + neue Evidenz
5. 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):

1. Ü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
2. Release erstellen (Tag + Release Notes aus dem Delta-Report)
3. 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)

1. «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.
2. «Screenshot der Startseite reicht als Evidenz» — nein. Journeys begehen, Zustände provozieren (Fehler, leere Ergebnisse, langsames Netz), Viewports wechseln.
3. «Kontrast sieht gut aus» — Kontrast wird gemessen (Farbwerte aus dem DOM ziehen, Ratio berechnen), nicht geschätzt.
4. «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.)
5. «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.
6. «Ich schreibe unverified und bin fertig» — der Status ist ein Hand-off, keine Ablage. Ohne Ursache, Teilverifikation und konkrete Prüfanweisung ist er wertlos.
7. «Findings direkt im Chat statt als Dateien» — flüchtig. Ohne audit/-Ordner kein Re-Audit-Vergleich, keine Git-Historie, kein Release-Artefakt.
8. «Re-Audit = alles nochmal» — verschwendet Zeit. Fail/partial + Regressionsstichprobe, fertig.
9. «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

• audit/profile.yaml vollständig, Stopp-Regel geprüft
• Applicability-Report ausgegeben, Katalog-Version notiert
• Hydration-Probe gemacht, bevor Interaktions-Checks bewertet wurden (4.1.1)
• Alle anwendbaren Checks in Severity-Reihenfolge ausgeführt (kein Skip ohne Begründung)
• Kern-Journeys auf allen Profil-Viewports begangen, Tastatur-Durchgang gemacht
• Pro fail/partial ein Finding mit Evidenz (Selektor + Messwert/Screenshot oder Datei:Zeile)
• eCH-0059-Eskalation nur auf A/AA-Aspekte angewandt (AAA nicht eskaliert)
• Kein fail auf einer Interaktion, die gar nicht ausgeführt werden konnte — solche Checks sind unverified mit Ursache + Prüfanweisung
• Jeder unverified-Check im Report-Abschnitt «Vorbehalte», Score mit «X/Y verifiziert» ausgewiesen
• Report mit UX-Score + Remediation-Plan in Wellen erzeugt

Phase C

• Alle fail/partial/unverified-Checks re-verifiziert, Regressionsstichprobe gezogen
• Delta-Report mit Score vorher/nachher (inkl. Anzahl verifizierter Checks)
• Finding-Status aktualisiert (closed mit Commit-Referenz)
• Verbliebene unverified erneut als Vorbehalt ausgewiesen — nicht stillschweigend zu pass befördert

Phase D

• User-Bestätigung vor Push/Release eingeholt
• CHANGELOG + Version-Bump + Release Notes
• Offene Findings als Issues übertragen

---

Versionierung des Check-Katalogs

Wenn neue Best Practices auftauchen (WCAG-Updates, neue CWV-Metriken):

1. Neue .md unter checks/ mit nächster ID, applies_when und evidence_required mit Sorgfalt befüllen
2. MANIFEST.txt und CHANGELOG aktualisieren
3. Bestehende Audits bleiben gültig; beim nächsten Re-Audit gilt der neue Katalog
4. 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.»