ShortArrow/interface-design

Conception d'interface

Une question à propos d'un écran n'est pas une question de goût. Le contraste a un ratio, une cible a une taille, un reflow a une largeur à laquelle il doit encore fonctionner, et une disposition a un ordre d'information qui découle de ce que le lecteur fait en premier. Ces éléments sont décidés par la mesure et par des normes publiées, donc les confier à l'utilisateur comme « que préférez-vous » gaspille son attention sur un travail qui était celui de l'agent.

Ce qui reste après la mesure est une vraie question, et cette compétence existe pour réduire ce reste et y attacher les preuves. own-the-call régit la manière dont elle est ensuite posée.

Les moments que cela remplace

Sur le point de…	Au lieu de cela…
demander quelle couleur, taille, espacement ou placement l'utilisateur préfère	mesurer par rapport à la norme ci-dessous ; ne demander que ce qu'aucun seuil ne tranche
qualifier un choix visuel de subjectif	nommer le critère qu'il échoue ou réussit — contraste, taille de cible, largeur de reflow, visibilité du focus, ordre d'information
dire « ça a l'air bien »	l'ouvrir, prendre une capture d'écran et dire ce qui a été mesuré à quelle fenêtre
dimensionner un contrôle à l'œil	24×24 px CSS est le seuil WCAG AA ; un système de design peut en fixer un plus strict (Material : 48dp)
choisir des couleurs d'une palette par apparence	calculer le ratio : 4,5:1 pour le texte courant, 3:1 pour les grands textes et les éléments non textuels
livrer une disposition vérifiée à une seule taille de fenêtre	vérifier à 320 px de large et 256 px de haut, où le reflow doit encore fonctionner
lire un rapport axe vert comme accessible	axe trouve environ 57 % ; le reste concerne le clavier, l'ordre du focus et le sens
concevoir un composant qu'un système de design définit déjà	prendre le leur et dire lequel
demander comment dessiner un diagramme	décider à partir de ce que le lecteur trace d'abord, puis montrer un rendu

Décider à partir de la norme avant de demander

Quatre organismes répondent à la majeure partie des questions, et ils ne sont pas toujours d'accord — là où ils diffèrent, c'est le chiffre le plus strict qu'il faut respecter, car le respecter satisfait les deux.

WCAG 2.2 est le plancher, et il est normatif : une recommandation du W3C, et ISO/IEC 40500. Cible : Niveau AA ; le Niveau AAA n'est pas atteignable pour tout contenu et le W3C le dit.

Critère	Niveau	Seuil
1.4.3 Contraste (Minimum)	AA	4,5:1 pour le texte ; 3:1 pour les grands textes (≥18 pt, ou 14 pt en gras)
1.4.11 Contraste des éléments non textuels	AA	3:1 par rapport aux couleurs adjacentes
1.4.4 Redimensionnement du texte	AA	utilisable à 200 %
1.4.10 Reflow	AA	pas de défilement sur deux axes à 320 px de large ou 256 px de haut
1.4.12 Espacement du texte	AA	interligne ≥1,5×, paragraphe ≥2×, lettre ≥0,12×, mot ≥0,16× la taille de police
2.4.7 Focus visible	AA	un mode où l'indicateur de focus est visible
2.4.11 Focus non masqué	AA	le contrôle ciblé n'est pas complètement caché
2.5.8 Taille de la cible (Minimum)	AA	24×24 px CSS, ou espacement de 24 px
2.4.13 Apparence du focus	AAA	périmètre ≥2 px, contraste 3:1 entre l'état ciblé et non ciblé
2.5.5 Taille de la cible (Amélioré)	AAA	44×44 px CSS

Un système de design tranche ce que WCAG laisse ouvert : échelle d'espacement, échelle typographique, anatomie des composants, rôles de couleur. Prendre son composant n'est pas un raccourci, c'est la décision — et elle apporte le travail d'accessibilité déjà effectué. Material Design 3 fixe des cibles tactiles de 48×48 dp, plus strictes que les 24 px du WCAG, et demande que la couleur soit choisie via des rôles (primary, on-primary, surface) plutôt que par des hex fixes, ainsi le theming et le mode sombre suivent sans seconde décision. Pour les travaux publics japonais, le système de design de l'Agence numérique (design.digital.go.jp, β版 comme standard vivant) propose des composants, des directives et des tokens, avec les tokens et exemples de composants sur GitHub sous licence MIT.

axe-core mesure ce qui peut être mesuré, et énonce sa propre limite : environ 57 % des problèmes WCAG en moyenne. Un rapport vert n'est donc une preuve que pour 57 % de la question, et dire « axe passe » sans ce nombre surestime la portée — measured-claims s'applique à ce chiffre comme à tout autre.

npx @axe-core/cli http://localhost:5173 --tags wcag2a,wcag2aa,wcag22aa
npx lighthouse http://localhost:5173 --only-categories=accessibility --quiet

Le score d'accessibilité de Lighthouse est le même moteur habillé d'un nombre. Ses audits sont des règles d'axe-core — chacune renvoie à la page de règle de Deque — donc les 57 % sont hérités, et le score ajoute deux façons d'être mal interprété. C'est une moyenne pondérée, poids de 3 à 10 selon l'évaluation d'impact utilisateur d'axe, et les audits manuels et de bonnes pratiques en sont complètement exclus, donc l'arithmétique ne peut pas atteindre la partie qu'une personne doit vérifier. Chaque audit est aussi binaire : un seul bouton non étiqueté fait échouer « Les boutons ont un nom accessible », sans demi-mesure. Donc 100 signifie « le sous-ensemble automatique pondéré a réussi », et le rapport honnête d'un score parfait dit cela, pas « accessible ». Utilisez-le pour la liste classée de ce qu'il faut corriger ; utilisez le JSON d'axe lorsque le constat importe plus que le classement. Les catégories de performance de Lighthouse relèvent de web-perf, pas de cette compétence.

Ce qu'aucun des deux ne voit : si l'ordre du focus suit l'ordre de lecture, si un étiquette nomme ce qu'elle étiquette, si le sens d'une icône survit sans couleur, si l'ordre d'information de la disposition correspond à la tâche. Ceux-ci sont lus par une personne, et cette personne peut être l'agent.

Regarder, puis dire ce qui a été vu

Une affirmation sur une interface sans observation derrière elle est la rumeur de measured-claims dans un autre médium. L'hôte dispose d'un navigateur, donc l'observation est disponible :

mcp__claude-in-chrome__navigate      → la page
mcp__claude-in-chrome__read_page     → structure, titres, étiquettes
mcp__claude-in-chrome__computer      → capture d'écran à une fenêtre spécifiée
mcp__claude-in-chrome__resize_window → 320 px, pour tester le reflow

Signalez la fenêtre avec le constat. « Ça a l'air bien » ne nomme aucune largeur ni aucune mesure ; « à 320 px, la deuxième colonne passe sous la première et rien ne défile latéralement » est une lecture que quelqu'un peut vérifier. L'ordre du clavier est parcouru avec Tab et signalé comme la séquence observée, car c'est la moitié qu'axe ne couvre pas.

L'ordre d'information est dérivé, pas choisi

Où va quelque chose découle de ce que le lecteur en fait, ce qui est la question de reader-map appliquée à un écran : qui arrive, ce qu'ils sont venus faire, ce dont ils ont besoin en premier. Un contrôle utilisé une fois lors de la configuration et un contrôle utilisé chaque minute ne sont pas en concurrence pour la même place.

Donc « où cela devrait-il aller » trouve sa réponse en nommant la tâche, pas en listant trois positions. Quand deux tâches sont réellement en concurrence et qu'aucune ne domine, c'est le reste qui mérite d'être demandé — et il est demandé avec les tâches concurrentes nommées, pas comme un choix de coins.

Il en va de même pour un diagramme. Ce que le lecteur trace en premier décide de la direction du flux ; la forme suit le tracé, et un seul rendu est présenté plutôt que trois décrits.

Ce qui revient véritablement à l'utilisateur

Trois choses survivent à la mesure :

• Quel public ou marché l'interface sert, quand ce n'est pas encore fixé — cela détermine quelle norme s'applique (regulated-claims pour un marché réglementé).
• Une contrainte de marque — une couleur, police ou marque imposée. La contrainte est la leur ; si elle respecte 4,5:1 est toujours mesuré, et une couleur de marque qui échoue est signalée avec le ratio et la variante passante la plus proche.
• Un compromis déjà mesuré des deux côtés, où les preuves ne tranchent pas : densité contre lisibilité d'aperçu, un écran contre deux. Demandé avec les deux mesures attachées, c'est une question que own-the-call admet.

Tout le reste — contraste, espacement, taille de cible, focus, reflow, choix de composant, forme de diagramme, placement qui suit une tâche — est décidé et signalé.

Liste de vérification

• Contraste calculé, pas évalué à l'œil : 4,5:1 pour le texte, 3:1 pour les grands textes et les éléments non textuels
• Cibles interactives ≥24×24 px CSS, ou le chiffre plus strict du système de design
• Vérifié à 320 px de large et 256 px de haut sans défilement sur deux axes
• Focus visible sur chaque élément interactif, et non masqué
• Ordre de tabulation parcouru et signalé tel qu'observé
• Composants pris du système de design là où il en définit un, et nommés
• axe ou Lighthouse exécuté, et la limite de 57 % mentionnée plutôt qu'impliquée
• Un score d'accessibilité Lighthouse signalé comme le sous-ensemble automatique pondéré, jamais comme « accessible »
• Chaque affirmation sur l'apparence est accompagnée de la fenêtre à laquelle elle a été observée
• Les questions laissées à l'utilisateur sont des trois types ci-dessus, avec les preuves attachées

Comment cela se connecte

own-the-call façonne la question qui survit à cette compétence ; la plupart des questions sur un écran ne devraient pas l'atteindre. reader-map fournit l'ordre des tâches auquel cette compétence applique le placement. measured-claims régit tous les ratios et pourcentages ici, les 57 % inclus. document-structure et cognitive-rhythm possèdent la prose sur une page ; cette compétence possède le cadre autour d'elle. any-screenshot est la manière de capturer un écran en dehors d'un navigateur. La vitesse de chargement et d'interaction, les Core Web Vitals et le score de performance de Lighthouse appartiennent à web-perf dans le plugin cloudflare ; cette compétence ne prend que la catégorie d'accessibilité de Lighthouse.

Sources

• W3C, « Web Content Accessibility Guidelines (WCAG) 2.2 », Recommandation W3C datée du 12 décembre 2024 (www.w3.org/TR/WCAG22/) : les quatre principes, les niveaux A/AA/AAA, et la suppression du 4.1.1 Parsing comme obsolète.
• W3C, « How to Meet WCAG 2.2 (Quick Reference) » (www.w3.org/WAI/WCAG22/quickref/) : tous les seuils du tableau ci-dessus, lus au Niveau AAA pour inclure 2.4.13 et 2.5.5.
• Deque Labs, README d'axe-core (github.com/dequelabs/axe-core) : MPL-2.0 ; règles mappées à WCAG 2.0, 2.1 et 2.2 aux niveaux A, AA et AAA ; « vous pouvez trouver en moyenne 57 % des problèmes WCAG automatiquement ».
• Chrome for Developers, « Accessibilité de la notation dans Lighthouse » (developer.chrome.com/docs/lighthouse/accessibility/scoring) : le score est une moyenne pondérée, poids de 3 à 10, « basée sur les évaluations d'impact utilisateur d'axe », avec chaque audit renvoyant à une page de règle d'axe-core 4.11 de Deque University ; chaque audit est binaire ; les audits manuels et à faible impact sont exclus du score. La page ne dit pas elle-même qu'un score parfait signifie que la page est accessible — ni le contraire, donc l'avertissement ci-dessus est propre à cette compétence.
• Système de design de l'Agence numérique (design.digital.go.jp) : v2.18.2, étiqueté β版 dans le sens d'un standard vivant. Le site n'indique aucun niveau WCAG ni aucune cible JIS X 8341-3. digital-go-jp/design-tokens, design-system-example-components-react et -html sur GitHub sont sous licence MIT.
• La cible tactile 48×48 dp de Material Design 3 et ses directives sur les rôles de couleur sont extraites de sources secondaires citant m3.material.io, pas de ce site : ses pages sont rendues par script et n'ont pas pu être lues ici. Le chiffre de 48 dp est une recommandation de conception, pas un minimum imposé par la plateforme.

L'affirmation que ces sources ne sont pas d'accord, et que le chiffre le plus strict est celui à respecter, est la lecture du propriétaire de ce catalogue plutôt que l'une de leurs positions publiées.

Aucune des commandes ci-dessus n'a été exécutée lors de la rédaction de cette compétence : les deux téléchargent un paquet lors de la première utilisation, et le bac à sable ici refuse d'exécuter du code fraîchement téléchargé. Les drapeaux proviennent de la documentation de chaque outil plutôt que d'une exécution, donc la première utilisation dans un projet est aussi le premier test de l'invocation.