Le WordPress d'aujourd'hui, décodé pour les développeurs

Accessibilité

Un thème qui déborde dès qu’on applique l’espacement de texte, WCAG 1.4.12

Le critère WCAG 1.4.12 impose de supporter un espacement de texte augmenté sans perte de contenu. Sur un thème mal préparé, cet espacement fait exploser des blocs entiers de mise en page.

Par Clément Hadrot • 30 septembre 2025 • 4 min de lecture • Aucun commentaire
Un thème qui déborde dès qu'on applique l'espacement de texte, WCAG 1.4.12

Un visiteur malvoyant augmente l’espacement du texte depuis les réglages de son navigateur ou une extension dédiée : sur la majorité des thèmes WordPress testés, rien de grave ne se produit. Sur un thème vitrine construit autour de cartes à hauteur fixe, le résultat est tout autre : les textes débordent de leur conteneur, se superposent aux éléments voisins, ou disparaissent purement et simplement derrière un overflow: hidden mal anticipé.

Le critère WCAG 1.4.12 « Text Spacing », introduit avec la version 2.1 des Web Content Accessibility Guidelines, impose qu’aucune perte de contenu ni de fonctionnalité ne survienne lorsqu’un utilisateur applique un ensemble précis de valeurs d’espacement : une hauteur de ligne d’au moins 1,5 fois la taille de police, un espacement après chaque paragraphe d’au moins 2 fois la taille de police, un espacement entre lettres d’au moins 0,12 fois la taille de police, et un espacement entre mots d’au moins 0,16 fois la taille de police. Ce n’est pas une recommandation vague : ce sont des ratios chiffrés, testables mécaniquement.

Pourquoi tant de thèmes échouent sur ce critère précis

La cause la plus fréquente tient à des habitudes de mise en page héritées d’un design figé en pixels : une carte produit dont la hauteur est fixée à height: 220px plutôt que min-height, un titre limité à une ligne par white-space: nowrap, ou un conteneur de résumé d’article tronqué par overflow: hidden combiné à une hauteur fixe. Tant que le texte reste à sa taille et son interligne d’origine, tout tient dans la boîte. Dès que l’espacement grandit de 50 % ou plus, le texte a simplement besoin de plus de place verticale, et la boîte rigide ne le lui accorde pas.

Un deuxième piège, plus discret, concerne les menus de navigation à hauteur fixe : un menu horizontal dont chaque lien tient dans une case de hauteur constante peut voir ses libellés se chevaucher verticalement dès que l’espacement entre lignes augmente, si le lien contient plusieurs mots qui passent à la ligne.

Reproduire le réglage sans extension tierce

Il n’est pas nécessaire d’installer une extension de navigateur pour tester ce critère : un simple signet JavaScript (bookmarklet) suffit à injecter une feuille de style respectant exactement les ratios exigés par 1.4.12 :

javascript:(function(){
  var style = document.createElement('style');
  style.innerHTML = '* { line-height: 1.5 !important; ' +
    'letter-spacing: 0.12em !important; ' +
    'word-spacing: 0.16em !important; } ' +
    'p { margin-bottom: 2em !important; }';
  document.head.appendChild(style);
})();

En collant ce code dans la barre d’adresse (précédé de javascript:) ou en l’enregistrant comme signet, n’importe quelle page se retrouve instantanément dans les conditions du test, sans dépendre d’un plugin qui pourrait ne pas être à jour avec la dernière version des critères.

L'essentiel à retenir : Le critère 1.4.12 fixe des valeurs précises d'interligne et d'espacement à supporter ; Les hauteurs et largeurs fixées en pixels sont la cause la plus fréquente du débordement ; Un bookmarklet de test reproduit le réglage sans dépendre d'une extension du navigateur

Corriger sans tout reconstruire

La correction la plus efficace, dans la grande majorité des cas, consiste à remplacer systématiquement les hauteurs fixes par des hauteurs minimales, et à supprimer les troncatures automatiques par overflow: hidden sur des conteneurs de texte :

  • Remplacer height par min-height sur les cartes, encarts et blocs de résumé.
  • Retirer white-space: nowrap des libellés de menu qui peuvent légitimement passer à la ligne.
  • Vérifier les grilles CSS avec grid-template-rows fixe, qui peuvent tronquer silencieusement une cellule sans qu’aucune erreur ne remonte dans la console.
  • Tester systématiquement les composants qui utilisent -webkit-line-clamp pour limiter un texte à un nombre de lignes : ce mécanisme reste globalement compatible, mais la troncature devient plus agressive avec un espacement élargi.

Sur un thème d’agence immobilière que nous avons repris récemment, la correction a porté sur douze composants distincts, dont neuf partageaient la même origine : une bibliothèque de cartes construite sur un système de grille avec hauteur de ligne figée à trois lignes par -webkit-line-clamp: 3 couplé à une hauteur fixe du conteneur parent, ce qui doublait l’effet de troncature au lieu de le neutraliser.

Un point d’attention sur les composants tiers

Les widgets de blocs fournis par des extensions tierces, notamment les carrousels et les grilles de témoignages, sont statistiquement les composants les plus susceptibles d’échouer sur ce critère, car ils sont souvent conçus et testés uniquement à la taille de police par défaut. Il est utile de les inclure explicitement dans la checklist de recette avant chaque mise à jour majeure de thème.

En résumé

Le critère 1.4.12 se distingue par sa précision : il ne s’agit pas d’un jugement subjectif sur la lisibilité, mais d’un ensemble de ratios vérifiables avec un simple bookmarklet. Concevoir des composants avec des hauteurs minimales plutôt que fixes, dès la phase d’intégration, évite la majorité des régressions constatées sur ce point précis lors des audits RGAA.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi