Quand on parle d’accessibilité, beaucoup de gens imaginent encore une suite de petites corrections bien rangées.
On ajuste deux ou trois contrastes, on complète quelques textes alternatifs, on corrige un formulaire, et l’affaire serait bouclée.
Sur un site WordPress réel, ce n’est presque jamais aussi simple.
Pas parce que tout serait cassé. Pas parce que WordPress serait ingérable.
Mais parce qu’un site vivant accumule des couches : thème, blocs, plugins, contenus, anciens choix techniques, nouvelles habitudes d’édition, morceaux de refonte, petits correctifs ajoutés au fil du temps.
Et quand on commence enfin à regarder l’accessibilité sérieusement, on ne découvre pas un problème unique.
On découvre un ensemble.
C’est pour ça que la mise en conformité prend du temps.
Pas forcément parce que chaque correction est énorme. Souvent, c’est l’inverse. Mais il faut les repérer, les classer, les corriger, les tester, et surtout comprendre lesquelles comptent le plus.
1. La déclaration d’accessibilité oblige à nommer ce qui ne va pas encore
La déclaration d’accessibilité donne parfois l’impression d’être une formalité administrative.
En réalité, elle a quelque chose de beaucoup plus direct.
Elle oblige à écrire noir sur blanc ce qui n’est pas conforme.
Et c’est souvent là que le sujet devient concret.
Tant qu’on parle “d’amélioration”, tout le monde reste à l’aise. Dès qu’il faut lister les non-conformités, on change de niveau. On ne parle plus d’intention. On parle d’écarts réels, observés, vérifiables.
Sur un site WordPress un peu dense, cette liste peut vite s’allonger : un menu qui annonce mal son état, des tableaux mal interprétés, des erreurs de formulaire mal reliées aux champs, des liens sociaux trop vagues, des sorties HTML produites par un plugin, des contrastes insuffisants dans certains contextes, ou des modèles de pages qui ne se comportent pas tous de la même manière.
Le point important, c’est que la déclaration ne demande pas de raconter une histoire rassurante.
Elle demande de dire où le site en est réellement.
2. Un audit ne débouche pas sur une seule correction, mais sur une pile de sujets différents
C’est souvent là qu’il y a un malentendu.
On pense “audit”, puis on imagine “une solution”. En pratique, un audit produit plutôt une cartographie.
Il montre ce qui bloque vraiment, ce qui dégrade surtout le confort, ce qui relève du contenu, du thème, des blocs, d’un plugin externe, ce qui peut être corrigé vite, et ce qui demandera une reprise plus lourde.
Autrement dit, l’audit ne sert pas seulement à constater.
Il sert à séparer.
Et cette séparation change tout.
Parce qu’on ne traite pas de la même manière un texte de lien trop vague, un bloc tableau mal structuré, un menu mobile qui annonce mal son ouverture, un plugin tiers qui injecte du HTML non valide, ou un comportement dynamique qui se dégrade après soumission d’un formulaire.
C’est aussi pour ça que le chantier paraît long : on n’avance pas sur un seul rail.
On avance sur plusieurs couches à la fois.
3. Sur WordPress, une partie du travail se fait bloc par bloc
Dès qu’on travaille avec Gutenberg et le Full Site Editing, les blocs deviennent centraux.
C’est une force. Mais c’est aussi une réalité technique à assumer.
Quand un site repose largement sur les blocs, la mise en conformité se fait souvent bloc par bloc.
Il faut parfois reprendre les images, les tableaux, les liens sociaux, le logo du site, les groupes de contenu, le bloc de navigation, certains liens vers les pages, et parfois même des listes ou des paragraphes selon la manière dont ils sont saisis et stylés.
Ce n’est pas forcément une mauvaise nouvelle.
Au contraire, cela permet souvent de corriger à la source des éléments qui se répètent partout. Mais cela prend du temps, parce qu’il faut regarder comment chaque bloc rend son HTML, gère ses attributs, se comporte dans différents contextes et tient, ou non, au clavier et au lecteur d’écran.
4. Les plugins externes rallongent presque toujours le chantier
Un plugin visible ajoute rarement seulement une fonction visible.
Il ajoute aussi une structure HTML, des scripts, des styles, des comportements, parfois des attributs, parfois tout en même temps.
Et c’est là que le temps s’allonge.
Prenons les formulaires.
Tant qu’on regarde la page sans provoquer d’erreur, tout peut paraître propre. Puis on teste une soumission incomplète, un message d’échec, une protection anti-spam, une interaction avec un service tiers. Et là, on commence à voir le vrai comportement du composant.
Sur un site réel, on retrouve vite ce type de cas : messages d’erreur à reprendre, statuts de formulaire à rendre plus explicites, doublons d’attributs dans une intégration Turnstile, styles injectés au mauvais endroit, fragments HTML à nettoyer après rendu.
Et oui, parfois des hooks permettent de corriger ces choses-là proprement. Heureusement.
Mais pas toujours. Parfois il faut filtrer le rendu. Parfois il faut réécrire un fragment. Parfois il faut simplement accepter qu’un plugin courant fasse perdre beaucoup de temps sur des points qui ne se voient presque pas à l’écran.
5. Toutes les non-conformités n’ont pas le même poids
C’est une nuance importante, et elle change complètement la manière de piloter un chantier.
Quand on commence à lister les écarts, tout peut sembler urgent.
En réalité, il faut distinguer
- ce qui bloque l’usage,
- ce qui rend l’usage plus difficile,
- ce qui relève de la robustesse du code, et
- ce qui peut être traité plus tard sans empêcher une vraie progression.
Sinon, on s’éparpille.
Dans la vraie vie, quelques corrections font souvent monter vite le niveau global :
- des liens reformulés,
- une hiérarchie de titres reprise,
- des messages d’erreur mieux reliés aux champs,
- des contrastes corrigés,
- un focus clavier redevenu visible,
- des tableaux clarifiés,
- ou certaines sorties HTML nettoyées.
C’est aussi pour ça qu’on entend souvent les professionnels dire qu’on peut monter à 70 %, parfois 80 %, avec un chantier bien mené et bien priorisé.
Au-delà, le temps s’allonge plus fortement.
6. Le vrai sujet, c’est la priorisation dans le temps
Le mot “chantier pluriannuel” peut sembler lourd.
Mais il décrit souvent assez bien la réalité.
Un site WordPress ne reste pas figé.
Il reçoit de nouveaux contenus, de nouvelles pages, parfois de nouveaux blocs, parfois de nouveaux plugins, parfois de nouveaux besoins marketing ou métiers. Donc, même après une première phase de correction, le sujet ne disparaît pas totalement.
C’est pour ça qu’une démarche sérieuse ne cherche pas à tout faire d’un coup. Elle cherche à organiser le travail.
En général, cela veut dire :
- corriger d’abord ce qui bloque l’usage ;
- traiter ensuite les composants structurants ;
- reprendre progressivement les cas plus techniques ;
- puis stabiliser ;
- et vérifier régulièrement que les évolutions du site ne réintroduisent pas les mêmes défauts.
Ce n’est pas une manière de repousser le sujet. C’est une manière de le rendre tenable.
Parce que promettre une conformité totale, rapide et simple sur un WordPress déjà riche en contenus, blocs, plugins et historique technique, ce n’est pas très sérieux. En revanche, proposer une progression claire, priorisée et testée, là, on commence à parler d’une vraie démarche.
Ce qu’on peut attendre d’une mise en conformité sérieuse
Une mise en conformité sérieuse ne doit pas seulement produire une liste.
Elle doit produire une lecture utile.
Elle doit permettre de répondre à des questions simples :
- qu’est-ce qui bloque vraiment aujourd’hui ?
- qu’est-ce qui peut être corrigé vite ?
- qu’est-ce qui demande une reprise plus lourde ?
- qu’est-ce qui dépend d’un plugin ou d’un composant externe ?
- qu’est-ce qui relève d’une évolution normale du site dans le temps ?
C’est cette clarté qui rend le chantier supportable.
Au fond, le vrai risque n’est pas seulement d’avoir des non-conformités.
Le vrai risque, c’est d’avoir un site où personne ne sait plus distinguer l’important du secondaire, le rapide du long, le contenu du technique, le correctif local du problème structurel.
Et sur WordPress, cette distinction vaut déjà beaucoup.
Votre WordPress a besoin d’un cadre plus clair ?
Quand un site accumule des blocs, des plugins, des réglages et des héritages techniques, la mise en conformité devient vite difficile à piloter sans vision d’ensemble.
Repartir du cadre global permet de distinguer ce qui relève d’un audit, d’un correctif ciblé ou d’un chantier plus progressif.
