Figer une observation plutôt qu’un système entier
Ce parcours aide les designers et responsables frontend d’un site autorisé. Il livre un inventaire relu et des propositions de jetons, pas un clone ni les sources du design original. Choisissez une page publique sans identifiants ni données sensibles. Notez URL, date, fenêtre ordinateur ou mobile, préférence claire ou sombre et attente. Demander le sombre ne prouve pas que le site l’applique.
Gardez le ZIP contenant design.md, screenshot.png, tokens.json et tokens.css et calculez les empreintes. Examinez d’abord l’image : consentement, police absente ou ressource bloquée peuvent fausser l’état. La capture couvre une fenêtre fixe, alors que le scan limité peut inclure des éléments plus bas. Aucun défilement, clic ou connexion automatique n’est effectué. Conservez avertissements et troncatures comme limites de couverture.
Séparer observations et interprétations
Choisissez titres, textes, boutons et cartes représentatifs et associez les valeurs à leur contexte dans un registre distinct. Le prélèvement par coordonnées sert à comparer une surface visible, pas à retrouver aveuglément le CSS. Anticrénelage, transparence, dégradés, images et gestion des couleurs peuvent modifier les pixels. Préférez une zone unie et gardez les deux valeurs si nécessaire.
Les fréquences comptent des déclarations, pas des surfaces ni l’importance de marque. Une pile font-family ne prouve pas la police de chaque glyphe ; une largeur ne définit pas toute l’échelle responsive. observed-1 est un nom mécanique. Lui attribuer une action principale est une proposition avec motif et responsable. Certaines expressions restent au rapport sans jeton primitif exporté : signalez la limite au lieu d’inventer une valeur.
Contrôler les contrastes et changements dans leur contexte
Convertissez seulement les couleurs prises en charge, en gardant originaux et avertissements de gamut. Un espace plus étroit peut changer l’apparence : un HEX pratique n’est pas forcément équivalent à une source étendue. Identifiez avant-plan et fond réels. Les transparences nécessitent une composition vérifiée ; images et dégradés des contrôles adaptés. Si l’outil ne représente pas le cas, laissez-le ouvert sans deviner des couleurs opaques.
Formatez une copie de tokens.css pour lecture, sans remplacer les styles du site. Validez tokens.json avec votre schéma compatible et pris en charge : structure ou étiquette de format ne prouvent ni justesse du design ni conformité à une norme. Comparez fenêtres, préférences et réglages équivalents. L’ordre peut décaler les numéros : observed-1 modifié ne désigne pas forcément le même composant. Rapprochez valeurs et contexte et distinguez changement réel, ressources manquantes et bruit.
Livrer les décisions et les vérifications restantes
Tenez référence de capture, composant, déclaration, coordonnées utiles, nom proposé, statut, motif et responsable. Ce registre est séparé, pas une identité stable fournie automatiquement. Distinguez preuves, propositions acceptées et cas ouverts ; chaque nouveau nom doit retrouver son observation.
Rouvrez JSON et CSS, répétez les contrôles après modification et calculez les empreintes finales. Gardez fichiers locaux et ressources du rapport plutôt que de simples liens temporaires. Listez largeurs, survol, focus, erreurs, écrans privés, cadres et pages non testés. Le destinataire doit vérifier les changements dans le navigateur cible avant déploiement : une capture et quelques ratios ne certifient pas l’accessibilité globale. Les parcours liés servent à créer une palette, vérifier la typographie et implémenter le CSS.