メニュー
Findet falsche oder überflüssige ARIA-Nutzung (redundante Roles, kaputte id-Referenzen, ARIA statt nativem Element) und korrigiert sie. Nutzen beim Review von ARIA-Attributen.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | aria-usage-review |
| description | Findet falsche oder überflüssige ARIA-Nutzung (redundante Roles, kaputte id-Referenzen, ARIA statt nativem Element) und korrigiert sie. Nutzen beim Review von ARIA-Attributen. |
Prüft ARIA-Attribute auf Fehler und Redundanz. Erste ARIA-Regel: Kein ARIA ist besser als falsches ARIA.
role, aria-*-Attribute, die geprüft/aufgeräumt werden sollen.role="button" auf <div> → durch <button> ersetzen.role="navigation" auf <nav>, role="list" auf <ul>, role="button" auf <button>.aria-labelledby/aria-describedby/aria-controls-id muss existieren und eindeutig sein.aria-expanded/aria-checked/aria-selected werden bei Interaktion aktualisiert, nicht nur initial gesetzt.aria-hidden="true" auf fokussierbaren Elementen; role widerspricht nativer Semantik.aria-label/aria-labelledby nicht auf Elemente ohne unterstützte Rolle (z.B. <div> ohne Rolle).Je Finding:
aria-labelledby mit fehlender id → Element bleibt unbeschriftet (fällt still aus).role="presentation"/aria-hidden entfernt Kinder aus dem Baum — nicht auf Container mit interaktivem Inhalt.title ist kein zuverlässiger Ersatz für aria-label (auf Touch/Keyboard unsichtbar).Konventionen für die Projekt-Config-Ebene der Coding-Agenten (CLAUDE.md / AGENTS.md / GEMINI.md) — Verhaltens-Baseline, Hierarchie, Token-Effizienz, Multi-Tool-Symlinks. Vor allem: die Entscheidung, was in CLAUDE.md gehört vs. in einen Skill vs. Auto-Memory vs. knowledge-base. Nutzen beim Aufsetzen/Verbessern von Projekt-Config. NICHT für das Schreiben einzelner Skills (→ skill-authoring).
Taxonomie der gängigen Webdesign-Richtungen (Editorial, Corporate, Premium/Luxury, Bold Branding, Minimalismus, Tech, Storytelling, Conversion, Content-First, Brand-First) mit Merkmalen und passenden Branchen/Zielen — um bewusst EINE Richtung zu wählen statt beim Default-Template zu landen. Nutzen bei Designrichtungs-Entscheidungen (Phase 5 in web-design-workflow). NICHT für die konkrete ästhetische Ausführung — dafür frontend-design.
Creative-Director-Prozess für individuelles Webdesign — Strategie → Designsystem → Layout → Inhalte → Code, statt sofort HTML zu erzeugen. Erzwingt Markenanalyse, 3–5 bewusst unterschiedliche Designkonzepte und ein fertiges Designsystem VOR dem ersten Layout. Nutzen bei neuer Website/Relaunch, wenn das Ergebnis nach Marke aussieht, nicht nach Template. NICHT für kleine Einzelseiten/Copy-only (→ landing-and-site-builder) oder reine Ästhetik-Fragen (→ frontend-design).
Formt aus priorisierten Findings einen konkreten, umsetzbaren Maßnahmenplan mit Prioritäts- und Aufwandseinordnung. Nutzen, wenn aus einem Audit ein Umsetzungsplan werden soll.
Übersetzt ein einzelnes technisches Barrierefreiheits-Finding (axe, Lighthouse, Pa11y, manuelle WCAG-Prüfung) in sachliche, verständliche Kundensprache. Nutzen, wenn ein Finding kundengerecht mit Auswirkung, Maßnahme und Priorität erklärt werden soll.
Erstellt aus technischen Audit-Rohdaten (Lighthouse, axe, Pa11y, auditmysite, manuelle Prüfung) eine verständliche Zusammenfassung für Endkunden. Nutzen, wenn ein ganzer Report/Scan kundenfreundlich zusammengefasst werden soll.