Construisez la couverture autour des tâches client
Listez les itinéraires et résultats qui créent de la valeur : trouver un service, rechercher, ajouter un article, réserver, se connecter, demander de l’aide ou payer. Pour chacun, nommez les composants qui peuvent changer de forme ou échouer : navigation, filtres, cartes, tableaux, images, bannières, formulaires, tiroirs et widgets embarqués. Testez les largeurs où votre contenu devient contraint, pas simplement un catalogue des modèles de téléphones actuels. Testez juste en dessous, à et juste au‑dessus de chaque point de rupture.
Incluez des téléphones étroits et de largeur moyenne, une largeur de type tablette, un ordinateur portable, un grand bureau, et le mode paysage lorsque cela change la tâche.
Utilisez des titres longs, résultats vides, erreurs de validation, badges de prix, adresses complètes et libellés plus longs quand ces états existent.
Prouvez la réorganisation (reflow), la lecture et le zoom
Confirmez que la page possède un paramètre viewport approprié, puis recherchez le défilement horizontal au niveau de la page. Images fixes, champs larges, marges négatives, panneaux hors‑toile et bannières sont des causes courantes. Le critère Reflow de la WCAG 2.1 décrit un contenu en défilement vertical à une largeur équivalente à 320 pixels CSS, incluant un viewport de 1280 pixels à un zoom de 400 %. Si ce critère est dans le périmètre, testez le scénario de zoom réel. Une carte, une vidéo ou un tableau de données peut nécessiter une mise en page bidimensionnelle, mais maintenez ce défilement à l’intérieur du composant et laissez la page environnante se réorganiser.
Vérifiez en‑têtes, contenu principal, pieds de page, barres fixes, dialogues et résumés d’erreur à chaque limite testée.
Réorganisez l’information pour un écran étroit ; ne supprimez pas silencieusement une exigence, un détail de prix ou une voie d’aide.
Soumettez le contenu et les formulaires à rude épreuve
Les opérations sur le contenu peuvent provoquer des échecs responsive sans une publication CSS. Testez le titre approuvé le plus long, plusieurs badges, une image manquante, un filtre sélectionné, un avertissement légal volumineux et un champ rempli par le navigateur. Quand les colonnes se superposent, vérifiez que l’ordre de lecture et l’ordre clavier restent cohérents. Complétez le formulaire réel sur un petit appareil : ouvrez les contrôles, corrigez une erreur et soumettez. Testez les widgets tiers dans une page proche de la production car leur conteneur, état de consentement, polices et styles peuvent modifier le résultat.
Reflétez les longueurs et combinaisons maximales probables, mais n’incluez pas de données client ou de paiement dans les preuves QA.
Ouvrez avis, chat, promotions et messages de validation ensemble ; aucun ne doit couvrir l’action principale ou le champ focalisé.
Exercez chaque chemin d’entrée
Un grand écran n’assure pas une souris, et un petit écran n’assure pas seulement le tactile. La media feature hover teste si une entrée principale peut survoler de manière pratique, donc le survol doit améliorer l’expérience plutôt qu’être l’unique voie vers une action ou une explication. Testez l’utilisation au clavier et au pointeur sur bureau, les tapes et le défilement sur un appareil tactile, et les appareils à entrées mixtes lorsque pertinent. Passez en revue boutons de fermeture compacts, incréments, chips, calendriers et actions par icône. Le critère WCAG 2.2 Target Size (Minimum) spécifie une taille cible de 24 par 24 pixels CSS avec des exceptions définies, incluant l’espacement et les liens en ligne. C’est un critère avec périmètre et exceptions, pas une promesse que chaque contrôle de 24 pixels soit également facile pour tout le monde.
Parcourez la page avec Tab. Le focus doit rester visible, suivre un ordre logique et entrer/sortir menus et dialogues de façon prévisible.
Rendez une révélation essentielle disponible par focus, tape ou un contrôle visible, et évitez un comportement confus au premier tap.
Vérifiez les ressources et la performance sous contrainte
Une image peut s’adapter à son conteneur et pourtant être le mauvais fichier pour l’appareil. Vérifiez que les médias restent contenus, réservent l’espace de mise en page lorsque applicable, conservent le recadrage utile et requièrent des candidates appropriées. Srcset et sizes donnent au navigateur des informations pour choisir parmi les sources d’image fournies ; ils ne garantissent pas une requête particulière. Utilisez le throttling des DevTools pour découvrir les problèmes tôt, mais ses contrôles CPU et réseau simulent des conditions relatives à la machine de développement. Recontrôlez les parcours clés sur un appareil réel et une connexion réelle. Inspectez polices, médias héros, carrousels, travail côté client et scripts tiers pour retards, déplacements ou taps bloqués.
Capturez l’itinéraire, le viewport, la connexion réelle ou simulée, et ce qui est devenu lent ou instable ; comparez des conditions similaires.
Quand c’est sûr, retardez les embeds non essentiels dans une build de test pour savoir si la tâche principale reste utilisable.
Corrigez comme un travail proactif d’uptime
Pour Status Is UP, la préparation responsive est une optimisation proactive de la disponibilité : identifiez un chemin appareil bloquant l’utilisateur, corrigez sa cause, prouvez la réparation et empêchez la récurrence. Ce n’est pas une affirmation qu’une alerte de monitoring peut juger chaque défaut de mise en page ou d’interaction. Priorisez par impact sur la tâche et portée. Avant le déploiement, testez les largeurs adjacentes et le parcours modifié sur du matériel réel. Prévoyez un rollback pour les changements de navigation partagée, styles, scripts, paiements ou intégrations. Après la mise en production, répétez les étapes de preuve et joignez les éléments de preuve à l’enregistrement du changement.
Indiquez l’itinéraire, l’appareil ou viewport, l’orientation, l’entrée, l’état, le résultat attendu, le résultat réel et une capture anonymisée.
Privilégiez une correction de composant, règle de mise en page, token ou livraison d’image plutôt qu’un contournement spécifique à un itinéraire ; donnez aux exceptions un propriétaire et un plan de suppression.