robcsaszar/tend

Tend A11y — der Herold

Finde das einzelne Problem mit der höchsten Priorität in Bezug auf Barrierefreiheit, UX oder Tonfall im Markup dieses Repositories, behebe es minimal, verifiziere und lege den Diff zur Überprüfung vor. Ein Problem pro Durchlauf.

0. Konfiguration laden

• Lies .claude/tend/config.yaml. Verwende skills.a11y (Ausnahmeglobs, notes). Dieser Skill hat keine Fähigkeitsmodule – überspringe die Modulprüfung vollständig, es gibt hier keinen Schritt modules: Gating.
• Keine Konfiguration? Führe auf Kernstufe aus: Kernannahmen für SvelteKit + TS, konservativ integrierte Ausnahmen (niemals Lockfiles, CI, .env, Konfiguration berühren). Gib einmal aus: „Führe tend-onboard aus, um zu verfeinern.“ Fahre fort.

1. Triage

PFLICHT LESE: references/scan-core.md

• Lege die Ausnahmemenge fest: die skills.a11y.off-limits aus der Konfiguration plus die integrierten Schranken (niemals Lockfiles, CI-Konfiguration, .env, Projektkonfiguration oder Backend-/API-Routenlogik berühren – dieser Skill ist präsentationsorientiert).
• Lege die Einstiegspunkte fest: die Markup-Dateien dieses Repositories – .svelte-Komponenten, +page.svelte / +layout.svelte-Routen oder andere Vorlagendateien, die der Stack tatsächlich verwendet. Überprüfe skills.a11y.notes auf ein benanntes Komponentenbibliotheksverzeichnis (z. B. src/lib/components/ui) – falls vorhanden, sind dessen Exporte die „Verwende dies statt rohem HTML“-Zielliste für Phase 2.
• Lese 1–2 vorhandene Komponenten vor dem Scannen, um die tatsächlichen Konventionen des Repositories für Komponentenbibliothek und Status-/Ladeanzeige zu lernen – du benötigst das tatsächliche Muster, bevor du eine Abweichung als Verstoß bezeichnen kannst.

Abschlusskriterium: Ausnahmemenge bekannt, Komponentenbibliothekskonvention (falls vorhanden) identifiziert, Einstiegs-Globs identifiziert.

2. Scannen – Prioritätsreihenfolge, stoppe beim ersten echten Treffer

Geordnet von höchstem Wert (am stillsten für Benutzer) zuerst – stoppe beim ersten echten, belegten Treffer:

1. Rohes interaktives HTML, zu dem ein Komponentenbibliotheksäquivalent existiert – ein roher <button>/<a>/<input> neben einer Button/Link/Input-Export anderswo im Repository.
2. Symbolorientierte oder symbol-primäre interaktive Elemente ohne zugänglichen Namen – kein aria-label, kein visuell versteckter Text, kein title-Fallback.
3. <img> ohne alt – ein fehlendes Attribut ist der Verstoß; ein absichtlich leeres alt="" bei einem dekorativen Bild ist keiner.
4. Formulareingaben ohne zugehöriges Label – kein label for=, aria-label oder Komponentenbibliotheks-Label-Prop. Prüfe die gerenderte Anzahl, nicht nur die Vorlage: Eingaben, die innerhalb einer Schleife ({#each} oder Äquivalent) generiert werden, erzeugen zur Laufzeit N anonyme Steuerelemente.
5. role="button" (oder ein bloßes onclick auf einem nicht interaktiven Element) ohne den zugehörigen Tastaturhandler – onkeydown für Eingabe + Leertaste. Native <button> erhält dies kostenlos; dies wird nur bei der Ausweichlösung mit rohem Element ausgelöst.
6. Asynchrones Erfolgs-/Fehler-/Lade-Feedback, das als einfaches, unangekündigtes Element gerendert wird – kein role="alert"/role="status", kein aria-live und kein vorhandenes Komponentenbibliotheks-Banner/Toast-Primitiv, das bereits anderswo im Repository verwendet wird.
7. Eine destruktive Aktion (Löschen/Entfernen/Zurücksetzen) ohne Bestätigungsschritt bevor sie wirksam wird.
8. Tonfallverstöße, geprüft anhand der konfigurationsgesteuerten Erlaubnis-/Verbietungsliste (skills.a11y.notes oder einem Projekt-Tonfall-Dokument, auf das sie verweist). Falls keine repository-spezifische Liste existiert, falle auf generische Standardwerte zurück: ein imperativer Weichmacher wie „Bitte“ vor einer Validierungs-/Fehleranweisung („Bitte geben Sie einen Namen ein“ vs. „Geben Sie einen Namen ein“) oder ein unnötiges Ausrufezeichen in routinemäßigen Bestätigungs-/Anweisungstexten. Scanne sowohl gerenderten Markup-Text als auch String-Literale innerhalb <script>-Blöcke – Text, der einer Variable zugewiesen, an einen Toast-/Alert-Aufruf übergeben oder über .textContent/.innerText gesetzt wird, befindet sich in Script-Blöcken, nicht nur im Markup, und eine reine Markup-Suche übersieht die tatsächlichen Validierungsstrings.

3. Beheben – eine atomare Änderung

Beantworte vor dem Bearbeiten:

1. Ist dies für einen echten Benutzer (Screenreader, Tastaturnutzer oder jemand, der den Tonfall liest) wirklich unklar oder unzugänglich – nicht nur eine stilistische Vorliebe von mir?
2. Betrifft die Korrektur nur Präsentation/Text – keine Logik, kein Backend, keine neue Abhängigkeit?
3. Existiert für dieses Muster bereits ein Komponentenbibliotheksäquivalent? Wenn ja, verwende es statt einer handgestrickten rohen HTML-Korrektur (verpasse nicht role="alert" auf ein rohes <div>, wenn das Repository bereits eine Status-/Banner-Komponente hat, die es trägt).

Basis-Verifikation: Führe das Linting/Typprüfung des Repositories (und die Tests, falls schnell) vor dem Bearbeiten aus – notiere etwaige bereits bestehende Fehler, um sie nicht später falsch zuzuordnen.

Größenbudget: ≤50 geänderte Zeilen für eine Markup-/Struktur-Korrektur, ≤10 Zeilen für eine reine Textkorrektur; eine Komponente oder Seite pro Durchlauf.

Berühre niemals Ausnahmepfade. Falls die tatsächliche Korrektur einen Ausnahmepfad berühren würde, stoppe und berichte stattdessen, warum, anstatt sie anderswo zu erzwingen.

4. Verifizieren & Präsentieren

Führe erneut Linting/Typprüfung (und Tests, falls in Schritt 3 ausgeführt) durch – brich nur ab, wenn deine Änderung einen neuen Fehler einführt; bereits bestehende Fehler sind nicht deine zu beheben. Zeige den Diff. STOPP – nicht committen, keinen PR öffnen.

NIEMALS

• NIEMALS mehr als ein Problem pro Durchlauf markieren oder beheben Stattdessen: Stoppe das Scannen beim ersten echten Treffer, behebe ihn, präsentiere ihn. Warum: Gebündelte A11y-/Text-Diffs sind schwer einzeln zu überprüfen und verbergen, welche spezifische Korrektur eine Regression verursacht hat.

• NIEMALS eine handgestrickte rohe HTML-Korrektur durchführen, wenn ein Komponentenbibliotheksäquivalent bereits existiert Stattdessen: Verwende die eigenen Button/Input/Link/Status-Banner-Komponente des Repositories. Warum: Eine parallele Einmalkorrektur erzeugt ein zweites inkonsistentes Muster, anstatt auf das eine zu konvergieren, auf das der Rest des Repositories bereits setzt – die nächste Prüfung wird es erneut als Abweichung markieren.

• NIEMALS eine Tonfallregel erfinden, die nicht durch skills.a11y.notes oder einen generischen, klar gekennzeichneten Standardwert gestützt wird Stattdessen: Verwende die konfigurationsgesteuerte Erlaubnis-/Verbietungsliste oder gib explizit an, dass du auf ein generisches Standardmuster zurückfällst. Warum: Eine spontan erfundene Regel ist beim nächsten Durchlauf nicht wiederverwendbar oder überprüfbar und kann dem tatsächlichen Hausstil des Repositories widersprechen.

• NIEMALS nur Markup scannen und <script>-Blöcke für Textstrings überspringen Stattdessen: Suche auch nach String-Literalen in <script>-Blöcken – Validierungs- und Feedback-Text wird häufig dort zugewiesen, nicht direkt in die Vorlage geschrieben. Warum: Der tatsächliche benutzersichtige String ist oft eine Variable, die in die Vorlage eingefügt wird; eine reine Markup-Suche trifft auf die Einfügestelle, nicht auf den tatsächlichen anstößigen Text, und meldet nichts zu beheben.

• NIEMALS Ausnahmepfade berühren oder committen/einen PR öffnen Stattdessen: Respektiere skills.a11y.off-limits plus die integrierten Schranken; stoppe nach dem Präsentieren des Diffs. Warum: Die Aufgabe dieses Skills endet mit „verifizierter Diff, bereit zur menschlichen Überprüfung“ – Committen oder Berühren ausgeschlossener Pfade entfernt die Überprüfungsinstanz, von der der gesamte Workflow abhängt.

Dateien

• references/scan-core.md – Kernprüfungen (geladen Phase 1)
• evals/ – ai-forge-eval-assertions