Publié le 18 octobre 20265 min de lecture

Accessibilité WordPress : le plugin ne suffit pas. Le code, si.

Tout propriétaire de site WordPress confronté à une échéance d’accessibilité finit par tomber sur la même réponse dans un forum : installez un plugin d’accessibilité. Un widget apparaît dans un coin, propose un réglage de contraste et un curseur de taille de police, et le problème semble réglé.

Il ne l’est pas, et il existe désormais une décision d’autorité qui le dit. La FTC a poursuivi l’éditeur d’overlay accessiBe pour avoir affirmé que son produit « peut rendre n’importe quel site conforme aux WCAG » ; la Commission a retenu qu’accessWidget « ne rendait pas tous les sites de ses clients conformes aux WCAG ». L’ ordonnance définitive, approuvée à 3 voix contre 0 en avril 2025, impose un versement d’un million de dollars et interdit à l’entreprise d’affirmer que ses produits automatisés « peuvent rendre n’importe quel site conforme aux WCAG, ou en garantir la conformité dans la durée, sans preuve à l’appui ».

L’Overlay Fact Sheet, signée par 1 048 professionnels de l’accessibilité, en donne la version technique : « Aucun produit d’overlay sur le marché ne peut rendre un site pleinement conforme à un standard d’accessibilité existant. »

Le mécanisme compte plus que le verdict. Un overlay s’exécute après le chargement et rafistole le DOM qu’il trouve. La conformité, elle, s’évalue sur la page que vous livrez. Et aucun script ne peut deviner ce qu’une image signifie — ce qui est précisément l’échec le plus fréquent sur un site WordPress.

Voici donc la version ingrate : le code. Ce sont les défauts que je retrouve dans presque chaque audit WordPress, avec le critère de succès qu’ils enfreignent.

1. Des niveaux de titre choisis pour la taille, pas pour la structure

L’éditeur de blocs laisse l’auteur choisir n’importe quel niveau dans une liste déroulante — il prend donc celui qui « rend bien ».

<!-- Échoue au 1.3.1 Information et relations — un niveau est sauté -->
<h2>Nos services</h2>
<h4>Conseil</h4>

<!-- Correct : le niveau suit la structure. La taille est un problème de CSS. -->
<h2>Nos services</h2>
<h3 class="has-small-font-size">Conseil</h3>

Les utilisateurs de lecteurs d’écran naviguent par niveau de titre. Un niveau sauté, c’est un barreau manquant à l’échelle.

2. Des boutons-icônes sans nom accessible

Menus hamburger, loupes de recherche, icônes sociales. Le défaut le plus courant des thèmes commerciaux :

<!-- Échoue au 4.1.2 Nom, rôle et valeur — annoncé simplement « bouton » -->
<button class="menu-toggle"><svg>…</svg></button>

<!-- Correct : un vrai nom, l'icône masquée, l'état exposé -->
<button class="menu-toggle" aria-expanded="false" aria-controls="primary-menu">
  <svg aria-hidden="true" focusable="false">…</svg>
  <span class="screen-reader-text">Menu</span>
</button>

screen-reader-text est une classe du cœur de WordPress : elle est déjà dans votre feuille de style. Utilisez-la plutôt que d’inventer .visually-hidden.

3. Le focus que quelqu’un a supprimé

Je trouve cette ligne dans la majorité des thèmes commerciaux, ajoutée parce que le designer n’aimait pas le contour :

/* Échoue au 2.4.7 Visibilité du focus — l'utilisateur clavier navigue à l'aveugle */
a:focus, button:focus { outline: none; }

/* Correct : visible au clavier, pas de contour au clic souris */
:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
}

4. Des placeholders déguisés en étiquettes

Contact Form 7, WPForms et Gravity Forms rendent l’erreur facile :

<!-- Échoue aux 1.3.1 et 3.3.2 — le placeholder disparaît à la saisie -->
[email* your-email placeholder "E-mail"]

<!-- Correct : une vraie étiquette, associée au champ -->
<label for="your-email">Adresse e-mail (obligatoire)</label>
[email* your-email id:your-email]

Et les erreurs ne doivent pas reposer sur la seule couleur : c’est le 1.4.1 Utilisation de la couleur plus le 3.3.1 Identification des erreurs. Un texte rouge sans mots ne dit rien à un daltonien, et moins que rien à un lecteur d’écran.

5. Douze liens « Lire la suite » identiques

Le standard de n’importe quel template d’archive WordPress :

<!-- Échoue au 2.4.4 Fonction du lien — hors contexte, tous les liens sont identiques -->
<a href="…">Lire la suite</a>

<!-- Correct : le texte visible reste court, le nom accessible est complet -->
<a href="…">Lire la suite<span class="screen-reader-text"> sur l'accessibilité WordPress</span></a>

6. Le texte alternatif, la part qu’aucun plugin ne fera à votre place

WordPress laisse le champ alt vide par défaut, et un overlay devinera. Ni l’un ni l’autre n’est correct. La règle porte sur la fonction, pas sur la description : une image porteuse d’information a besoin d’un alt qui transmet cette information ; une image décorative a besoin d’alt="" pour que les technologies d’assistance l’ignorent. Un alt vide est un choix délibéré et juste. Un attribut alt absent n’est pas la même chose — le lecteur d’écran peut alors lire le nom du fichier.

Les critères WCAG 2.2 qui vont compter

WCAG 2.2 ajoute neuf critères de succès. Quatre frappent durement les sites WordPress typiques :

2.4.11 Focus non masqué (minimum), AA. Votre en-tête collant. Tabulez vers le bas : l’élément focalisé glisse dessous. Presque tous les thèmes WordPress à en-tête fixe échouent, et presque personne ne l’a vérifié.
2.5.8 Taille de la cible (minimum), AA. 24 × 24 pixels CSS. Les rangées d’icônes sociales, la pagination et les entrées de menu mobile sont les coupables habituels.
2.5.7 Mouvements de glissement, AA. Tout ce qui repose sur le glisser seul doit offrir une alternative à pointeur unique — sliders et carrousels.
3.3.8 Authentification accessible (minimum), AA. Pas de test de fonction cognitive pour se connecter, et ne bloquez pas le collage dans le champ mot de passe.

À savoir également : le 4.1.1 Analyse syntaxique a été supprimé en 2.2 car obsolète. Cessez donc de présenter des erreurs de validateur comme des échecs WCAG.

Sur le calendrier juridique, méfiez-vous de ce que vous répétez. EN 301 549 v4.1.1 — la version qui intègre WCAG 2.2 — a été publiée le 2 septembre 2026, mais à l’heure où j’écris elle n’avait pas encore été citée au Journal officiel, ce qui est l’étape qui ferait de WCAG 2.2 la référence opposable pour l’European Accessibility Act. Les estimations pointent vers la fin 2026. Vérifiez au Journal officiel avant d’inscrire une date dans une proposition client ; j’ai traité le cadre juridique plus large dans un précédent article.

Le test de dix minutes qui bat n’importe quel plugin

Débranchez votre souris. Tabulez sur un parcours clé. Voyez-vous où vous êtes ? Atteignez-vous tout ? Sortez-vous de la modale ?
Zoomez à 200 %. La mise en page tient-elle, ou le menu disparaît-il ?
Lancez axe ou Lighthouse. Les outils automatiques attrapent environ un tiers des problèmes : réel, mais c’est un plancher, pas une ligne d’arrivée.
Activez VoiceOver ou NVDA sur un parcours : accueil → produit → envoi de formulaire.

L’étape 1 trouve plus que n’importe quel plugin, et elle ne coûte rien. C’est la partie inconfortable : l’accessibilité n’est pas un produit qu’on installe, c’est une propriété du balisage qu’on livre — et c’est pourquoi je répète qu’elle coûte dix fois moins cher intégrée à la construction qu’ajoutée au moment de l’audit.

Besoin d’un état des lieux WCAG de votre site WordPress qui produise des correctifs plutôt qu’un widget ? C’est le rôle d’un audit technique — et je développe aussi sous WordPress, comme sur le site d’Espé Montréal.