Un site WordPress peut avoir l’air propre, moderne, bien tenu.
Les pages s’affichent, le menu fonctionne, les blocs sont bien rangés, et tout le monde se dit que la base est saine.
Puis on commence à tester autrement.
Au clavier. Avec un lecteur d’écran. Avec un zoom un peu fort. En remplissant un formulaire trop vite.
Et là, le décor change. Ce n’est pas forcément spectaculaire. C’est même souvent l’inverse : des détails discrets, presque banals, qui suffisent à casser la compréhension ou à rendre l’usage laborieux.
Sur WordPress, les problèmes d’accessibilité viennent rarement d’une seule source.
Ils naissent plutôt d’un empilement : un thème un peu approximatif, un plugin trop bavard, un bloc natif à reprendre, un shortcode ancien, un peu de HTML sale, quelques attributs hérités, et un historique technique qui s’est épaissi avec le temps.
Autrement dit, le problème n’est pas WordPress tout seul.
Le problème, c’est ce que le site produit réellement une fois que tout le monde a mis sa couche.
1. WordPress fournit une base, pas une conformité automatique
On entend parfois une idée rassurante : puisque le site tourne sur WordPress, une bonne partie de l’accessibilité devrait déjà être réglée.
Ce serait confortable. Ce n’est pas vraiment comme ça que ça marche.
Le cœur de WordPress a progressé, Gutenberg aussi, et le Full Site Editing a apporté une structure souvent plus propre que certains anciens montages maison.
Tant mieux. Mais WordPress ne décide pas à votre place du thème, du constructeur, des plugins, des blocs tiers, ni de la manière dont le contenu est saisi.
Il ne corrige pas non plus ce qu’un composant ajoute maladroitement dans le HTML.
WordPress peut fournir une base correcte. Mais dès que le thème, les blocs, les plugins et le contenu ajoutent chacun leurs propres défauts, les problèmes d’accessibilité se cumulent vite.
2. Le thème porte une grosse part des écarts
Le thème décide de beaucoup plus de choses qu’on ne l’imagine.
Il donne la structure, les styles, les contrastes, les états de focus, la hiérarchie visuelle, parfois même une partie du comportement mobile.
Quand le thème gère mal la structure, les contrastes ou les états de focus, les problèmes se répandent partout dans le site.
On retrouve souvent les mêmes dérives : titres utilisés pour le style plutôt que pour la structure, contrastes trop doux, boutons sans focus visible, gabarits qui déplacent l’information importante trop loin, styles hérités qui ne correspondent plus à la palette réelle du site.
Sur un site réel, certaines remontées viennent précisément de là : anciennes références de palette encore présentes dans les styles, règles de couleur incohérentes selon le contexte, héritage du thème parent qui ne colle plus tout à fait au thème enfant.
Rien de très spectaculaire.
Mais c’est souvent comme ça que l’accessibilité se dégrade : pas dans un grand crash, plutôt dans une série de petites imprécisions.
3. Les blocs Gutenberg demandent parfois une reprise un par un
C’est un point qu’on sous-estime facilement.
Sur un WordPress moderne, on construit le site avec beaucoup de blocs. Donc, quand un bloc pose problème, le problème se répète vite dans plusieurs pages.
Et la mise au propre se fait souvent bloc par bloc.
On le voit bien dans les correctifs déjà envisagés sur le projet : navigation, image, tableau, logo de site, liens sociaux, groupes de contenu… Chaque brique peut porter son lot de petites ambiguïtés : un intitulé pas assez clair, un tableau mal interprété, un comportement responsive discutable, une relation mal posée entre un visuel et sa description.
Dit autrement, on ne corrige pas seulement une page.
On corrige un assemblage de briques.
Le bloc de navigation est un bon exemple.
Le moindre problème dans l’ouverture, la fermeture ou le balisage du menu mobile, ses rôles ou ses attributs d’ouverture devient tout de suite structurante.
Un menu de navigation doit rester clair dans son ouverture, sa fermeture et son ordre de parcours. Dès que cette logique se dérègle, l’usage devient moins fiable.
4. Les plugins ajoutent des fonctions, puis du HTML plus ou moins propre
WordPress adore les plugins. C’est sa force. Et parfois son angle mort.
Chaque plugin ajoute une fonction visible, mais aussi du HTML, des attributs, des scripts, des styles et des comportements qu’on maîtrise plus ou moins.
Tant que tout reste visuel, on a l’impression que ça va. Dès qu’on vérifie ce que le composant produit vraiment dans le HTML et comment il se comporte au clavier, au lecteur d’écran ou lors d’une erreur de formulaire
Les formulaires sont un cas classique.
Tant qu’on regarde juste la surface, tout semble simple. Mais dès qu’on teste les erreurs, les statuts, les retours après soumission ou les protections anti-spam, la scène change complètement.
Sur un site réel, il faut parfois reprendre une intégration Contact Form 7 ou Turnstile pour nettoyer des attributs dupliqués, retirer des styles injectés au mauvais endroit, et surtout redonner de la clarté aux messages d’erreur et aux statuts après soumission.
Le problème n’est donc pas : “le plugin ne marche pas”.
Le problème, c’est plutôt : “le plugin marche, mais son HTML et ses interactions ne sont pas assez propres”.
5. Le HTML généré finit toujours par raconter la vérité
Quand un site pose problème, il suffit souvent d’ouvrir le HTML réellement rendu pour comprendre d’où vient une partie du malaise.
Des paragraphes mal fermés. Un attribut obsolète encore présent sur un player vidéo. Des liens enrichis avec des attributs techniques hérités. Des rôles vides. Des structures qui ne cassent pas forcément l’affichage, mais qui salissent le DOM et compliquent la lecture par les technologies d’assistance.
Ce ne sont pas de grands sujets théoriques.
Ce sont des traces de fabrication. Et c’est justement ce qui les rend intéressantes : elles montrent comment un site devient non conforme sans que personne n’ait eu l’impression de commettre une grosse erreur.
Le critère 8.2 fait d’ailleurs souvent un peu peur aux développeurs, parce qu’il passe par le validateur HTML.
Mais il faut rester lucide : peu d’erreurs sont réellement éliminatoires à elles seules. Pour être franchement coincé, il faut en général un HTML vraiment cassé, avec des balises mal fermées, une structure incohérente ou un DOM perturbé au point de gêner le comportement global.
Le reste relève souvent d’un nettoyage méthodique.
Ce n’est pas anodin. Mais ce n’est pas non plus une condamnation automatique.
6. Le vrai problème, c’est l’accumulation
Sur un site WordPress en production, les problèmes d’accessibilité arrivent rarement en fanfare.
Ils s’installent avec le temps.
Une refonte partielle conserve un ancien template. Un plugin historique reste actif parce qu’on préfère éviter d’y toucher. Un shortcode continue de sortir un HTML discutable. Le thème parent évolue. Le thème enfant compense. Un bloc est repris, un autre non.
Et, à force, plus personne n’a une vision vraiment nette de ce que le site produit.
C’est là qu’on se trompe souvent de lecture.
On cherche la cause. En réalité, il y en a plusieurs. Certaines internes, d’autres externes. Certaines dans le thème, d’autres dans le thème parent, d’autres dans les plugins, d’autres encore dans le rendu final.
Au fond, un site WordPress qui pose des problèmes d’accessibilité ressemble rarement à une maison écroulée.
Il ressemble plutôt à une maison habitée depuis longtemps, améliorée par touches successives, avec de bonnes pièces, des coins bricolés, et quelques raccords qu’on ne remarque plus jusqu’au jour où on les inspecte vraiment.
Ce qu’il faut retenir avant de parler conformité
Sur WordPress, les problèmes d’accessibilité viennent surtout de l’endroit où plusieurs couches techniques se croisent : thème, blocs Gutenberg, plugins, HTML généré, scripts tiers, héritages plus anciens.
La bonne nouvelle, c’est qu’on peut presque toujours identifier les causes.
Encore faut-il regarder le site comme il fonctionne réellement, et pas comme on suppose qu’il fonctionne.
C’est souvent là que l’audit devient utile.
Pas pour produire un grand discours abstrait sur la conformité, mais pour comprendre ce qui relève du thème, des blocs natifs, d’un plugin externe, du HTML final, ou simplement d’un site qui a accumulé trop de petites exceptions.
Et, franchement, sur WordPress, cette clarification change déjà beaucoup.
Prêt à faire le tri dans les vrais problèmes d’accessibilité ?
Quand un site WordPress accumule thème, blocs, plugins et couches techniques, il devient difficile de distinguer ce qui vient du core, de l’existant ou d’un composant tiers.
Pour mieux lire ce type de situation, le plus utile est de repartir du cadre global de l’accessibilité web et du RGAA, avec une vue d’ensemble plus structurée.
