メニュー
Prüft eine einzelne Astro-/React-/HTML-Komponente auf typische Barrierefreiheitsprobleme und liefert konkrete Fixes. Nutzen beim a11y-Review einer Komponente. Für WCAG-Patterns siehe accessibility-audit.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
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.
| name | astro-component-a11y-review |
| description | Prüft eine einzelne Astro-/React-/HTML-Komponente auf typische Barrierefreiheitsprobleme und liefert konkrete Fixes. Nutzen beim a11y-Review einer Komponente. Für WCAG-Patterns siehe accessibility-audit. |
Prüft eine konkrete Komponente auf Barrierefreiheitsprobleme und liefert Findings mit Code-Fix. Die WCAG-Patterns selbst stehen im Skill accessibility-audit — hier geht es um das Prüf-Vorgehen und das Finding-Format.
.astro, .tsx, .svelte, HTML-Snippet) soll auf a11y geprüft werden.content-clarity-a11y-check bzw. lighthouse-axe-result-explainer.Pro interaktivem/strukturellem Block prüfen:
<button>, <a>, <nav>, <label> statt <div>/<span>).div mit onclick ohne Rolle + Key-Handler + tabindex.:focus-visible-Style vorhanden, kein outline:none ohne Ersatz.aria-label; Inputs haben <label>.aria-usage-review).alt bzw. alt="" wenn dekorativ (siehe alt-text-generator).Finding-Liste, je Finding:
<button> statt <div role="button"> — bringt Fokus, Enter/Space und Rolle gratis.div mit onclick ist unsichtbar für Tastatur und Screenreader.aria-label ist für Screenreader leer.placeholder ersetzt kein <label>.aria-label überschreibt sichtbaren Text — nicht bei Elementen mit lesbarem Inhalt setzen.