freedzhost.cloud

Web design module 2 : les outils et les règles

Niveau DébutantTemps estimé 14 hÀ lire avant Web design module 1 : voir comme un designerUn mot inconnu ? Lexique

Quatorze séances pour passer du regard à la main : Penpot, l'outil de design libre qui tourne dans le navigateur, puis les règles qui rendent une interface utilisable par tous — contraste, cibles, focus, langage clair, formulaires, navigation. Chaque règle est d'abord expliquée, puis appliquée dans un dessin.

Jour 15 — Penpot 1/3 : le canevas

Objectif : créer un fichier Penpot et y dessiner un premier écran simple.

Théorie 1/2 : l'outil et ses objets

Penpot est un outil de design d'interface libre (licence MPL 2.0) qui tourne entièrement dans le navigateur : créez un compte gratuit sur design.penpot.app, aucune installation. Trois objets structurent tout fichier : la page (un plan de travail, un fichier peut en contenir plusieurs), le board (un cadre qui représente un écran, avec une largeur et une hauteur — l'équivalent de l'« artboard » ailleurs), et les calques (formes, textes, images, empilés dans le panneau de gauche). La zone centrale, infinie, est le canevas : on y pose des boards côte à côte pour comparer des écrans. Penpot enregistre tout en continu : pas de bouton « sauvegarder ».

Dans Penpot, un « board » est…

  1. un commentaire sur le design
  2. un cadre qui représente un écran, avec sa taille
  3. une palette de couleurs
Réponse

Le board est l'écran : un cadre dimensionné (ex. 1440×900 pour un desktop) qui contient les calques.

Théorie 2/2 : les gestes de base

Cinq gestes suffisent pour aujourd'hui : créer un board (icône cadre, puis cliquer-glisser ou choisir un preset dans le panneau de droite), dessiner un rectangle (R), écrire un texte (T), déplacer au pixel près avec les flèches (Maj+flèche par grands pas), et aligner deux objets avec les guides magnétiques qui apparaissent en rouge pendant le déplacement. Le panneau de droite règle l'objet sélectionné : position, taille, remplissage, bordure, rayon des coins, ombre. Tout ce que vous avez appris au module 1 — tailles, couleurs, espacements — se saisit là, en chiffres, pas à l'œil.

Les lignes rouges qui apparaissent pendant un déplacement servent à…

  1. aligner l'objet sur ses voisins ou sur le board
  2. signaler une erreur
  3. mesurer une distance en centimètres
Réponse

Ce sont les guides d'alignement : ils magnétisent les bords et les centres, pour aligner sans calculer.

Pratique (30 min)

  1. Créez votre compte sur design.penpot.app, puis un fichier « Parcours webdesign » et une page « J15 ».
  2. Créez un board desktop (1440×900). Dessinez-y une carte : rectangle aux coins arrondis (8px), un titre, deux lignes de texte, un bouton (rectangle + texte).
  3. Appliquez votre palette du jour 6 et votre échelle du jour 4 : fond neutre, texte foncé, bouton accent. Espacements en multiples de 8.
  4. Vérifiez au survol de l'inspecteur que chaque espacement est bien 8, 16, 24 ou 32.

Critère de réussite : une carte dessinée, alignée, dont chaque espacement est un multiple de 8 et chaque couleur issue de votre palette.

Tips agent : un agent ne pilote pas Penpot à votre place, mais il prépare vos valeurs : « Génère-moi la liste des réglages d'une carte (tailles, coins, ombre discrète, espacements en multiples de 8) à partir de cette palette : [hex]. » Piège : il inventera des ombres trop marquées. Preuve : l'ombre finale reste sous 20 % d'opacité, vérifiée dans le panneau de droite.

Synthèse (10 min)

Trois lignes : page, board, calque ; les cinq gestes ; pourquoi on saisit des chiffres. Puis redessinez la carte sans notes, dans une page neuve.

Jour 16 — Penpot 2/3 : couleurs et typographies partagées

Objectif : centraliser couleurs et styles de texte dans la bibliothèque du fichier.

Théorie 1/2 : pourquoi centraliser

Quand une couleur est tapée à la main dans dix objets, la changer suppose dix corrections — et une onzième oubliée. Penpot, comme tout outil sérieux, permet d'enregistrer une couleur dans la bibliothèque du fichier (panneau Assets) : les objets s'y réfèrent, et modifier la couleur de la bibliothèque met tout à jour. Même principe pour les styles de typographie : on enregistre « Corps 16/24 Inter regular », « Titre 25/31 Inter bold », et chaque texte applique un style au lieu de valeurs isolées. C'est la version design de la règle d'or du code : une information, un seul endroit. Le jour 35, cette habitude prendra son nom d'industrie : les design tokens.

On enregistre les couleurs dans la bibliothèque pour…

  1. les rendre plus belles
  2. exporter le fichier plus vite
  3. changer une couleur une fois et la voir appliquée partout
Réponse

Une information, un seul endroit : la référence se modifie, les usages suivent.

Théorie 2/2 : nommer pour retrouver

Un bon nom de couleur dit son rôle, pas sa teinte : texte-principal, fond-page, accent, accent-survol, erreur. « Bleu-500 » devient inutile le jour où le bleu devient vert ; « accent » reste vrai. Gardez les deux niveaux si vous voulez : les teintes dans un groupe « primitif » (bleu/500), les rôles dans un groupe « sémantique » (accent → référence la même valeur). Même discipline pour les textes : le nom dit l'usage (titre-section), pas l'aspect (gras-25px). Une bibliothèque bien nommée se lit comme le sommaire de votre design.

Le meilleur nom pour la couleur des boutons d'action est…

  1. bleu-vif
  2. accent
  3. #3B82F6
Réponse

accent nomme le rôle : il survit au changement de teinte et dit à quoi sert la couleur.

Pratique (30 min)

  1. Dans votre fichier Penpot, ouvrez le panneau Assets et enregistrez vos couleurs : fond, texte, accent, accent foncé (survol), erreur, succès. Nommez-les par rôle.
  2. Enregistrez quatre styles de typographie : petit (12-14px), corps (16px/1,5), titre de section, titre principal — tous issus de votre échelle du jour 4, dans une police de Google Fonts (Inter est disponible dans Penpot).
  3. Reprenez la carte du jour 15 : remplacez chaque valeur tapée à la main par la couleur ou le style de la bibliothèque.
  4. Modifiez la couleur accent dans la bibliothèque et vérifiez que le bouton suit.

Critère de réussite : la carte ne contient plus aucune valeur isolée : tout vient de la bibliothèque, et changer l'accent la met à jour.

Tips agent : « Voici ma palette : [hex + rôles]. Propose un nommage sémantique complet (primitifs + rôles) et signale les rôles manquants pour un formulaire. » Piège : il ajoutera des rôles dont vous n'avez pas l'usage — taillez. Preuve : chaque nom proposé correspond à un élément réel de votre maquette.

Synthèse (10 min)

Trois lignes : ce que fait la bibliothèque, nommer le rôle et non la teinte, le lien avec les tokens du jour 35. Puis recréez vos cinq couleurs et quatre styles de mémoire.

Jour 17 — Penpot 3/3 : les composants

Objectif : transformer votre bouton en composant réutilisable, avec ses états.

Théorie 1/2 : le composant, la copie

Un composant est un objet défini une fois et réutilisé en autant de copies que nécessaire : on modifie le composant principal, les copies suivent. C'est la réponse à la question du jour 12 (« pareil = même aspect ») : au lieu de copier-coller un bouton et de prier pour ne rien oublier, on crée le composant « Bouton » et on en place des instances. Dans Penpot : sélectionnez le groupe d'objets, clic droit → « Create component » ; il apparaît dans Assets, et glisser depuis Assets crée une copie liée. Les copies gardent leurs propres textes — le libellé « Enregistrer » d'une copie ne change pas celui des autres — mais la forme, les couleurs et les espacements restent pilotés par le principal. Penpot prend aussi en charge les variantes de composants (plusieurs versions regroupées, comme les états), une addition récente de l'outil.

On change la couleur du composant principal « Bouton ». Les copies…

  1. gardent leur ancienne couleur
  2. suivent le principal
  3. sont supprimées
Réponse

Les copies héritent du principal : c'est tout l'intérêt. Seuls les contenus (textes) restent propres à chaque copie.

Théorie 2/2 : dessiner les états

Le jour 13 a listé les états d'un bouton : repos, survol, focus, actif, désactivé. En conception, chaque état devient une version du composant : même géométrie, seuls changent le fond, le contour ou l'opacité. Conventions saines : survol = accent un cran plus foncé ; focus = contour de 2-3px dans une couleur contrastée (3:1) décalée de 2px, comme le font les navigateurs ; désactivé = saturation presque nulle, jamais juste « un peu plus pâle », sinon il reste confondu avec l'état normal. Gardez les états côte à côte sur le canevas : l'alignement et l'espacement identiques entre versions montrent que seule la couleur change.

L'indicateur de focus doit…

  1. être visible et contraster à 3:1 avec ce qui l'entoure
  2. être supprimé pour l'esthétique
  3. apparaître seulement au clic
Réponse

WCAG 2.4.7 exige un focus visible, 1.4.11 son contraste à 3:1. Le supprimer rend la navigation clavier aveugle.

Pratique (30 min)

  1. Dans Penpot, sélectionnez le bouton de votre carte (rectangle + texte groupés) et créez-en un composant.
  2. Dessinez les cinq états côte à côte : repos, survol, focus, actif, désactivé. Nommez chaque version (bouton/repos, bouton/survol…).
  3. Placez trois copies de l'état « repos » sur le board avec des libellés différents ; vérifiez que modifier le principal met à jour les formes sans toucher aux libellés.
  4. Mesurez le contraste de votre contour de focus contre le fond (WebAIM) : il doit atteindre 3:1.

Critère de réussite : un composant « Bouton » dans Assets, cinq états dessinés, trois copies liées, et un focus mesuré à 3:1 ou plus.

Tips agent : « Décris les cinq états d'un bouton sous forme de tableau : état, propriétés qui changent, valeur proposée à partir de mon accent #… » Piège : il oubliera l'état actif ou donnera un désactivé trop proche du repos. Preuve : comparez son tableau à votre dessin, et plissez les yeux devant repos/désactivé.

Synthèse (10 min)

Trois lignes : composant vs copie, ce qui reste lié et ce qui reste libre, les réglages des cinq états. Puis recréez les cinq états sans notes.

Jour 18 — Le wireframe

Objectif : esquisser une page en basse fidélité, sans couleur ni polices.

Théorie 1/2 : la basse fidélité protège les décisions

Un wireframe est le plan d'une page : des rectangles gris pour les images, des barres pour le texte, des libellés pour les actions. Sa pauvreté est volontaire : sans couleur ni typographie, personne ne discute du bleu du bouton — la conversation porte sur ce qui compte à ce stade : quelles informations, dans quel ordre, avec quelle priorité. Changer une structure coûte dix minutes en wireframe, dix heures en maquette aboutie. C'est aussi un outil de pensée : dessiner la page en gris oblige à décider du contenu réel — un vrai titre, pas « lorem ipsum » — avant de décider de son aspect.

Pourquoi le wireframe reste-t-il volontairement gris et sans style ?

  1. pour aller plus vite à dessiner, sans autre raison
  2. pour que la discussion porte sur la structure et le contenu, pas sur les couleurs
  3. parce que la couleur coûte cher à imprimer
Réponse

La basse fidélité isole les décisions de structure : tant que tout est gris, nul ne débat de la teinte du bouton.

Théorie 2/2 : le vocabulaire du wireframe

Cinq conventions suffisent : une barre épaisse pour un titre, des barres fines pour les lignes de texte, un rectangle croisé pour une image ou une vidéo, un rectangle plein avec libellé pour un bouton, et des annotations en marge pour ce que le dessin ne dit pas (« ce menu s'ouvre au clic »). On travaille d'abord à la taille la plus contraignante — le mobile — parce que le contenu qui tient en 375px de large tiendra partout (on y reviendra au jour 30). La question à se poser pour chaque bloc, dans l'ordre : est-il nécessaire ? est-il à la bonne place ? est-il à la bonne taille relative ?

Dans un wireframe, une image se représente par…

  1. un rectangle avec une croix en diagonale
  2. une photo floutée
  3. un carré noir
Réponse

Le rectangle croisé : universel, il dit « visuel ici » sans distraire.

Pratique (30 min)

  1. Choisissez la page d'accueil d'un site que vous connaissez bien. Listez au carnet ses blocs dans l'ordre vertical (bandeau, hero, trois arguments, témoignage, pied de page…).
  2. Dans Penpot, créez un board mobile (375×812) et redessinez cette page en wireframe : barres, rectangles croisés, boutons. Aucune couleur, aucune vraie police stylée.
  3. Vérifiez : chaque action est un bouton libellé, chaque texte a sa longueur réelle approximative, l'ordre des blocs suit la hiérarchie du jour 10.

Critère de réussite : un wireframe mobile complet, gris, où chaque bloc répond aux trois questions (nécessaire, place, taille relative).

Tips agent : « Voici la liste ordonnée des blocs de ma page : [collez]. Critique l'ordre du point de vue d'un visiteur qui découvre le service, et propose une seule amélioration. » Piège : il ne voit pas votre dessin — décrivez les blocs, pas vos intentions. Preuve : chaque critique cite le bloc et le visiteur concerné.

Synthèse (10 min)

Trois lignes : ce que la basse fidélité protège, les cinq conventions, les trois questions par bloc. Puis refaites le wireframe sur papier, sans notes.

Jour 19 — Du wireframe à la maquette

Objectif : appliquer palette, échelle et espacements à votre wireframe pour en faire une maquette.

Théorie 1/2 : une seule règle à la fois

La maquette (haute fidélité) est le wireframe habillé. Le passage se fait en couches, jamais tout à la fois : d'abord la typographie (appliquer les styles de la bibliothèque à chaque texte), puis la couleur (fond, textes, accent — la répartition 60-30-10), puis les espacements (tout en multiples de 8), et enfin les détails (coins, bordures, ombres discrètes, états). Ce ordre a une raison : chaque couche peut casser la précédente si on y touche plus tard — un texte qui change de corps déborde, une couleur d'accent appliquée trop tôt se disperse. Travailler en couches permet aussi de revenir d'un cran sans tout perdre.

Dans le passage wireframe → maquette, quelle couche vient en premier ?

  1. les ombres
  2. la couleur
  3. la typographie
Réponse

La typographie : la taille des textes fixe les dimensions de tout le reste. Couleur ensuite, espacements, détails.

Théorie 2/2 : le vrai contenu, toujours

La maquette se dessine avec le contenu réel — les vrais titres, les vrais libellés, une longueur de texte plausible. Le « lorem ipsum » cache les problèmes : il a une densité régulière que le français réel n'a pas (libellés longs, mots avec accents, capitales), et il dispense de décider ce que la page doit dire. Règle pratique : si le contenu définitif n'existe pas encore, écrivez-le vous-même, même imparfait — une maquette avec un vrai titre médiocre apprend plus qu'une maquette avec du faux latin parfait. C'est aussi le moment de tester les limites : le titre le plus long prévu, le nom d'utilisateur le plus long, la liste vide. Un design qui ne survit qu'au contenu idéal n'est pas fini.

Pourquoi bannir le lorem ipsum d'une maquette ?

  1. parce que le latin est ringard
  2. parce qu'un faux texte régulier cache les débordements et dispense de décider du contenu
  3. parce qu'il est payant
Réponse

Le vrai contenu révèle les vraies longueurs et les vrais choix. Le lorem ipsum reporte les deux au jour du développement — le plus mauvais moment.

Pratique (30 min)

  1. Dupliquez le wireframe du jour 18 sur un nouveau board (même structure, même ordre).
  2. Appliquez les couches dans l'ordre : styles de typographie de la bibliothèque, puis couleurs de la bibliothèque (60-30-10), puis espacements en multiples de 8, puis coins 8px et une ombre discrète sur la carte s'il y en a une.
  3. Remplacez tout faux texte par du vrai contenu écrit par vous ; testez le titre le plus long plausible.
  4. Squint test final : la hiérarchie voulue est-elle celle qui ressort ?

Critère de réussite : une maquette mobile finie, 100 % bibliothèque (couleurs et styles), vrai contenu, squint test conforme à la hiérarchie décidée.

Tips agent : décrivez votre maquette bloc par bloc avec ses valeurs : « Vérifie ma répartition 60-30-10 et mes hiérarchies de tailles ; signale tout ce qui sort de l'échelle. » Piège : il validera poliment si vous ne demandez pas les écarts. Exigez : « liste chaque valeur qui n'est pas dans mon échelle, une par ligne ». Preuve : recoupez un écart signalé dans Penpot.

Synthèse (10 min)

Trois lignes : l'ordre des couches, pourquoi le vrai contenu, ce que vérifie le squint test. Puis refaites le passage en couches sur un petit bloc sans notes.

Jour 20 — Poser une grille dans Penpot

Objectif : équiper un board desktop d'une grille 12 colonnes et aligner une maquette dessus.

Théorie 1/2 : la grille de l'outil

Le jour 11 a expliqué la grille à 12 colonnes ; Penpot la matérialise : sélectionnez un board, et dans le panneau de droite, la section « Guides » (ou « Grid ») permet d'ajouter une grille de colonnes — nombre, gouttière, marges. Réglages de départ sains pour un board 1440px : 12 colonnes, gouttière 24px, marges latérales 80 à 120px, ce qui laisse une zone utile de 1200px environ. La grille s'affiche ou se masque, elle ne s'exporte pas : c'est une aide au dessin, pas un élément du design. Une fois posée, chaque bloc de la maquette commence et finit sur des limites de colonnes ; les gouttières ne contiennent jamais de contenu.

La gouttière d'une grille…

  1. ne reçoit jamais de contenu
  2. accueille les petits textes
  3. mesure toujours 10px
Réponse

La gouttière est l'espace de séparation entre colonnes : y poser du contenu casse l'alignement de toute la grille.

Théorie 2/2 : desktop contre mobile

Sur desktop, la grille multiplie les blocs côte à côte (trois cartes de 4 colonnes). Sur mobile, une seule colonne de contenu : les blocs s'empilent. La grille mobile est donc plus simple — souvent 4 colonnes qui servent surtout à caler les marges latérales (16 à 24px) — et le vrai travail est l'ordre d'empilement : ce qui était côte à côte doit se succéder dans un ordre qui respecte la hiérarchie. Règle : l'ordre vertical mobile suit l'importance, pas la position desktop. Un encadré « appel à l'action » placé à droite sur desktop passe souvent avant le contenu secondaire sur mobile.

Sur mobile, l'ordre d'empilement des blocs suit…

  1. leur position gauche-droite sur desktop
  2. leur importance pour l'utilisateur
  3. leur taille
Réponse

L'importance : en une seule colonne, l'ordre de lecture est la hiérarchie, rendue littérale.

Pratique (30 min)

  1. Créez un board desktop 1440×900 et posez la grille : 12 colonnes, gouttière 24px, marges 96px.
  2. Déclinez la maquette mobile du jour 19 en desktop : même contenu, mais les blocs s'alignent sur les colonnes (ex. texte sur 7 colonnes, visuel sur 5 ; ou trois cartes de 4).
  3. Vérifiez chaque bord : il commence et finit sur une limite de colonne. Aucun contenu dans les gouttières ni les marges.
  4. Masquez puis réaffichez la grille : la page doit rester alignée sans elle.

Critère de réussite : une maquette desktop dont tous les bords tombent sur la grille, avec la même hiérarchie que la version mobile.

Tips agent : « Pour un board de 1440px, 12 colonnes, gouttière 24px, marges 96px, calcule la largeur d'une colonne et celle de 4 colonnes + 3 gouttières. » Piège : il arrondira peut-être sans le dire. Preuve : la colonne vaut (1440 − 192 − 11×24) ÷ 12 = 74px, vérifiez le calcul à la main.

Synthèse (10 min)

Trois lignes : les réglages de la grille desktop, la règle des gouttières, l'ordre d'empilement mobile. Puis recalculez la largeur de colonne sans notes.

Jour 21 — Le Flex layout

Objectif : construire un composant dont les espacements se maintiennent quand le contenu change.

Théorie 1/2 : des boîtes qui s'adaptent

Dans un dessin « libre », rallonger un titre décale tout à la main. Le Flex layout de Penpot (l'équivalent du flexbox des navigateurs, et de l'auto-layout de Figma) rend une boîte intelligente : ses enfants se rangent en ligne ou en colonne, avec un écart (gap) constant entre eux et un remplissage (padding) constant autour. Rallongez le titre, le bouton se décale ; ajoutez une ligne, la carte grandit — les espacements du jour 8 deviennent des propriétés de la boîte, pas des distances figées. C'est aussi ce qui rapproche le design du développement : la maquette décrit des règles (écart de 16, padding de 24), exactement comme le CSS qui la réalisera.

L'intérêt principal du Flex layout est…

  1. dessiner plus joli
  2. exporter des images plus légères
  3. que les espacements se maintiennent quand le contenu change
Réponse

L'écart et le remplissage sont des règles de la boîte : le contenu change, les espacements tiennent.

Théorie 2/2 : les réglages qui comptent

Cinq réglages couvrent l'essentiel : la direction (rangée ou colonne), l'écart entre enfants, le remplissage sur les quatre côtés, l'alignement (début, centre, espace entre) et le comportement de taille de chaque enfant : fixe (il garde sa taille), remplir (il prend la place disponible) ou contenu (il s'ajuste à ce qu'il contient). Une carte produit typique : direction colonne, écart 12, padding 24, image en « remplir » pour la largeur, textes en « contenu ». Le piège classique est de tout laisser en taille fixe : le composant redevient rigide et le Flex layout ne sert à rien.

Un bouton dont la largeur doit suivre son libellé est réglé sur…

  1. fixe
  2. contenu
  3. remplir
Réponse

« Contenu » : la boîte épouse le libellé, plus le padding. « Fixe » casse au premier libellé long, « remplir » étire le bouton à toute la largeur.

Pratique (30 min)

  1. Dans Penpot, reconstruisez la carte des jours 15-16 en Flex layout : sélectionnez le board ou le groupe, activez « Flex layout » dans le panneau de droite, direction colonne.
  2. Réglez : écart 12 ou 16, padding 24, bouton en « contenu », titre et texte en largeur « remplir ».
  3. Test de robustesse : doublez la longueur du titre, puis changez le libellé du bouton pour « Découvrir la collection complète ». Les espacements doivent tenir seuls.
  4. Dupliquez la carte en trois exemplaires dans une rangée en Flex layout (écart 24) : les trois cartes s'alignent sans réglage manuel.

Critère de réussite : la carte survit au titre long et au libellé long sans retouche manuelle, et trois copies s'alignent par la seule règle d'écart.

Tips agent : « Voici la structure de ma carte (image, titre, texte, bouton) et mes valeurs d'écart. Dis-moi quels réglages flex (direction, alignement, taille des enfants) tu choisirais, et pourquoi. » Piège : il décrira du CSS — traduisez vers les réglages Penpot, qui portent les mêmes noms. Preuve : appliquez et faites le test du titre long.

Synthèse (10 min)

Trois lignes : ce que le Flex layout remplace, les cinq réglages, les trois comportements de taille. Puis refaites la carte flexible sans notes.

Jour 22 — Accessibilité 1/3 : pour qui, pour quoi

Objectif : comprendre ce que recouvre l'accessibilité et ce que demande la norme WCAG.

Théorie 1/2 : l'accessibilité concerne tout le monde

Concevoir accessible, c'est concevoir pour des capacités variées : déficiences visuelles (daltonisme, malvoyance, cécité — environ 2 milliards de personnes vivent avec un trouble de la vision selon l'OMS), motrices (navigation au clavier, à la voix), auditives (sous-titres), cognitives (langage simple, cohérence). Mais le handicap est souvent temporaire ou situationnel : bras en écharpe, écran en plein soleil, connexion lente, fatigue, langue étrangère. Microsoft résume cette idée dans son Inclusive Design : le handicap est un décalage entre la personne et son contexte, pas une propriété de la personne. Une interface accessible est simplement une interface qui fonctionne dans plus de situations — les sous-titres servent au malentendant et au passager du train.

Le handicap « situationnel » désigne par exemple…

  1. une maladie rare
  2. lire un écran en plein soleil ou utiliser son téléphone à une main
  3. une panne de serveur
Réponse

Soleil, bras occupé, bruit : le contexte crée le handicap. Concevoir pour ces situations améliore l'expérience de tous.

Théorie 2/2 : WCAG et les quatre principes

Les WCAG (Web Content Accessibility Guidelines, du W3C — version 2.2 publiée en octobre 2023) sont la référence mondiale, déclinée en exigences légales dans l'Union européenne pour les services publics et, depuis la directive européenne sur l'accessibilité (applicable depuis juin 2025), une grande partie des services privés en ligne. Trois niveaux : A (minimum), AA (la cible standard), AAA (renforcé). Chaque critère se range sous quatre principes, mnémonique POUR : Perceptible (l'information peut être perçue : contrastes, alternatives textuelles), Opérable (on peut agir : clavier, cibles assez grandes, pas de piège), Compréhensible (langage clair, comportement prévisible), Robuste (compatible avec les technologies d'assistance). La référence filtrable officielle est le quickref du W3C.

« Pouvoir utiliser toute l'interface au clavier » relève du principe…

  1. Opérable
  2. Perceptible
  3. Robuste
Réponse

Opérable : agir, quelle que soit la manière. Le contraste relève du Perceptible, la compatibilité avec un lecteur d'écran du Robuste.

Pratique (30 min)

  1. Analyse du jour : parcourez la page d'accueil d'un site connu au seul clavier : Tab pour avancer, Maj+Tab pour reculer, Entrée pour activer. Comptez : voyez-vous toujours où vous êtes ? Atteignez-vous tout ?
  2. Lisez la checklist du A11Y Project et repérez trois critères que vous pouvez déjà vérifier sur une maquette (contraste, cibles, focus).
  3. Micro-exercice : au carnet, listez pour votre maquette du jour 19 trois situations de handicap (permanent, temporaire, situationnel) et ce qui dans votre design y répond déjà ou pas encore.

Critère de réussite : un parcours clavier documenté (ce qui marche, ce qui manque) et trois situations reliées à des éléments concrets de votre maquette.

Tips agent : « Explique-moi le critère WCAG 2.4.7 (focus visible) avec un exemple concret d'échec et un exemple de réussite. » Piège : les numéros de critères sont le genre de détail qu'un LLM confond (2.4.7 vs 2.4.11). Preuve : ouvrez le critère cité dans le quickref du W3C et comparez les intitulés.

Synthèse (10 min)

Trois lignes : les trois types de handicap, les quatre principes POUR, les niveaux A/AA/AAA. Puis redonnez les quatre principes sans notes.

Jour 23 — Accessibilité 2/3 : le contraste appliqué

Objectif : corriger une palette complète pour qu'elle passe le niveau AA partout où c'est exigé.

Théorie 1/2 : où le contraste s'applique

Le jour 7 a posé les seuils : 4,5:1 pour le texte courant, 3:1 pour le grand texte (24px, ou 18,5px en gras) et pour les éléments d'interface porteurs de sens — bordure d'un champ, icône sans libellé, contour de focus (critère 1.4.11, « contraste des contenus non textuels »). Deux exemptions à connaître : les éléments purement décoratifs et les composants désactivés ne sont pas soumis aux seuils, et les logotypes non plus. Un piège fréquent : le texte posé sur une image — le contraste se mesure alors contre la partie la plus claire de l'image sous le texte, et la solution honnête est un voile assombrissant ou un fond unicolore derrière le texte, pas l'espoir que la photo reste sombre.

Exercice généré à l'infini (JavaScript requis) : les seuils AA, texte normal et grand texte.

Théorie 2/2 : la méthode de correction

Corriger un contraste ne veut pas dire changer d'identité : on travaille la luminosité (le L de HSL, jour 5), qui est ce que le ratio mesure, en gardant teinte et saturation. Recette : pour un texte trop pâle sur fond clair, baissez sa luminosité par pas de 5 % jusqu'à passer 4,5:1 ; pour un accent trop clair portant du texte blanc, assombrissez l'accent ou passez le texte en foncé — mesurez les deux et gardez le meilleur ratio. Documentez ensuite le couple validé : « accent-700 (#…, 5,1:1 sur fond-page) : seule version de l'accent autorisée sous du texte ». La palette devient un système de couples autorisés, et le jour 36 en fera des tokens.

Pour faire passer un texte gris de 3,5:1 à 4,5:1 sur fond blanc, on…

  1. augmente la saturation du gris
  2. baisse la luminosité du gris (gris plus foncé)
  3. change la police
Réponse

Le ratio mesure la luminance : on baisse la luminosité. Saturation et police ne changent rien au calcul.

Pratique (30 min)

  1. Listez au carnet tous les couples texte/fond de votre maquette du jour 19 : corps sur fond, secondaire sur fond, blanc sur accent, accent sur fond, texte sur carte…
  2. Mesurez chaque couple dans le vérificateur WebAIM et notez le ratio à côté du couple.
  3. Pour chaque couple sous le seuil, corrigez par la luminosité (pas de 5 %) jusqu'au passage, et mettez à jour la couleur dans la bibliothèque Penpot.
  4. Rédigez la règle d'usage : pour chaque couleur, les fonds sur lesquels elle a le droit de porter du texte.

Critère de réussite : chaque couple de la maquette mesuré, chaque contrevenant corrigé et documenté, la bibliothèque Penpot à jour.

Tips agent : « Voici mes couples texte/fond : [hex]. Pour chacun, indique s'il passe AA texte normal, et propose une correction par la luminosité s'il échoue. » Piège : les ratios calculés de tête sont souvent faux (jour 7). Preuve : chaque couple corrigé est revérifié dans WebAIM — c'est le vérificateur qui fait foi.

Synthèse (10 min)

Trois lignes : les trois seuils et leurs cibles, la méthode de correction par la luminosité, pourquoi documenter les couples. Puis refaites une correction sans notes.

Jour 24 — Accessibilité 3/3 : cibles, focus, au-delà de la couleur

Objectif : appliquer les trois règles d'usage qui complètent le contraste.

Théorie 1/2 : la taille des cibles et le focus

Les WCAG 2.2 demandent que les cibles tactiles (boutons, liens, cases) mesurent au moins 24×24 pixels CSS (critère 2.5.8, niveau AA), avec quelques exceptions (liens dans le fil du texte, cibles espacées). Les guides des plateformes visent plus haut — 44×44 points chez Apple, 48×48 chez Google : retenez 24 comme plancher légal et 40-48 comme confort. Le focus visible (2.4.7) exige qu'on voie toujours quel élément est actif au clavier : ne supprimez jamais le contour de focus sans le remplacer par un indicateur au moins aussi visible, contrasté à 3:1. Enfin, le texte doit pouvoir être agrandi à 200 % sans perte de contenu (1.4.4) — une raison de plus pour les unités relatives du jour 29.

Le plancher WCAG 2.2 AA pour une cible tactile est…

  1. 16×16 px
  2. 44×44 px
  3. 24×24 px
Réponse

24×24 px CSS (2.5.8). Les 44×44 viennent des guides Apple/Google et du niveau AAA : un confort recommandé, pas le plancher AA.

Théorie 2/2 : ne jamais coder par la couleur seule

Le critère 1.4.1 interdit qu'une information repose sur la seule couleur : le lien doit être souligné ou distingué autrement que par sa teinte, l'erreur annoncée par une icône et un texte, le graphique en camembert légendé directement. Le test est simple : passez votre écran en niveaux de gris (les devtools Chrome l'émulent : panneau Rendering → « Emulate vision deficiencies », ou une capture convertie en noir et blanc) — tout ce qui disparaît était codé par la couleur seule. Ajoutez-y l'alternative textuelle : toute image qui porte de l'information a un texte équivalent (l'attribut alt, côté code ; côté design, on rédige ce texte dans la maquette). Une image purement décorative porte un alt vide pour être ignorée, pas un alt absente.

Le test rapide du critère « couleur seule » consiste à…

  1. regarder l'écran en niveaux de gris : rien d'important ne doit disparaître
  2. changer la résolution d'écran
  3. imprimer la page
Réponse

En niveaux de gris, toute information codée par la seule couleur s'efface. Ce qui survit est accessible aux daltoniens.

Pratique (30 min)

  1. Auditez votre maquette du jour 19 : chaque bouton et lien mesure-t-il au moins 24×24 (idéalement 40+) ? Corrigez les tailles dans Penpot.
  2. Vérifiez que chaque lien dans le texte est souligné (ou distingué autrement que par la couleur), et que chaque état d'erreur prévu a son icône et son message.
  3. Test niveaux de gris : exportez la maquette en PNG, convertissez-la en noir et blanc (n'importe quel visualiseur d'images le fait) : listez ce qui perd son sens.
  4. Rédigez le texte alternatif de chaque image informative de la maquette, dans le carnet.

Critère de réussite : toutes les cibles à 24px minimum, aucun sens porté par la couleur seule au test gris, et un alt rédigé par image informative.

Tips agent : « Rédige le texte alternatif de cette image : [décrire l'image et son rôle dans la page]. Règle : le rôle dans la page d'abord, la description ensuite, 125 caractères max. » Piège : il décrira l'image au lieu de sa fonction (« bouton bleu » au lieu de « rechercher »). Preuve : l'alt lu à voix haute remplace l'image sans perte.

Synthèse (10 min)

Trois lignes : les tailles de cible, la règle du focus, le test des niveaux de gris. Puis refaites l'audit cibles/focus/couleur sur un écran connu sans notes.

Jour 25 — Le langage clair

Objectif : écrire les textes d'une interface : libellés, messages d'erreur, boutons.

Théorie 1/2 : la microcopie

La microcopie est l'ensemble des petits textes d'une interface : libellés de boutons, titres de champs, messages d'erreur, confirmations, pages vides. Ses règles tiennent en quatre points : des verbes d'action pour les boutons (« Enregistrer le brouillon » bat « OK » : le libellé dit ce qui va se passer), des phrases courtes et actives (« Nous n'avons pas pu enregistrer » bat « Une erreur est survenue lors de l'enregistrement »), le vocabulaire de l'utilisateur plutôt que le jargon métier, et l'important d'abord (« 3 champs à corriger » avant la phrase de politesse). Un bon message d'erreur répond à trois questions : que s'est-il passé, est-ce grave, que faire maintenant. « Erreur 500 » n'en répond à aucune.

Le meilleur libellé pour le bouton final d'un formulaire d'inscription est…

  1. « OK »
  2. « Créer mon compte »
  3. « Soumettre le formulaire »
Réponse

Le verbe qui dit l'action et son bénéfice. « OK » ne dit rien, « Soumettre » décrit la mécanique, pas le résultat.

Théorie 2/2 : écrire pour tout le monde

Le langage clair est aussi un critère d'accessibilité (principe « Compréhensible ») : phrases de moins de 20-25 mots, voix active, un terme pour une chose (ne pas alterner « panier » et « sac »), pas de double négation, pas de référence à la forme ou à la position (« cliquez sur le bouton vert à droite » exclut celui qui ne voit ni la couleur ni l'écran — préférez « cliquez sur "Enregistrer" »). Pour le contenu long, la recommandation WCAG 3.1.5 (AAA) vise un niveau de lecture de fin de collège : ce n'est pas infantiliser, c'est respecter le temps de tous. Test maison : lisez le texte à voix haute ; toute phrase qui essouffle est à couper.

« Cliquez sur le bouton vert en haut à droite » est une mauvaise consigne parce que…

  1. elle dépend de la couleur et de la position, invisibles pour une partie des utilisateurs — mieux : nommer le bouton
  2. elle est trop longue
  3. le vert est agressif
Réponse

On nomme l'élément (« cliquez sur "Enregistrer" ») : le nom survit au lecteur d'écran, au niveaux de gris et au responsive.

Pratique (30 min)

  1. Analyse du jour : ouvrez le formulaire d'inscription ou de contact de deux sites connus. Relevez au carnet cinq libellés ou messages, et pour chacun : verbe d'action ou non ? jargon ou non ?
  2. Micro-exercice : réécrivez ces cinq textes banals — « Erreur : champ invalide », « Soumettre », « Votre requête a bien été prise en compte », « Mot de passe incorrect », « Chargement… » — en messages qui disent ce qui se passe et quoi faire.
  3. Appliquez : rédigez les textes réels de votre maquette du jour 19 (titres, boutons, messages d'erreur du formulaire s'il y en a un).

Critère de réussite : cinq textes réécrits au format « quoi + quoi faire », et les textes définitifs posés dans la maquette.

Tips agent : c'est le terrain où le LLM est fort : « Réécris ce message d'erreur pour un utilisateur non technique : que s'est-il passé, que faire. Ton direct, une phrase. » Piège : il enjolive et rallonge. Preuve : chaque message tient en une phrase, commence par le fait, finit par l'action.

Synthèse (10 min)

Trois lignes : les quatre règles de la microcopie, les trois questions d'un message d'erreur, pourquoi nommer plutôt que montrer. Puis réécrivez « Erreur 500 » sans notes.

Jour 26 — Les formulaires

Objectif : dessiner un formulaire complet avec ses labels, ses erreurs et ses états.

Théorie 1/2 : l'anatomie d'un champ

Un champ de formulaire a quatre parties : le label (toujours visible, au-dessus du champ — jamais un placeholder qui disparaît à la saisie : le placeholder est un exemple, pas un label), le champ lui-même (hauteur 40-48px, bordure contrastée à 3:1), l'aide éventuelle (format attendu, en texte permanent sous le label), et le message d'erreur (sous le champ, relié à lui, avec icône). Une colonne unique, des champs à la largeur de leur contenu attendu (un code postal n'a pas la largeur d'un e-mail), les champs liés groupés sous un titre de section : la recherche en ergonomie des formulaires (les travaux de Luke Wroblewski dès 2008) montre que ces choix réduisent mesurablement le temps de remplissage et les abandons.

Pourquoi le placeholder ne peut-il pas tenir lieu de label ?

  1. il est moche
  2. il disparaît à la saisie et son contraste est souvent insuffisant : l'utilisateur perd la consigne
  3. il ralentit la page
Réponse

Disparu au premier caractère tapé, le placeholder laisse l'utilisateur sans consigne. Le label reste visible en permanence, au-dessus du champ.

Théorie 2/2 : valider sans punir

La validation se règle comme une conversation polie : on ne signale pas une erreur pendant la frappe (trop tôt), on valide le champ quand on le quitte, et on re-valide en direct un champ corrigé. L'erreur se place à côté du champ concerné et se résume en haut si le formulaire est long. Les champs obligatoires se marquent d'un astérisque avec sa légende (« * obligatoire ») — ou mieux, on marque les champs facultatifs, s'ils sont minoritaires. Le bouton principal répète l'action (« Créer mon compte »), le bouton secondaire reste discret. Et la règle d'or : ne jamais vider un formulaire après une erreur — le pire des motifs, qui transforme une faute de frappe en abandon.

Le bon moment pour valider un champ est…

  1. à chaque touche pressée
  2. seulement à l'envoi du formulaire
  3. quand l'utilisateur quitte le champ, puis en direct pendant la correction
Réponse

Trop tôt, on punit la frappe en cours ; trop tard, on accumule. La validation à la sortie du champ, corrigée en direct, est le compromis éprouvé.

Pratique (30 min)

  1. Dans Penpot, dessinez un formulaire d'inscription : nom, e-mail, mot de passe (avec aide « 12 caractères minimum »), case d'acceptation, bouton « Créer mon compte ».
  2. Dessinez à côté le même formulaire en état d'erreur : e-mail invalide — le message sous le champ, l'icône, la bordure rouge contrastée, le résumé en haut.
  3. Vérifiez : labels permanents visibles, champs 44px de haut, bordures à 3:1, bouton à la hauteur et au libellé d'action, rien codé par la couleur seule.

Critère de réussite : deux versions du formulaire (repos, erreur) respectant les huit vérifications de la pratique.

Tips agent : « Liste les erreurs possibles de ce formulaire (nom, e-mail, mot de passe, case) et rédige chaque message au format quoi+quoi faire. » Piège : il oubliera les cas limites (champ vide, e-mail déjà pris, mot de passe trop court). Preuve : confrontez sa liste aux cas que votre formulaire accepte réellement — chaque rejet a son message.

Synthèse (10 min)

Trois lignes : les quatre parties d'un champ, le moment de la validation, la règle d'or du formulaire. Puis redessinez le champ en erreur sans notes.

Jour 27 — La navigation

Objectif : concevoir l'arborescence et les menus d'un petit site.

Théorie 1/2 : l'architecture de l'information

Avant les menus, le plan du site : quelles pages, groupées comment. La méthode éprouvée est le tri de cartes : écrire chaque contenu sur un papier, faire grouper par des utilisateurs, nommer les groupes avec eux. Deux règles tiennent sans recherche : un menu principal reste court (l'ordre de grandeur de 5 à 7 entrées vient des limites de la mémoire de travail — à prendre comme une prudence, pas une loi), et les libellés disent ce qu'on trouvera, pas le nom interne du service (« Tarifs » bat « Offre »). Le mythe des « trois clics » a été testé et démenti (les études de User Interface Engineering, 2003) : ce qui fait rester l'utilisateur n'est pas le nombre de clics mais la certitude, à chaque clic, d'être sur la bonne piste — le « parfum de l'information ».

La « règle des trois clics »…

  1. est une norme WCAG
  2. est un mythe : ce qui compte est que chaque clic rapproche visiblement du but
  3. interdit les menus profonds
Réponse

Testée et démentie : les utilisateurs ne abandonnent pas au quatrième clic, ils abandonnent quand la piste refroidit.

Théorie 2/2 : les patrons de navigation

Quatre patrons couvrent l'essentiel du web : la barre horizontale en en-tête (le standard, logo à gauche cliquable vers l'accueil), le menu hamburger pour le mobile (le libellé « Menu » à côté de l'icône améliore sa découvrabilité), le fil d'Ariane qui dit où l'on est dans l'arborescence (Accueil › Rubrique › Page) et le pied de page, qui reçoit tout ce qui n'a pas sa place dans le menu principal (mentions, contact, plan du site). Sur chaque page, trois repères doivent répondre « où suis-je » : l'entrée de menu active distinguée (pas par la couleur seule), le titre de page qui reprend le libellé cliqué, et le fil d'Ariane dès que le site dépasse deux niveaux.

Le fil d'Ariane devient utile…

  1. dès que le site dépasse deux niveaux de profondeur
  2. seulement sur les sites d'administration
  3. jamais, c'est dépassé
Réponse

Il répond à « où suis-je » dans les arborescences profondes — documentation, e-commerce, administration.

Pratique (30 min)

  1. Analyse du jour : sur service-public.fr, repérez les trois repères « où suis-je » sur une page profonde. Notez le nombre d'entrées du menu principal et les libellés choisis.
  2. Micro-exercice : inventez l'arborescence d'un site de boulangerie : 6 à 10 pages, groupées, libellés au vocabulaire du client. Dessinez-la au carnet.
  3. Dans Penpot, dessinez l'en-tête desktop (barre horizontale, entrée active distinguée) et sa version mobile (hamburger + libellé « Menu ») de ce site.

Critère de réussite : une arborescence complète au carnet, deux en-têtes dessinés, et les trois repères d'un site réel relevés.

Tips agent : « Voici mes 12 contenus : [liste]. Propose un regroupement en 5-7 entrées de menu avec des libellés au vocabulaire du client, et justifie chaque groupe en une ligne. » Piège : il utilisera votre vocabulaire interne. Exigez : « reformule chaque libellé comme ce que le visiteur cherche ». Preuve : chaque contenu de la liste apparaît dans un groupe, aucun n'est perdu.

Synthèse (10 min)

Trois lignes : le tri de cartes, le mythe des trois clics, les trois repères « où suis-je ». Puis redessinez votre arborescence sans notes.

Jour 28 — Bilan du module 2 : refonte accessible

Objectif : refondre une page réelle dans Penpot en appliquant toutes les règles du module.

Théorie 1/2 : la méthode de refonte

Refondre n'est pas redessiner au goût : c'est corriger contre des règles. La méthode en quatre temps : auditer d'abord (la grille à six critères du jour 14, plus les contrôles d'accessibilité des jours 22-24 : contraste des couples, tailles des cibles, couleur seule), prioriser ensuite — les fautes qui empêchent l'usage (contraste du texte courant, focus, cibles) avant les fautes de confort (rythme, alignements) ; corriger dans l'outil, en couches (typographie, couleur, espacements, détails, jour 19) ; prouver enfin : chaque correction livrée avec sa mesure avant/après. Ce format « problème, règle, correction, preuve » est exactement celui d'un rapport d'audit professionnel — le jour 28 est un entraînement à en écrire.

Théorie 2/2 : ce qu'on garde, ce qu'on change

Une refonte respecte ce qui fonctionne : la structure d'information, les contenus, les conventions que les utilisateurs ont apprises (jour 12). On change ce qui échoue aux mesures, pas ce qui déplaît. Deux garde-fous : toute correction qui casse une autre règle est refusée (assombrir un texte sous 12px n'est pas une correction), et la version refondue doit passer le même audit sans faute nouvelle. Gardez l'avant et l'après côte à côte : la comparaison est votre premier livrable de designer, et elle fera partie du projet final.

Dans une refonte, on corrige en priorité…

  1. ce qui nous déplaît esthétiquement
  2. ce qui échoue aux mesures et empêche l'usage (contraste, cibles, focus)
  3. les couleurs d'abord
Réponse

L'usage d'abord, mesuré ; le goût ensuite. Un audit qui commence par « je n'aime pas ce bleu » n'est pas un audit.

Pratique (30 min)

  1. Choisissez une page réelle visiblement perfectible (site d'association, de mairie, de petit commerce).
  2. Auditez-la : grille à six critères + contrôles d'accessibilité. Rédigez six constats mesurés au format « problème, règle, correction ».
  3. Dans Penpot, refondez la zone la plus fautive (l'en-tête, une carte, le formulaire) : wireframe rapide puis maquette en couches, avec votre bibliothèque.
  4. Documentez l'avant/après : une capture de chaque, et la mesure qui prouve chaque correction (ratio avant → ratio après).

Critère de réussite : un audit de six constats mesurés, une zone refondue dans Penpot, et un avant/après documenté avec ses preuves chiffrées.

Tips agent : « Voici mon audit (6 constats mesurés) et mes corrections. Vérifie qu'aucune correction n'introduit une faute nouvelle (contraste, cible, couleur seule) et signale tout constat sans mesure. » Piège : il ne peut pas mesurer — il raisonne sur vos chiffres. Preuve : chaque « après » est re-mesuré dans WebAIM ou l'inspecteur, jamais repris de sa réponse.

Synthèse (10 min)

Trois lignes : les quatre temps d'une refonte, la priorité usage/confort, le format du rapport. Puis récitez la méthode sans notes — elle servira au projet du module 4.

Utile ? Dites-nous ce qu'il faut mesurer ensuite.

Commentaires

Ni compte ni traceur : un commentaire est lu par un humain avant d'apparaître.