Un titre déborde, une carte devient trop étroite ou un menu masque une action : le problème responsive se décrit d’abord sur un composant et une largeur précise. Le travail consiste à adapter la mise en page, pas à remplacer automatiquement votre identité visuelle.
Ce guide porte sur les choix de réalisation : largeur disponible, points de changement, composants réutilisés, images et vérifications. Le guide sur le parcours sur smartphone traite séparément les étapes d’une tâche et leur résultat réel. Aucun score, classement ou gain commercial n’est garanti ici.
Définir ce qui doit rester accessible
Avant de modifier une grille, listez les informations et actions qui doivent rester disponibles : titre, description, conditions, accès aux détails et prochaine étape. Notez le composant concerné, sa position et le problème observé. Une capture sert à décrire un état, pas à démontrer à elle seule que le parcours fonctionne.
Exemple illustratif : une carte présente une prestation et un lien vers sa fiche. Sur une largeur réduite, le titre passe sur plusieurs lignes. Le besoin est de conserver une lecture claire et le lien accessible ; cela ne justifie pas de couper le nom ou de masquer une condition importante.
Les priorités de contenu relèvent aussi de l’organisation d’un site vitrine. Distinguez-les du réglage CSS : un bloc peut tenir dans l’écran tout en présentant une information insuffisante.
Faire évoluer la mise en page quand le contenu le demande
Le responsive combine des mises en page flexibles et, lorsque nécessaire, des règles conditionnelles. La documentation MDN sur le responsive présente notamment Grid, Flexbox et les media queries. Le mobile-first part d’une présentation pour une largeur réduite puis ajoute des dispositions lorsque l’espace le permet.
Ne choisissez pas vos points de changement uniquement d’après une liste de téléphones. Réduisez progressivement la largeur et observez quand les contenus deviennent difficiles à lire ou à utiliser. Une grille peut passer à une seule colonne ; une navigation demande parfois une interaction différente, à vérifier séparément.
Conservez une trace du changement attendu. Deux colonnes ne doivent pas simplement devenir deux colonnes comprimées. Vérifiez aussi les largeurs intermédiaires : tester seulement un grand écran et un petit téléphone peut laisser passer un défaut entre les deux.
Adapter un composant à l’espace qu’il reçoit
Une carte peut apparaître dans une grande grille ou une zone plus étroite. Sa place disponible n’est pas toujours décrite par la largeur de la fenêtre. Les container queries décrites par MDN permettent de conditionner certains styles aux dimensions d’un conteneur déclaré.
Retenez cette approche lorsqu’elle répond à un usage réel du composant. Identifiez le conteneur, les variantes nécessaires et les endroits où la carte est réutilisée. Vérifiez ensuite ces endroits, pas seulement une page de démonstration. Le choix dépend aussi des navigateurs retenus pour la recette.
Une nouvelle règle de disposition n’autorise pas un changement silencieux de couleurs, de typographie ou de boutons. Séparez l’adaptation technique d’une proposition de nouvelle charte. Un composant qui fonctionne déjà ne doit pas être complexifié sans besoin identifié.
Vérifier le cadrage et le fichier réellement chargé
Réduire l’affichage d’une image ne suffit pas à vérifier quel fichier le navigateur télécharge. La documentation MDN sur les images responsives distingue le choix de résolution et l’adaptation du cadrage. Les attributs srcset et sizes et l’élément picture répondent à des besoins différents.
Pour chaque image importante, relevez sa place dans la mise en page, les variantes disponibles et ce qui doit rester visible. Une photo recadrée peut perdre une information ; une capture de réalisation doit continuer à représenter le site montré. Ne remplacez pas une capture manquante par une illustration présentée comme réelle.
Contrôlez le fichier choisi dans les conditions du test, sa disponibilité et les dimensions réservées. Vérifiez aussi le retour à une largeur plus grande. Le nom d’une variante mobile ne prouve pas qu’elle est effectivement utilisée, ni qu’elle améliore les performances mesurées.
Tester le réagencement sans cacher les difficultés
Le zoom et la largeur réduite doivent faire partie des vérifications. Le W3C explique le critère de réagencement : pour les contenus concernés, l’information et les fonctions doivent rester accessibles sans imposer un défilement dans deux dimensions. Certaines présentations nécessitant deux dimensions ont des exceptions.
Examinez les titres, les liens, les aides, les tableaux et les panneaux ouverts. Un élément absent de la capture n’est pas forcément supprimé : vérifiez s’il reste accessible. Inversement, cacher un débordement ne suffit pas à corriger le contenu coupé ou l’action devenue impossible.
Consignez ce qui est testé et ce qui ne l’est pas. Une page qui tient dans une largeur réduite ne certifie pas l’accessibilité de tout le site. Les contrôles de clavier, de focus et les autres exigences demandent leur propre vérification.
Rejouer les cas réels avant de valider
Le mode appareil de Chrome aide à simuler des dimensions et certaines contraintes. Il ne reproduit pas intégralement un téléphone. Complétez les observations par les appareils et navigateurs retenus, en distinguant simulation et test réel.
La fiche de recette peut indiquer la page, le composant, la largeur, l’appareil, l’état ouvert ou fermé, le constat et le résultat attendu. Reprenez les mêmes cas après correction et contrôlez les autres pages qui réutilisent le composant. Ne déclenchez pas de vraie commande ou de message client sans cadre de test.
Si votre site demande une adaptation, partagez la page et le problème observé. Le périmètre peut concerner un composant ou plusieurs modèles de pages, sans présumer qu’une refonte complète est nécessaire. Les modifications, la recette et les limites seront définies avant réalisation.
