cg-web-accessibility

Ein Button ist ein <button>, ein Link ein <a href>, ein Feld hat ein <label>. Der Skill legt eine Reihenfolge fest — native Semantik, Browserfunktionen, CSS und ARIA nur dort, wo native Semantik nicht reicht — und verbietet ARIA, das ein falsches Element kaschiert.

Ein Accessibility-Widget kann Präferenzen wie größere Schrift oder weniger Bewegung anbieten. Es kann keinen korrekten Alt-Text schreiben, keine Fokusreihenfolge reparieren und keinen Checkout mit Screenreader bedienbar machen. Deshalb behebt Claude immer die Ursachen im Code und behandelt die Toolbar als zusätzliche Ebene.

Ein echter Button auf jeder Seite öffnet einen zugänglichen Dialog: größere Schrift, Textabstand, Zeilenhöhe, Kontrastmodi, hervorgehobene Links, pausierte Animationen, ausgeblendete Bilder, eine lesefreundliche Schrift, ein größerer Cursor, eine Seitenstruktur-Navigation und ein Reset. Präferenzen werden nur lokal gespeichert — kein externer Dienst, kein Tracking, keine personenbezogenen Daten.

Automatische Scans mit axe oder Lighthouse finden einen Teil der Probleme. Der Skill ergänzt einen Tastaturdurchgang, mindestens einen echten Screenreader, einen Mobile-Durchgang und einen Test mit 200 % Textgröße, und prüft jeden Toolbar-Modus gegen den Rest der Seite.

Der Skill stellt klar, dass ein Button in der Ecke kein rechtlicher Status ist — nicht für WCAG, nicht für EN 301 549 und nicht für das BFSG:

Mit nativem HTML lösen, wo es geht, zu ARIA und JavaScript nur greifen, wenn nötig, Präferenzen obendrauf setzen und am Ende mit echter assistiver Technologie prüfen.