antislop-human

Anti Slop : Règles pour les agents de codage IA. Compétence humaine

Fait partie du système antislop. À lire avec antislop.md (le noyau). Cette compétence approfondit la préoccupation humaine : l'interface utilisateur doit rester utilisable par des personnes ayant des yeux, des mains et des configurations différents. Contraste, clavier, focus, états, et les détails mobiles qui excluent les personnes.

Comment utiliser cette compétence

Chargez-la avec antislop.md dès que la tâche construit ou modifie une interface utilisateur. Le noyau contient le mécanisme (le test d'intention, les trois niveaux, la Porte de Livraison) ; cette compétence contient la profondeur côté humain : les parties d'une interface qui excluent les personnes ayant des yeux, des mains et des configurations différents.
Chaque entrée a la même structure : Dire (le motif), Pourquoi (qui il exclut, et pourquoi il est perçu comme inachevé), Corriger (que faire à la place), avec la règle de base correspondante citée comme R-XX.
L'accessibilité n'est pas une liste de contrôle d'extras ajoutés à la fin. Elle fait partie de la promesse fondamentale selon laquelle « l'interface tient la route » (C-4). La Porte de Livraison du noyau reste la porte ; la « Liste de contrôle de la compétence humaine » à la fin de ce fichier est le supplément à exécuter en parallèle.
Le vérificateur de contraste (formule + tableau de référence + script) se trouve dans cette compétence. Utilisez-le pour chaque paire de couleurs que vous ne pouvez pas vérifier à l'œil.
Cette compétence ne conserve que les détails mobiles qui excluent les personnes : le zoom et le clavier à l'écran.

Couleur et contraste

Texte à faible contraste

Dire : texte gris clair sur fond blanc ou presque blanc, texte de corps fin, étiquettes atténuées choisies parce qu'elles semblent « élégantes » mais sont difficiles à lire.
Pourquoi : cela exclut les utilisateurs malvoyants et tout le monde sous une lumière vive. C'est un choix visuel fait sans vérifier la norme, exactement le genre de défaut que le filtre est censé détecter.
Corriger : respecter les minimums WCAG AA (R-25) : 4,5:1 pour le texte normal, 3:1 pour le grand texte (18px+). Calculez le ratio ; ne l'évaluez pas à l'œil.

Texte sur une photo ou un dégradé

Dire : texte blanc placé directement sur une image ou un dégradé clair par endroits, vérifié uniquement à un endroit lumineux.
Pourquoi : le contraste est local. Là où l'image est claire, le texte tombe en dessous de 4,5:1 même si la bannière semble encore « correcte ». R-25 exige de tester toute la zone que le texte traverse, pas un seul point.
Corriger : ajoutez une voilette ou un bloc de couleur unie derrière le texte, puis vérifiez le pire endroit, pas le meilleur. Si une partie de la zone de texte échoue, le traitement est invalide.

L'hallucination gris sur gris

Dire : « gris foncé sur noir » ou « gris clair sur blanc » prétendu passer AA sans calcul.
Pourquoi : c'est l'hallucination d'accessibilité la plus courante. L'œil surestime le contraste sur les paires de gris, et les agents répètent l'affirmation parce qu'elle semble plausible. #555555 sur noir donne 2,8:1. Il échoue.
Corriger : n'affirmez jamais qu'une paire passe. Exécutez le vérificateur de contraste (ci-dessous) ou appliquez la formule. Quand aucun des deux n'est possible, utilisez le tableau de référence.

Contraste non textuel

Dire : composants interactifs (boutons, icônes, bordures de saisie, indicateurs de focus, segments de graphique) se distinguant de leur arrière-plan par moins de 3:1.
Pourquoi : l'interface non textuelle transmet des informations par la forme et le bord. Lorsque le bord est une nuance infime, les utilisateurs malvoyants ne peuvent pas trouver le contrôle. La même barre s'applique aux états comme le survol et la sélection.
Corriger : donnez à chaque limite de composant et à chaque indicateur d'état un ratio de 3:1 par rapport aux couleurs adjacentes (WCAG 1.4.11). Associez les icônes à une étiquette de texte qui atteint 4,5:1.

Le vérificateur de contraste

Le cœur du vérificateur de contraste. Trois couches, de la plus pratique à la moins pratique :

Le script. Lorsqu'un environnement d'exécution de script est disponible et que le fichier est présent, exécutez-le plutôt que de calculer à la main. Le script est livré dans le dossier de cette compétence (contrast-check.py, à côté de ce SKILL.md). Exécutez-le avec python3 sur macOS et Linux, python sur Windows :

python3 "${CLAUDE_SKILL_DIR}/contrast-check.py" "#FFFFFF" "#777777"
# texte normal : ÉCHEC (4.48 < 4.5)
# grand texte :  RÉUSSI (4.48 >= 3.0)

Si la variable ${CLAUDE_SKILL_DIR} n'est pas disponible dans cet agent, pointez le chemin du script directement vers le dossier de cette compétence. Le script existe pour que les agents cessent d'halluciner AA. Il prend deux couleurs hexadécimales et affiche le ratio et le verdict pour les deux tailles de texte. Si le fichier est manquant, la formule et le tableau ci-dessous sont complets en eux-mêmes. Ne bloquez jamais sur le script.

La formule (WCAG 2.x).

Rapport de contraste = (L1 + 0,05) / (L2 + 0,05), où L1 est la luminance relative la plus claire et L2 la plus foncée.
Luminance relative L d'une couleur : convertir chaque canal en 0-1 (c = hex / 255), puis linéariser : si c <= 0,03928, c_lin = c / 12,92 ; sinon c_lin = ((c + 0,055) / 1,055)^2,4.
L = 0,2126*R + 0,7152*G + 0,0722*B.
Comparez le ratio non arrondi : 4,5:1 pour le texte normal, 3:1 pour le grand texte (18px+, selon R-25). Arrondissez uniquement pour l'affichage, donc une paire à 4,498:1 s'affiche comme 4,50 et échoue toujours à 4,5:1. Le ratio maximum est de 21,0 (noir sur blanc).

Le tableau de référence (paires courantes, calculées avec la formule) :

Paire (texte sur fond)	Ratio	Texte normal (4.5)	Grand texte (3.0)
Noir sur blanc	21.00	Réussi	Réussi
Blanc sur noir	21.00	Réussi	Réussi
Blanc sur #333333	12.63	Réussi	Réussi
Blanc sur #666666	5.74	Réussi	Réussi
#777777 sur blanc	4.48	Échec	Réussi
#777777 sur #070707	4.50	Échec	Réussi
Blanc sur #888888	3.54	Échec	Réussi
Blanc sur #999999	2.85	Échec	Échec
#555555 sur noir	2.82	Échec	Échec

La ligne #777777 sur #070707 est le cas proche du seuil : 4,4983:1 arrondi à 4,50 pour l'affichage et échoue toujours à 4,5:1.

Lisez le tableau comme une vérification de cohérence, pas comme un substitut. Toute paire non répertoriée, ou tout ce qui est proche d'un seuil, passe par la formule ou le script.

Clavier

Contour de focus supprimé

Dire : outline: none ou outline: 0 sans style de focus de remplacement.
Pourquoi : les utilisateurs du clavier ne peuvent pas voir où ils se trouvent. C'est le moyen le plus rapide de rendre une interface inutilisable sans souris, et R-32 l'interdit catégoriquement.
Corriger : conservez ou remplacez le contour par un style :focus-visible visible qui respecte la même barre de contraste (3:1 par rapport à ses voisins). Ne définissez jamais outline: none sans remplacement.

Modèles réservés à la souris

Dire : menus qui s'ouvrent uniquement au survol, listes déroulantes qui s'ouvrent au clic mais pas au clavier, glisser-déposer sans alternative clavier.
Pourquoi : chacun exclut les utilisateurs du clavier et des technologies d'assistance (R-32). Si un contrôle ne peut pas être atteint et actionné par Tab, Entrée ou Espace, il n'existe pas pour tout un groupe de personnes.
Corriger : chaque élément interactif est accessible et actionnable au clavier (R-32) : ordre de tabulation logique suivant l'ordre visuel, activation avec Entrée ou Espace, et fenêtres modales fermables avec Échap (R-26).

Ordre de tabulation défaillant

Dire : le focus saute dans la page, ignore du contenu, ou atterrit sur des éléments cachés parce que l'ordre du DOM ne correspond pas à l'ordre visuel.
Pourquoi : l'ordre de tabulation qui suit l'ordre du code au lieu de l'ordre visuel rend la navigation imprévisible (R-32). Les utilisateurs perdent leur repère et la page semble cassée.
Corriger : maintenez l'ordre source correspondant à l'ordre visuel, ajoutez des liens d'évitement pour les longues pages, et n'attribuez jamais tabindex="-1" à du contenu réel sauf s'il fait partie d'un piège à focus contrôlé comme une boîte de dialogue.

Focus et états

Indicateur de focus faible ou invisible

Dire : un anneau de focus de la même couleur que l'arrière-plan, un anneau qui n'apparaît qu'au survol, ou un indicateur plus fin qu'une bordure de 1px.
Pourquoi : l'indicateur de focus est la façon dont les utilisateurs du clavier savent où ils se trouvent. S'il échoue à la barre de contraste ou n'apparaît qu'au survol, l'utilisation au clavier seul est compromise (R-32, R-34).
Corriger : un indicateur de focus visible sur chaque élément interactif, 3:1 par rapport aux couleurs adjacentes, dans chaque thème que vous livrez. Vérifiez-le en mode sombre et clair.

Retour d'information uniquement par la couleur

Dire : succès, erreur et état communiqués uniquement par la couleur : texte d'erreur rouge, bordure de succès verte, un badge teinté, sans icône, étiquette ou texte.
Pourquoi : cela exclut les utilisateurs daltoniens et malvoyants, et disparaît complètement en mode couleurs forcées. Un état qui dépend de la perception de la teinte n'est pas un état (C-4).
Corriger : associez chaque signal de couleur à du texte, une icône ou un motif. Les états d'erreur sont d'abord du texte : « Le mot de passe doit comporter au moins 8 caractères », pas seulement une bordure rouge.

États d'interface manquants

Dire : une vue de données sans état vide, de chargement ou d'erreur, ou des états qui existent mais sont invisibles : un spinner sans texte, un écran vide sans explication.
Pourquoi : R-27 exige les trois états ; l'angle d'accessibilité est que chacun doit être perceptible et informatif, pas décoratif. Un spinner de chargement sans contexte est perçu comme une page figée par les utilisateurs de lecteurs d'écran.
Corriger : chaque vue de données a les trois états (R-27), chacun annoncé ou visible : un message de vide explicite, un état de chargement avec texte, et un état d'erreur qui dit ce qui s'est passé et comment procéder.

Zoom et utilisation mobile

Les mécanismes de mise en page derrière le mobile (points de rupture, échelle, grilles, débordement, cibles tactiles) relèvent de antislop-layoutmobile. Cette section ne conserve que les détails mobiles qui excluent les personnes : le zoom et le clavier à l'écran.

Texte impossible à zoomer

Dire : tailles de police fixes en pixels, ou conteneurs avec overflow: hidden qui coupent le texte à 200% de zoom.
Pourquoi : les utilisateurs doivent pouvoir redimensionner le texte (WCAG 1.4.4). Si le zoom à 200% coupe le contenu ou force un défilement horizontal, le texte n'est pas redimensionnable en pratique.
Corriger : une typographie fluide qui se redimensionne avec le zoom, pas de conteneurs tronquant le texte, et vérifiez que la disposition tient à 200% de zoom sur une fenêtre étroite (R-35).

Le clavier mobile couvre le formulaire

Dire : des champs de saisie en bas de la fenêtre cachés derrière le clavier à l'écran, sans défilement visible et sans espace pour la saisie.
Pourquoi : un formulaire que l'utilisateur ne peut pas voir ou atteindre est un formulaire qu'il ne peut pas remplir. C'est une exclusion propre au mobile (R-03).
Corriger : lorsqu'un champ de saisie est activé, il défile dans la vue au-dessus du clavier, avec un espacement inférieur suffisant pour que le champ activé ne soit jamais masqué. Testez avec un appareil réel ou un clavier émulé.

Liste de contrôle de la compétence humaine

Exécutez-les parallèlement à la Porte de Livraison du noyau lorsque la tâche implique une interface utilisateur. Toutes les réponses doivent être oui :

Chaque paire de texte et d'arrière-plan est-elle vérifiée par le vérificateur de contraste (formule, tableau ou script), y compris le texte sur les images et les dégradés ? (R-25)
Chaque limite de composant interactif et indicateur d'état atteint-il 3:1 par rapport à son arrière-plan ? (contraste non textuel)
L'indicateur de focus est-il visible, à contraste élevé, et présent sur chaque élément interactif dans chaque thème ? (R-32, R-34)
Chaque élément interactif est-il accessible et actionnable au clavier, avec des boîtes de dialogue fermables via Échap et aucun outline: none sans remplacement ? (R-32, R-26)
Les états vide, de chargement et d'erreur de chaque vue de données sont-ils présents et perceptibles, et non uniquement par la couleur ? (R-27, C-4)
Le texte peut-il être redimensionné à 200% sans être tronqué, et le clavier mobile ne couvre-t-il jamais un champ activé ? (R-35)

yonathan-boop/Claude

Qu'est-ce que Claude ?

Demander à votre IA préférée

Documentation