La balise <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=no"> a une histoire ancienne : elle date d’une époque où certains sites, mal responsives, préféraient empêcher le zoom plutôt que corriger leur mise en page qui se déformait au pincement. Le consensus dans la communauté du développement web a évolué depuis longtemps, et cette pratique est considérée comme un antipattern reconnu. Pourtant, elle réapparaît régulièrement, en 2024, dans des thèmes WordPress récents, généralement sans que personne ne l’ait décidé consciemment.
Ce billet ne traite pas du zoom navigateur natif en général (comportement du navigateur, raccourcis Ctrl + / Ctrl -), mais spécifiquement de ce réglage qui, lui, désactive délibérément le zoom tactile par pincement sur mobile, quelle que soit la volonté de la personne qui consulte le site.
Ce qu’on voit
Le motif se répète presque à l’identique d’un projet à l’autre : un thème acheté sur une marketplace, ou un starter-kit interne conservé depuis plusieurs années, inclut encore dans son fichier header.php une balise viewport avec user-scalable=no ou une valeur équivalente comme maximum-scale=1.0 combinée à user-scalable=no. Personne ne l’a ajoutée intentionnellement sur le projet en cours : elle vient d’un modèle copié, souvent hérité d’un générateur de code en ligne ou d’un tutoriel d’une dizaine d’années qui recommandait cette pratique pour « stabiliser l’affichage mobile ».
<!-- Ce qu'on trouve encore, tel quel, dans certains header.php -->
<meta name="viewport"
content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">Pourquoi c’est un problème
Le critère 1.4.4 « Redimensionnement du texte » de WCAG (niveau AA) exige que le texte puisse être agrandi jusqu’à 200 % sans perte de fonctionnalité, en utilisant les fonctionnalités standard du navigateur. Sur mobile, cette fonctionnalité standard est le zoom par pincement. En le désactivant explicitement via user-scalable=no, un site empêche une personne malvoyante — qui n’utilise pas nécessairement de technologie d’assistance dédiée, mais qui a simplement besoin d’agrandir le texte pour le lire confortablement — d’accéder au contenu dans des conditions raisonnables. C’est l’un des rares antipatterns qui produit un échec de conformité avec une seule ligne de code, sans qu’aucune autre partie du site ne soit en cause.
La justification historique de cette pratique — éviter que la mise en page ne se déforme au zoom — ne tient plus depuis l’adoption généralisée du CSS responsive et des unités relatives. Un site correctement construit avec des unités flexibles (rem, pourcentages, clamp()) supporte un agrandissement sans casser sa mise en page ; bloquer le zoom pour masquer un problème de mise en page non résolu revient à cacher un défaut plutôt qu’à le corriger.
Quoi faire
La correction est presque toujours la même et prend quelques minutes : retirer user-scalable=no et la limite maximum-scale de la balise viewport, pour ne conserver que ce qui est réellement nécessaire.
<meta name="viewport" content="width=device-width, initial-scale=1.0">Sur un thème basé sur wp_head(), cette balise est souvent injectée par le thème lui-même via la fonction wp_head ou directement codée en dur dans header.php : il faut vérifier les deux sources, car un plugin de performance ou de cache peut parfois réinjecter sa propre balise viewport, créant un doublon dont l’un des deux exemplaires bloque encore le zoom.
- Rechercher
user-scalabledans l’ensemble des fichiers du thème actif et de l’enfant éventuel. - Vérifier aussi les plugins qui génèrent du HTML dans
<head>(optimisation, AMP, certains constructeurs de page). - Retirer la restriction et ne garder que
width=device-width, initial-scale=1.0. - Tester le zoom par pincement sur un vrai appareil mobile, pas seulement dans les outils de développement du navigateur.
- Vérifier que la mise en page reste lisible à 200 % de zoom sur les pages les plus denses (tableaux, formulaires).
Sur un audit, la présence de
user-scalable=noest l’un des tout premiers points qu’on vérifie, avant même de lancer un scan automatisé complet : c’est rapide à repérer, presque toujours facile à corriger, et son impact réel sur les personnes malvoyantes est immédiat et disproportionné par rapport à l’effort de correction.
En résumé
user-scalable=no n’est presque jamais un choix assumé sur les projets récents : c’est un reliquat qui se propage par copie de modèles anciens ou de starter-kits jamais remis à jour. Sa correction est rapide et ne casse quasiment jamais l’expérience réellement voulue par le design, puisqu’un site responsive moderne n’a besoin d’aucune restriction du zoom pour rester lisible. Vérifier sa présence devrait faire partie des tout premiers réflexes de tout audit d’accessibilité mobile.
