accessibility

Überblick über die Accessibility-Skill

Was die Accessibility-Skill macht

Die Accessibility-Skill hilft dir dabei, barrierefreie UI nach WCAG 2.2 Level AA zu entwerfen, umzusetzen und zu prüfen. Ihr Ziel ist es, Produktabsicht in konkrete semantische Entscheidungen zu übersetzen: native Elemente, ARIA-Rollen, Labels, Hinweise, Fokusverhalten und plattformspezifische Accessibility-Eigenschaften für Web, iOS und Android.

Wer diese Accessibility-Skill installieren sollte

Diese Accessibility-Skill ist ideal für Frontend-Engineers, Design-System-Teams, UX-Auditoren und Product Designer, die umsetzbare Implementierungs­hinweise brauchen statt einer generischen Accessibility-Checkliste. Besonders nützlich ist sie, wenn du Accessibility im Rahmen einer UX-Audit-Arbeit machst und von „dieser Flow wirkt riskant“ zu konkreten Maßnahmen kommen musst.

Welche Aufgabe sie dir hilft zu erledigen

Die eigentliche Aufgabe besteht nicht nur darin, „alles konform zu machen“. Es geht darum, ein Component oder einen Flow korrekt auf den Accessibility Tree abzubilden, damit Nutzer assistiver Technologien die richtige Rolle, den richtigen Namen, Zustand, die richtige Reihenfolge und das richtige Interaktionsmodell erhalten. Die Skill legt den Schwerpunkt auf semantische Zuordnung, Fokusmanagement, Beschriftung und die POUR-Prinzipien statt auf allgemeine Policy-Zusammenfassungen.

Warum diese Skill besser ist als ein normaler Prompt

Ein normaler Prompt liefert oft vage Accessibility-Ratschläge. Diese Skill ist hilfreicher, wenn du strukturierte Begründungen brauchst, etwa: zuerst die Component-Rolle identifizieren, native Semantik bevorzugen und dann Labels, Zustände, Tastaturverhalten und Fokusbehandlung festlegen. Das macht die Accessibility-Nutzung deutlich handlungsorientierter für Implementierungsreviews und Audits.

So nutzt du die Accessibility-Skill

Installationskontext und was du zuerst lesen solltest

Installiere die Skill über deinen Skills-Workflow und öffne dann zuerst skills/accessibility/SKILL.md. In dieser Skill gibt es keine zusätzlichen Skripte oder Referenzdateien, deshalb steckt fast die gesamte nützliche Anleitung in genau diesem einen Dokument. Lies diese Abschnitte in dieser Reihenfolge:

1. When to Use
2. Core Concepts
3. How It Works
4. den Abschnitt zur Identifikation der Component-Rolle

Das ist eine leichtgewichtige Accessibility-Installation: wenig Einrichtungsaufwand, aber du solltest erwarten, dass du den fehlenden Produktkontext selbst lieferst.

Welche Eingaben die Accessibility-Skill braucht

Die Accessibility-Skill funktioniert am besten, wenn du Folgendes mitgibst:

• Plattform: Web, iOS oder Android
• Component oder Flow: Button, Modal, Formular, Tabs, Menü, Karussell usw.
• Nutzerziel: was der Nutzer erreichen will
• aktuelle Implementierung: HTML, JSX, SwiftUI/UIKit, Jetpack Compose/View XML oder Screenshots plus Verhaltensnotizen
• Einschränkungen: Design-System-Vorgaben, Legacy-Markup, Third-Party-Widgets
• Audit-Ziel: WCAG 2.2 AA, Tastaturbedienung, Screen-Reader-Verhalten, Fokusreihenfolge, Touch-Target-Größe oder Probleme mit Name/Zustand

Schwache Eingabe: „Mach das barrierefrei.“
Starke Eingabe: „Prüfe dieses React-Modal auf WCAG 2.2 AA. Bewerte semantische Rolle, Accessible Name, Fokusfalle, Escape-Verhalten, initialen Fokus, Rückgabe des Fokus und die Screen-Reader-Ausgabe. Schlage korrigiertes JSX vor.“

So machst du aus einem groben Ziel einen starken Prompt

Für eine bessere Nutzung der Accessibility-Skill kannst du eine Prompt-Struktur wie diese verwenden:

• Identifiziere die UI-Rolle und prüfe, ob ein natives Element das aktuelle ersetzen sollte.
• Beschreibe den erwarteten Accessibility Tree.
• Liste die erforderlichen Informationen zu Label, Rolle, Zustand, Wert und Hinweis auf.
• Definiere Tastatur- und Fokusverhalten.
• Markiere WCAG-2.2-AA-Risiken.
• Gib korrigierten Code plus eine kurze Audit-Zusammenfassung aus.

Beispiel:
„Nutze die Accessibility-Skill, um dieses Custom Dropdown im Web zu prüfen. Entscheide zuerst, ob es ein natives select, ein Button+Listbox-Pattern oder ein anderes Pattern sein sollte. Liefere dann das erwartete ARIA, die Tastaturinteraktionen, die Fokusbewegung, Anforderungen an sichtbaren Fokus, Probleme mit der Touch-Target-Größe und den überarbeiteten Code.“

Empfohlener Workflow für Audits und Implementierung

Bei Accessibility für UX-Audits solltest du auf Flow-Ebene beginnen und dich dann zu den einzelnen Components vorarbeiten:

1. Aufgabe und Fehlerrisiko benennen
2. die tatsächliche Rolle jedes interaktiven Elements bestimmen
3. native semantische Alternativen zuerst prüfen
4. Labels, Namen, Werte und Zustände verifizieren
5. Tastaturreihenfolge und sichtbaren Fokus prüfen
6. Screen-Reader-Ausgaben konzeptionell testen
7. bereinigten Code oder Spezifikationen anfordern

Wenn du implementierst statt zu auditieren, bitte die Skill um Abnahmekriterien, die du an Engineering und QA weitergeben kannst, nicht nur um allgemeine Erklärungstexte.

FAQ zur Accessibility-Skill

Ist diese Accessibility-Skill gut für Einsteiger?

Ja, wenn du bereits grundlegende UI-Entwicklung beherrschst. Die Skill erklärt die zentralen Accessibility-Konzepte verständlich, ist aber kein vollständiger Einsteigerkurs zu WCAG. Sie eignet sich besser als begleitende Implementierungsunterstützung denn als einzige Lernquelle.

Reicht sie für eine Installationsentscheidung zur Accessibility?

Größtenteils ja. Die Skill hat einen klaren Umfang, einen konkreten Workflow und einen praktischen technischen Fokus. Die wichtigste Einschränkung ist die Tiefe des Pakets: Es gibt keine begleitenden Beispiele, Testskripte oder plattformspezifischen Referenzdateien. Wenn du umfangreiche wiederverwendbare Assets willst, wirkt sie eher schlank; wenn du schnelle Orientierung suchst, ist sie leicht einzuführen.

Worin unterscheidet sie sich von einem generischen Accessibility-Prompt?

Der Unterschied liegt im Framing. Diese Accessibility-Anleitung konzentriert sich auf Rollenerkennung, semantische Zuordnung, das Denken im Accessibility Tree, Labels und Fokusmanagement. Generische Prompts springen oft direkt zu ARIA-Attributen, was zu Überengineering oder falschen Mustern führen kann.

Wann sollte ich diese Skill nicht verwenden?

Verlasse dich nicht allein auf diese Accessibility-Skill für rechtliche Freigaben, komplexe Kompatibilitätstests mit assistiven Technologien oder hochspezialisierte Edge Cases nativer Plattformen. Ihre Stärke liegt in Design- und Code-Logik, nicht als Ersatz für manuelles Testen mit echten Geräten, Screen Readern und reinen Tastatur-Workflows.

So verbesserst du die Accessibility-Skill

Gib mehr UI-Kontext, nicht nur Code-Snippets

Der größte Hebel für Qualität ist Kontext. Nenne die Nutzeraufgabe, ob das Steuerelement seinen Zustand ändert oder navigiert, was visuell sichtbar ist und was aktuell kaputtgeht. Accessibility-Empfehlungen hängen vom Verhalten ab, nicht nur vom Markup. Ein div kann mehrere Muster abbilden; die Skill arbeitet besser, wenn du die beabsichtigte Interaktion klar beschreibst.

Bitte erst um Pattern-Auswahl, dann um ARIA

Ein häufiger Fehler ist, ARIA auf das falsche Component zu pressen. Verbessere die Accessibility-Ausgabe, indem du fragst: „Welches Pattern ist das eigentlich?“ Bitte zum Beispiel zuerst um eine Entscheidung zwischen nativem Button, Link, Disclosure, Tab, Dialog oder Listbox, bevor die Korrektur erfolgt. So lassen sich unnötige Custom Widgets oft vermeiden.

Fordere die Ausgabe in implementierungsreifen Abschnitten an

Für eine stärkere Nutzung der Accessibility-Skill bitte um eine strukturierte Antwort:

• gefundenes Problem
• Auswirkung auf Nutzer
• WCAG-2.2-Bedenken
• empfohlene semantische Struktur
• konkrete Codeänderung
• Testschritte

Dieses Format eignet sich besser für die Übergabe an Engineering, QA oder Owner von Design-Systemen als eine einzelne essayartige Antwort.

Iteriere mit echten Fehlerbelegen

Nach dem ersten Durchlauf verbesserst du die Ausgabe der Accessibility-Skill am besten, indem du konkrete Beobachtungen zurückspielst: Screen-Reader-Ansagetext, Tastaturfallen, fehlender sichtbarer Fokus oder Messwerte zur Touch-Target-Größe. Die Skill wird deutlich nützlicher, wenn du sie als Iterationsschleife für UX-Audit-Funde nutzt und nicht als einmaligen Compliance-Check.