Rendre son site WordPress accessible : le guide

Rendre son WordPress accessible : par où commencer

Pour rendre un site WordPress accessible, on corrige quatre piliers : contrastes (ratio ≥ 4,5:1), navigation clavier avec focus visible, textes alternatifs sur les images et formulaires étiquetés. Le référentiel technique est WCAG 2.2 (via RGAA 4.1.2). Le thème et le page builder déterminent 60 à 70 % du résultat : un mauvais socle impose une refonte.

Il y a une raison très concrète de s’y mettre en 2026, et elle n’est plus seulement éthique. Depuis le 28 juin 2025, l’European Accessibility Act (directive UE 2019/882) étend l’obligation d’accessibilité numérique au secteur privé européen. Avant cette date, seuls le public et les très grandes entreprises (CA supérieur à 250 M€) étaient visés en France via l’article 47 de la loi 2005-102. Aujourd’hui, le périmètre est bien plus large, et les sanctions peuvent atteindre 50 000 € par service non conforme (rgaa-ia.fr).

Êtes-vous vraiment concerné ? Le critère exact

Ne partez pas du principe que vous êtes hors champ. Mais ne paniquez pas non plus. Voici les critères précis tels qu’ils figurent dans les textes.

L’EAA s’applique, en France, à toute entreprise qui remplit les deux conditions suivantes et propose un service B2C couvert :

• plus de 10 salariés et plus de 2 M€ de chiffre d’affaires annuel ;
• un service destiné aux consommateurs dans un domaine couvert : e-commerce, banque, livre numérique, transport, télécoms, médias (insign).

Les TPE de moins de 10 salariés ou avec un CA inférieur à 2 M€ sont exemptées pour les services (pas forcément pour tous les produits). Point important : la domiciliation du siège ne vous exempte pas. Si vous vendez à un public européen, la règle s’applique, même depuis l’étranger.

La conformité web se démontre via la norme EN 301 549, donc via le RGAA 4.1.2, lui-même adossé aux WCAG 2.2 publiées par le W3C le 5 octobre 2023. En clair : viser WCAG 2.2 niveau AA, c’est cocher l’essentiel des exigences web de l’EAA. Restent à ajouter les éléments propres à l’EAA : information accessible sur le service, support client accessible et continuité entre canaux.

Si vous êtes une petite structure non assujettie, l’accessibilité reste un investissement rentable : meilleure UX, meilleur SEO, audience plus large. Simplement, vous n’avez pas d’épée réglementaire au-dessus de la tête.

Le socle : thème et page builder décident de tout

C’est le point que 90 % des tutos survolent. Vous pouvez remplir tous les attributs alt du monde : si votre thème génère un HTML bancal ou si votre page builder produit des menus inutilisables au clavier, vous ne serez jamais conforme.

Choisir un thème “Accessibility Ready”

WordPress core est plutôt bon en accessibilité, grâce à la Make WordPress Accessibility team. La version 6.8 (avril 2025) a supprimé les attributs title redondants de l’admin, et la 6.9 a intégré 44 corrections dans Gutenberg : navigation clavier, annonces ARIA, indicateurs de focus renforcés (wpformation). Bonne nouvelle, mais le core n’est qu’un point de départ.

Privilégiez un thème estampillé “Accessibility Ready” ou disposant d’un VPAT public. GeneratePress, Astra ou Twenty Twenty-One offrent une base sémantique correcte et un contraste texte/fond décent. Le thème FSE (Full Site Editing) n’est ni plus ni moins accessible qu’un thème classique (rgaa-checker) : ce qui compte, c’est le code produit, pas la modernité de l’interface.

Le page builder est votre plus gros risque

L’étude comparative Equalize Digital d’août 2025 a audité 19 constructeurs de pages et bibliothèques de blocs. Le classement est sans appel :

Kadence arrive en tête après un processus d’audit manuel mené avec Equalize Digital (relation professionnelle divulguée par les auteurs, à garder en tête) (Equalize Digital). Le vrai enseignement n’est pas “prenez Kadence”, c’est : le builder que vous choisissez conditionne la moitié de votre travail d’accessibilité. Si votre site tourne sur un builder ancien ou lourdement bricolé, aucun plugin ne rattrapera la casse. C’est souvent là que la question de la refonte complète se pose vraiment.

Ce que vous pouvez corriger vous-même

Une bonne partie du travail est à votre portée, sans développeur. Voici les chantiers concrets, du plus rapide au plus exigeant.

Les textes alternatifs des images

Chaque image porteuse d’information doit avoir un attribut alt décrivant son contenu. Les images purement décoratives prennent un alt vide (alt="") pour que les lecteurs d’écran les ignorent. Dans WordPress, le champ se remplit à l’insertion de l’image ou dans la médiathèque. C’est fastidieux mais faisable sur un après-midi pour un site moyen.

La hiérarchie des titres

WCAG demande une structure logique : un seul H1 par page, puis des H2, H3 imbriqués sans sauter de niveau. Les en-têtes de section organisent le contenu (WCAG 2.2 FR). Ne choisissez jamais un niveau de titre “parce qu’il est joli” : le style se règle en CSS, la hiérarchie sert la sémantique. C’est aussi un facteur SEO direct, comme je le rappelle dans le guide SEO 2026.

Les contrastes

Le texte normal doit atteindre un ratio de contraste d’au moins 4,5:1 avec son fond. Le gris clair sur blanc, très à la mode, échoue presque toujours. Testez avec un outil comme le contrast checker de WebAIM et ajustez vos couleurs dans les réglages du thème. WCAG 2.2 ajoute une exigence sur le focus : l’indicateur doit avoir au moins 2 pixels de contour et un contraste minimum de 3:1 (rgaaudit).

Les liens explicites

Le texte d’un lien doit permettre d’en comprendre la fonction seul. Bannissez les “cliquez ici” et “en savoir plus” isolés : préférez “télécharger le catalogue 2026”. Un mécanisme doit permettre de déterminer la fonction du lien par son texte uniquement.

Les formulaires étiquetés

Chaque champ de formulaire doit avoir un label associé (pas juste un placeholder qui disparaît à la saisie). Le nom accessible du composant doit contenir le texte visible de l’étiquette. Si votre plugin de formulaire ne le fait pas proprement, c’est un signal d’alarme. Et pendant qu’on y est, vérifiez que votre formulaire de contact envoie bien les emails : un formulaire accessible mais muet ne sert à rien.

Le lien d’évitement et le menu clavier

Ajoutez un “skip link” (lien d’évitement) permettant de sauter directement au contenu principal. Testez ensuite tout le site à la touche Tab : chaque menu, chaque bouton, chaque pop-up RGPD doit être atteignable et actionnable au clavier, avec un focus visible. Toute interface utilisable au clavier doit comporter un mode où le focus est visible.

Ce qui exige une vraie intervention technique

Certains chantiers dépassent le tableau de bord WordPress et demandent un développeur.

• Les carrousels et sliders. WCAG 2.2 impose une alternative aux gestes de glissement : un carrousel doit proposer des boutons “Précédent” et “Suivant” en plus du swipe. Beaucoup de sliders premium ne le font pas nativement.
• Les composants interactifs complexes (menus déroulants multi-niveaux, accordéons, onglets) qui nécessitent des attributs ARIA corrects et une gestion du focus au clavier.
• Les pop-ups et modales qui doivent “piéger” le focus tant qu’elles sont ouvertes, puis le rendre proprement.
• Un HTML structurellement cassé hérité d’un vieux thème ou d’un builder daté : là, on ne rustine pas, on reconstruit.

Si votre site cumule ces problèmes sur un socle vieillissant, la mise en conformité coûtera plus cher que la refonte. C’est un arbitrage à poser froidement, dossier chiffré en main, exactement comme pour le coût réel d’un site sur 3 ans.

Le piège des overlays d’accessibilité

Je vais être direct, parce que c’est le raccourci que tout le monde me propose. Les overlays type AccessiBe, UserWay ou AudioEye promettent la conformité en une ligne de JavaScript. C’est du vent, et c’est dangereux.

Ces outils ajoutent une couche par-dessus le site sans corriger les vrais problèmes structurels. La communauté professionnelle de l’accessibilité les déconseille fortement, et plusieurs entreprises qui les utilisaient ont été poursuivies aux États-Unis malgré leur présence (wpformation). Un widget qui grossit la police ne rend pas un formulaire non étiqueté conforme. La checklist d’audit RGAA recommande d’ailleurs explicitement l’absence de tout overlay (rgaa-checker).

Un plugin utile existe en revanche : Equalize Digital Accessibility Checker, qui audite vos pages et pointe les erreurs à corriger dans le code. WP Accessibility peut aussi ajouter des liens d’évitement et signaler les images sans alt. La différence est fondamentale : ces plugins vous aident à corriger, l’overlay prétend masquer.

Comment auditer votre site en pratique

Voici la checklist d’audit concrète, à passer avant de crier victoire :

1. Thème “Accessibility Ready” ou VPAT public.
2. Plugin Equalize Digital Accessibility Checker activé et pages scannées.
3. Champ alt rempli sur toutes les images porteuses de sens.
4. Hiérarchie H1-H6 vérifiée, sans saut de niveau.
5. Skip link présent et fonctionnel.
6. Formulaires avec label associé à chaque champ.
7. Menu entièrement utilisable au clavier, focus visible.
8. Aucun overlay AccessiBe / UserWay / AudioEye.
9. Contraste texte/fond ≥ 4,5:1.
10. Pop-up RGPD accessible au clavier.
11. Déclaration d’accessibilité publiée en footer.

L’accessibilité n’est pas un plugin qu’on installe la veille d’un contrôle. C’est une propriété structurelle de votre site, décidée à 60 % par le choix du thème et du builder. Action concrète cette semaine : lancez Equalize Digital Accessibility Checker sur vos cinq pages les plus visitées et testez-les entièrement à la touche Tab. Ce que vous découvrirez vous dira, en une heure, si vous avez un chantier de rustines ou un dossier de refonte.