antislop-human

Anti Slop: Regeln für KI-Codierungs-Agenten. Human-Skill

Teil des Antislop-Systems. Zusammen mit antislop.md (dem Kern) lesen. Dieser Skill vertieft die menschliche Sorge: Die UI muss für Menschen mit unterschiedlichen Augen, Händen und Setups nutzbar bleiben. Kontrast, Tastatur, Fokus, Zustände und die mobilen Details, die Menschen ausschließen.

Wie man diesen Skill nutzt

Zusammen mit antislop.md laden, wenn die Aufgabe UI erstellt oder bearbeitet. Der Kern enthält den Mechanismus (den Zwecktest, die drei Stufen, das Delivery Gate); dieser Skill enthält die Tiefe der menschlichen Seite: die Teile einer UI, die Menschen mit unterschiedlichen Augen, Händen und Setups ausschließen.
Jeder Eintrag hat die gleiche Form: Sagen (das Muster), Warum (wen es ausschließt und warum es sich unfertig anfühlt), Beheben (was stattdessen zu tun ist), mit der zitierten Kernregel als R-XX.
Barrierefreiheit ist keine Checkliste von Extras, die am Ende angehängt werden. Sie ist Teil des Kernversprechens, dass "die UI hält" (C-4). Das Delivery Gate im Kern bleibt das Tor; die "Checkliste Human-Skill" am Ende dieser Datei ist die Ergänzung, die parallel dazu läuft.
Der Kontrastprüfer (Formel + Referenztabelle + Skript) befindet sich in diesem Skill. Verwende ihn für jedes Farbpaar, das du nicht mit dem Auge überprüfen kannst.
Dieser Skill behält nur die mobilen Details, die Menschen ausschließen: Zoomen und die Bildschirmtastatur.

Farbe und Kontrast

Text mit geringem Kontrast

Sagen: hellgrauer Text auf weißem oder fast weißem Hintergrund, dünner Fließtext, gedämpfte Labels, die gewählt wurden, weil sie "elegant" aussehen, aber schwer zu lesen sind.
Warum: es schließt sehbehinderte Benutzer und alle bei hellem Licht aus. Es ist eine visuelle Entscheidung, die ohne Prüfung des Standards getroffen wurde, genau die Art von Standardeinstellung, die der Filter abfangen soll.
Beheben: WCAG-AA-Mindestanforderungen erfüllen (R-25): 4,5:1 für normalen Text, 3:1 für großen Text (18px+). Das Verhältnis berechnen, nicht mit dem Auge schätzen.

Text auf einem Foto oder Farbverlauf

Sagen: weißer Text direkt auf einem Bild oder Farbverlauf, der an einigen Stellen hell ist, nur an einer hellen Stelle überprüft.
Warum: Kontrast ist lokal. Wo das Bild hell ist, fällt der Text unter 4,5:1, selbst wenn der Hero noch "in Ordnung" aussieht. R-25 erfordert das Testen des gesamten Bereichs, den der Text überstreicht, nicht nur eines einzelnen Punktes.
Beheben: einen Schleier oder einen festen Farbblock hinter den Text setzen, dann den schlechtesten Punkt überprüfen, nicht den besten. Wenn irgendein Teil des Textbereichs nicht besteht, ist die Behandlung fehlgeschlagen.

Die Grau-auf-Grau-Halluzination

Sagen: "dunkelgrau auf schwarz" oder "hellgrau auf weiß", das ohne Berechnung als AA bestanden angegeben wird.
Warum: dies ist die häufigste Barrierefreiheitshalluzination. Das Auge überschätzt den Kontrast bei Graupaaren, und Agenten wiederholen die Behauptung, weil sie plausibel klingt. #555555 auf Schwarz ist 2,8:1. Es besteht nicht.
Beheben: niemals behaupten, dass ein Paar bestanden hat. Den Kontrastprüfer (unten) ausführen oder die Formel anwenden. Wenn beides nicht möglich ist, die Referenztabelle verwenden.

Nicht-Text-Kontrast

Sagen: interaktive Komponenten (Schaltflächen, Symbole, Eingaberänder, Fokusindikatoren, Diagrammsegmente), die sich um weniger als 3:1 von ihrem Hintergrund abheben.
Warum: Nicht-Text-UI transportiert Informationen durch Form und Kante. Wenn die Kante nur ein Hauch von Farbe ist, können sehbehinderte Benutzer das Bedienelement nicht finden. Die gleiche Anforderung gilt für Zustände wie Hover und Ausgewählt.
Beheben: jeder Komponentengrenze und jedem Statusindikator ein 3:1-Verhältnis zu benachbarten Farben geben (WCAG 1.4.11). Symbole mit einem Textlabel paaren, das 4,5:1 erfüllt.

Der Kontrastprüfer

Die Heimat des Kontrastprüfers. Drei Ebenen, von der bequemsten zur am wenigsten bequemen:

Das Skript. Wenn eine Skriptlaufzeitumgebung verfügbar und die Datei vorhanden ist, führe es anstatt von Hand zu rechnen. Das Skript befindet sich im Ordner dieses Skills (contrast-check.py, neben dieser SKILL.md). Führe es mit python3 unter macOS und Linux, python unter Windows aus:

python3 "${CLAUDE_SKILL_DIR}/contrast-check.py" "#FFFFFF" "#777777"
# normal text: FAIL (4.48 < 4.5)
# large text:  PASS (4.48 >= 3.0)

Wenn die Variable ${CLAUDE_SKILL_DIR} in diesem Agenten nicht verfügbar ist, verweise den Skriptpfad direkt auf den Ordner dieses Skills. Das Skript existiert, damit Agenten aufhören, AA zu halluzinieren. Es nimmt zwei Hex-Farben und gibt das Verhältnis sowie das Urteil für beide Textgrößen aus. Wenn die Datei fehlt, sind die Formel und die Tabelle unten vollständig. Blockiere niemals auf das Skript.

Die Formel (WCAG 2.x).

Kontrastverhältnis = (L1 + 0,05) / (L2 + 0,05), wobei L1 die hellere relative Leuchtdichte und L2 die dunklere ist.
Relative Leuchtdichte L einer Farbe: jeden Kanal in 0-1 umwandeln (c = hex / 255), dann linearisieren: wenn c <= 0,03928, c_lin = c / 12,92; sonst c_lin = ((c + 0,055) / 1,055)^2,4.
L = 0,2126*R + 0,7152*G + 0,0722*B.
Das ungerundete Verhältnis vergleichen: 4,5:1 für normalen Text, 3:1 für großen Text (18px+, gemäß R-25). Nur zur Anzeige runden, so dass ein Paar bei 4,498:1 als 4,50 angezeigt wird und immer noch 4,5:1 nicht besteht. Das maximale Verhältnis ist 21,0 (Schwarz auf Weiß).

Die Referenztabelle (gängige Paare, mit der Formel berechnet):

Paar (Text auf Hintergrund)	Verhältnis	Normaler Text (4,5)	Großer Text (3,0)
Schwarz auf Weiß	21,00	Bestanden	Bestanden
Weiß auf Schwarz	21,00	Bestanden	Bestanden
Weiß auf #333333	12,63	Bestanden	Bestanden
Weiß auf #666666	5,74	Bestanden	Bestanden
#777777 auf Weiß	4,48	Nicht bestanden	Bestanden
#777777 auf #070707	4,50	Nicht bestanden	Bestanden
Weiß auf #888888	3,54	Nicht bestanden	Bestanden
Weiß auf #999999	2,85	Nicht bestanden	Nicht bestanden
#555555 auf Schwarz	2,82	Nicht bestanden	Nicht bestanden

Die Zeile #777777 auf #070707 ist der Grenzfall: 4,4983:1 rundet auf 4,50 zur Anzeige und besteht 4,5:1 immer noch nicht.

Lies die Tabelle als Plausibilitätsprüfung, nicht als Ersatz. Jedes nicht aufgeführte Paar oder alles nahe einem Grenzwert geht durch die Formel oder das Skript.

Tastatur

Entfernter Fokusrahmen

Sagen: outline: none oder outline: 0 ohne Ersatz-Fokusstil.
Warum: Tastaturnutzer können nicht sehen, wo sie sind. Es ist der schnellste Weg, eine UI ohne Maus unbrauchbar zu machen, und R-32 verbietet es vollständig.
Beheben: den Rahmen behalten oder durch einen sichtbaren :focus-visible-Stil ersetzen, der die gleiche Kontrastschwelle (3:1 zu seinen Nachbarn) erfüllt. Niemals outline: none ohne Ersatz setzen.

Nur-Maus-Muster

Sagen: Menüs, die sich nur bei Hover öffnen, Dropdowns, die per Klick öffnen, aber nicht per Tastatur, Drag-and-Drop ohne Tastaturfallback.
Warum: jedes schließt Tastatur- und Hilfstechnologie-Nutzer aus (R-32). Wenn ein Bedienelement nicht durch Tab, Enter oder Leertaste erreicht und bedient werden kann, existiert es für eine ganze Gruppe von Menschen nicht.
Beheben: jedes interaktive Element ist mit der Tastatur erreichbar und bedienbar (R-32): logische Tab-Reihenfolge entsprechend der visuellen Reihenfolge, Aktivierung mit Enter oder Leertaste und Dialoge schließbar mit Escape (R-26).

Unterbrochene Tab-Reihenfolge

Sagen: der Fokus springt auf der Seite umher, überspringt Inhalte oder landet auf versteckten Elementen, weil die DOM-Reihenfolge nicht mit der visuellen Reihenfolge übereinstimmt.
Warum: eine Tab-Reihenfolge, die die Code-Reihenfolge statt der visuellen Reihenfolge liest, macht die Navigation unvorhersehbar (R-32). Benutzer verlieren ihre Position und die Seite fühlt sich kaputt an.
Beheben: die Quellreihenfolge mit der visuellen Reihenfolge übereinstimmen lassen, Sprunglinks für lange Seiten hinzufügen und echten Inhalten niemals tabindex="-1" geben, es sei denn, es ist Teil einer kontrollierten Fokusfalle wie einem Dialog.

Fokus und Zustände

Schwacher oder unsichtbarer Fokusindikator

Sagen: ein Fokusring in derselben Farbe wie der Hintergrund, ein Ring, der nur bei Hover erscheint, oder ein Indikator dünner als ein 1px-Rand.
Warum: der Fokusindikator ist, wie Tastaturnutzer wissen, wo sie sind. Wenn er die Kontrastschwelle nicht erfüllt oder nur bei Hover erscheint, ist die reine Tastaturbedienung unterbrochen (R-32, R-34).
Beheben: ein sichtbarer Fokusindikator auf jedem interaktiven Element, 3:1 zu benachbarten Farben, in jedem von dir ausgelieferten Theme. Überprüfe ihn im Dunkel- und Hellmodus.

Nur-Farbe-Rückmeldung

Sagen: Erfolg, Fehler und Status werden nur durch Farbe kommuniziert: roter Fehlertext, grüner Erfolgsrand, ein getönter Chip, ohne Symbol, Label oder Text.
Warum: es schließt farbenblinde und sehbehinderte Benutzer aus und verschwindet vollständig im Zwangsfarbmodus. Ein Status, der vom Sehen eines Farbtons abhängt, ist kein Status (C-4).
Beheben: jedes Farbsignal mit Text, einem Symbol oder einem Muster paaren. Fehlerzustände sind zuerst Text: "Das Passwort muss mindestens 8 Zeichen lang sein", nicht nur ein roter Rand.

Fehlende UI-Zustände

Sagen: eine Datenansicht ohne leeren, Lade- oder Fehlerzustand, oder Zustände, die zwar existieren, aber unsichtbar sind: ein Spinner ohne Text, ein leerer Bildschirm ohne Erklärung.
Warum: R-27 erfordert die drei Zustände; der Barrierefreiheitsaspekt ist, dass jeder wahrnehmbar und informativ sein muss, nicht dekorativ. Ein Ladespinner ohne Kontext wirkt für Screenreader-Nutzer wie eine eingefrorene Seite.
Beheben: jede Datenansicht hat alle drei Zustände (R-27), jeder angesagt oder sichtbar: eine explizite Leermeldung, ein Ladestatus mit Text und ein Fehlerstatus, der sagt, was passiert ist und wie man weiter vorgeht.

Zoom und mobile Nutzung

Die Layout-Mechanik hinter mobil (Bruchpunkte, Skalierung, Raster, Überlauf, Zielgrößen) ist Gegenstand von antislop-layoutmobile. Dieser Abschnitt behält nur die mobilen Details, die Menschen ausschließen: Zoomen und die Bildschirmtastatur.

Text, der nicht zoombar ist

Sagen: feste Pixel-Schriftgrößen oder Container mit overflow: hidden, die Text bei 200% Zoom abschneiden.
Warum: Benutzer müssen Textgröße ändern können (WCAG 1.4.4). Wenn Zoomen auf 200% den Inhalt abschneidet oder horizontalen Scrollen erzwingt, ist der Text in der Praxis nicht skalierbar.
Beheben: fließende Schrift, die mit Zoom umfließt, keine abschneidenden Container für Text, und überprüfen, ob das Layout bei 200% Zoom auf einem schmalen Viewport hält (R-35).

Mobile Tastatur bedeckt das Formular

Sagen: Eingaben am unteren Rand des Viewports, versteckt hinter der Bildschirmtastatur, ohne Scroll-in-Ansicht und ohne Platz für die Eingabe.
Warum: ein Formular, das der Benutzer nicht sehen oder erreichen kann, ist ein Formular, das er nicht ausfüllen kann. Es ist ein mobiler Ausschluss (R-03).
Beheben: wenn eine Eingabe fokussiert ist, scrollt sie in die Ansicht über die Tastatur, mit genügend unterem Abstand, dass das fokussierte Feld niemals bedeckt wird. Teste mit einem echten Gerät oder einer emulierten Tastatur.

Checkliste Human-Skill

Führe diese zusammen mit dem Kern-Delivery-Gate aus, wenn die Aufgabe UI betrifft. Alle Antworten müssen ja sein:

Wurde jedes Text- und Hintergrundpaar gegen den Kontrastprüfer (Formel, Tabelle oder Skript) verifiziert, einschließlich Text auf Bildern und Farbverläufen? (R-25)
Erfüllt jede interaktive Komponentengrenze und jeder Statusindikator 3:1 gegenüber dem Hintergrund? (Nicht-Text-Kontrast)
Ist der Fokusindikator sichtbar, kontrastreich und auf jedem interaktiven Element in jedem Theme vorhanden? (R-32, R-34)
Ist jedes interaktive Element mit der Tastatur erreichbar und bedienbar, mit Dialogen, die über Escape schließbar sind, und kein outline: none ohne Ersatz? (R-32, R-26)
Sind die leeren, Lade- und Fehlerzustände jeder Datenansicht vorhanden und wahrnehmbar, nicht nur farbbasiert? (R-27, C-4)
Kann Text auf 200% vergrößert werden, ohne abgeschnitten zu werden, und deckt die mobile Tastatur niemals ein fokussiertes Eingabefeld ab? (R-35)

yonathan-boop/Claude

Was ist Claude?

In Ihrer bevorzugten KI fragen

Dokumentation