La plupart des thèmes WordPress sont encore pensés desktop-first, avec une passe d’adaptation mobile ajoutée en fin de projet. Cette approche condamne presque systématiquement les zones tactiles : les boutons dimensionnés confortablement pour un curseur de souris deviennent trop petits une fois transposés sur un écran tactile, et personne ne reprend le sujet une fois le design validé.
Ce billet détaille l’architecture d’un thème pensé mobile-first dès le départ, avec les zones tactiles conformes intégrées comme contrainte de conception plutôt que comme correctif de fin de course.
Pourquoi partir du mobile change la donne
Concevoir d’abord pour le plus petit écran et l’interaction tactile oblige à trancher tôt les questions de densité : combien d’éléments interactifs peuvent tenir sur une largeur de 360 pixels sans tomber sous la taille minimale recommandée. Ce travail, fait en premier, se répercute naturellement vers le haut : il est plus simple d’espacer davantage des boutons déjà bien dimensionnés que de rétrécir des boutons pensés trop petits.
L’arborescence des tokens de zone tactile
Plutôt que de fixer une taille de bouton dans chaque composant, l’architecture retenue centralise la contrainte dans des tokens dédiés, déclinés dans theme.json et repris par chaque composant du thème :
theme/
├── theme.json
│ └── settings.custom.zoneTactile
│ ├── minimum: "44px"
│ └── espacement: "8px"
├── parts/
│ ├── header.html
│ └── navigation-mobile.html
├── patterns/
│ ├── bouton-principal.html
│ └── carte-produit.html
└── assets/
└── css/
└── zones-tactiles.css
Chaque composant interactif du thème (bouton, lien de carte, icône cliquable) référence ce token plutôt que de définir sa propre dimension, garantissant une cohérence de bout en bout et un point unique de mise à jour si la cible évolue.
La densité d’interface, du mobile vers le desktop
L’erreur classique consiste à garder la même densité d’éléments interactifs sur toutes les tailles d’écran, en réduisant simplement leur taille sur mobile. L’architecture mobile-first inverse la logique : la densité maximale est calculée pour le mobile, avec des zones tactiles conformes, puis peut augmenter progressivement sur desktop où le pointeur précis autorise des cibles plus rapprochées — sans jamais redescendre sous le seuil mobile par erreur d’héritage CSS.
Le cas du menu de navigation
Le menu principal illustre bien cette logique : sur mobile, il s’ouvre en plein écran avec des liens espacés d’au moins 8 pixels et une hauteur de zone cliquable de 44 pixels minimum. Sur desktop, le même menu peut se densifier en barre horizontale, tout en conservant une hauteur de zone cliquable équivalente pour ne pas pénaliser un utilisateur tactile sur tablette qui verrait s’afficher la version desktop.
Le clavier n’est pas optionnel sur un thème mobile-first
Un piège fréquent : concevoir la navigation mobile uniquement pour le tactile, en oubliant qu’elle doit rester utilisable au clavier — pour les utilisateurs de claviers externes sur tablette, ou les technologies d’assistance qui simulent une navigation séquentielle. Le composant de menu mobile de ce thème est donc testé systématiquement avec un clavier externe branché sur tablette, en plus des tests tactiles.
Vérifier la conformité en continu
Un script de vérification automatisée, exécuté à chaque build du thème, parcourt les composants et signale toute zone interactive dont la hauteur ou la largeur calculée descend sous 44 pixels, avant même que la revue humaine n’intervienne.
Une zone tactile conforme coûte cher à ajouter après coup sur cinquante composants. Elle ne coûte presque rien si elle est posée comme token dès la première ligne du thème.
En résumé
Une architecture de thème mobile-first accessible repose sur des tokens de zone tactile centralisés, une densité d’interface pensée à rebours du sens habituel, et une vérification systématique du clavier même sur les composants pensés pour le tactile. Ce sont des décisions d’architecture, pas des ajustements de style, et elles se prennent avant d’écrire le premier composant.
