Accessibilité RGAA pour WordPress : plugins, thèmes et bonnes pratiques

WordPress propulse plus de 40 % des sites web dans le monde. En France, c'est le CMS dominant — chez les PME, les indépendants, les collectivités locales et même certaines grandes entreprises. Et c'est justement là que le problème se pose : la majorité de ces sites ne sont pas conformes au RGAA.

Ce n'est pas la faute de WordPress lui-même. Le CMS a fait des progrès considérables en accessibilité depuis WordPress 5.0. Le problème vient des thèmes mal codés, des plugins qui injectent du HTML non conforme, et des pratiques de contenu qui ignorent les bases (images sans alt, titres en désordre, formulaires sans labels).

Ce guide couvre tout ce qu'un développeur ou webmaster WordPress doit savoir pour rendre un site conforme au RGAA en 2026 : le choix du thème, les plugins utiles, les erreurs classiques à corriger et comment auditer automatiquement avec WebConforme.

L'accessibilité native de WordPress en 2026

Ce que WordPress fait bien

WordPress intègre nativement plusieurs bonnes pratiques d'accessibilité :

• Structure sémantique du back-office : l'admin WordPress est elle-même conçue pour être accessible. Les landmarks ARIA, la navigation au clavier et les labels de formulaires sont bien gérés dans l'interface d'administration.
• Tag « Accessibility Ready » : le répertoire officiel de thèmes propose un filtre « Accessibility Ready » qui identifie les thèmes ayant passé un audit d'accessibilité basique.
• L'éditeur de blocs (Gutenberg) : depuis WordPress 6.x, l'éditeur Gutenberg a amélioré la gestion des attributs alt sur les images, les labels sur les formulaires et la navigation au clavier dans l'éditeur lui-même.
• Attribut alt sur les images : WordPress demande un texte alternatif lors de l'upload d'une image dans la médiathèque. Le champ est visible et accessible.

Ce que WordPress ne fait pas

• Aucun contrôle de conformité : WordPress ne vérifie pas que le contenu publié est conforme au RGAA. Tu peux publier une image sans alt, un formulaire sans label, une page sans titre <h1> — WordPress ne dira rien.
• Aucune gestion des contrastes : le CMS ne vérifie pas les ratios de contraste des couleurs choisies dans le thème ou le contenu.
• Aucune gestion du focus : la navigation au clavier sur le front-end dépend entièrement du thème.
• Pas de déclaration d'accessibilité : WordPress ne génère pas de déclaration d'accessibilité, pourtant obligatoire pour les sites concernés par le RGAA.

Le thème : la fondation de l'accessibilité

Le thème WordPress est le premier facteur d'accessibilité (ou d'inaccessibilité) de ton site. Un mauvais thème peut rendre conforme un site impossible, même avec les meilleurs plugins du monde.

Les thèmes par défaut : Twenty Twenty-Four et Twenty Twenty-Five

Les thèmes par défaut de WordPress (Twenty Twenty-Four, Twenty Twenty-Five) sont conçus avec l'accessibilité en tête. Ils incluent :

• Landmarks ARIA : <header>, <nav>, <main>, <footer> correctement implémentés.
• Lien d'évitement : « Aller au contenu principal » (skip link) présent et fonctionnel — critère RGAA 12.7.
• Navigation au clavier : tous les éléments interactifs (liens, boutons, menus) sont focusables et activables au clavier.
• Contrastes suffisants : les couleurs par défaut respectent les ratios minimum (4.5:1 pour le texte normal, 3:1 pour le texte large) — critère RGAA 3.2.
• Structure de titres cohérente : un seul <h1> par page, hiérarchie sans saut de niveau — critère RGAA 9.1.
• Full Site Editing : Twenty Twenty-Four et Twenty Twenty-Five utilisent le Full Site Editing (FSE), ce qui te donne un contrôle complet sur la structure HTML via l'éditeur de blocs.

Recommandation : si tu pars de zéro, utilise Twenty Twenty-Four ou Twenty Twenty-Five comme base et personnalise avec un thème enfant ou des patterns de blocs. Tu pars d'une fondation accessible au lieu de corriger un thème cassé.

Les critères pour choisir un thème tiers

Si tu dois utiliser un thème premium ou tiers, vérifie ces points avant l'achat :

1. Tag « Accessibility Ready » : le thème a-t-il ce tag dans le répertoire WordPress ? Si c'est un thème premium (ThemeForest, Elegant Themes), cherche la mention dans la documentation.
2. Lien d'évitement (skip link) : ouvre la démo du thème, appuie sur Tab. Un lien « Aller au contenu » doit apparaître. S'il n'y est pas, élimine le thème.
3. Navigation au clavier : navigue dans le menu, les formulaires, les boutons uniquement au clavier (Tab, Entrée, Espace, Flèches). Tout doit être accessible.
4. Indicateur de focus visible : quand tu tabules, vois-tu clairement quel élément est sélectionné ? Un outline visible est obligatoire — critère RGAA 10.7.
5. Contrastes : le texte est-il lisible sur le fond ? Utilise un vérificateur de contraste (WebAIM Contrast Checker) sur les couleurs du thème.
6. Responsive et zoom : le contenu reste-t-il lisible et utilisable avec un zoom à 200 % ? — critère RGAA 10.4.

Les thèmes à éviter

Certains types de thèmes posent des problèmes récurrents d'accessibilité :

• Thèmes avec des « mega menus » JavaScript : souvent inaccessibles au clavier, pas de gestion des rôles ARIA, pas de fermeture avec Échap.
• Thèmes avec des sliders/carousels en page d'accueil : rarement accessibles (pas de contrôle pause, pas de navigation clavier, pas d'annonce du changement de slide).
• Thèmes basés sur des page builders visuels (Elementor, Divi, WPBakery) : ces builders injectent du HTML complexe avec de nombreux <div> imbriqués, souvent sans sémantique. L'accessibilité dépend du builder, pas du thème — et les builders ont des résultats très variables.

Les plugins d'accessibilité pour WordPress

WP Accessibility (Joe Dolson)

C'est le plugin d'accessibilité de référence pour WordPress. Développé par Joe Dolson, membre de l'équipe « Make WordPress Accessible », il corrige automatiquement plusieurs problèmes courants.

Ce qu'il fait :

• Ajoute un lien d'évitement (skip link) si le thème n'en a pas
• Force un outline de focus visible sur les éléments interactifs
• Supprime l'attribut tabindex sur les éléments où il ne devrait pas être
• Ajoute un label sur le champ de recherche WordPress s'il est manquant
• Permet de forcer un contraste minimum sur certains éléments
• Ajoute la langue au document si elle est manquante

Limites :

• Ne corrige pas les problèmes de structure HTML du thème (si le thème n'a pas de <main>, le plugin ne l'ajoute pas)
• Ne gère pas les alternatives textuelles sur les images
• Ne corrige pas les formulaires de plugins tiers

Installation : gratuit, disponible dans le répertoire officiel WordPress.

Access Monitor (Joe Dolson)

Du même développeur, Access Monitor est un plugin qui intègre un audit automatisé directement dans le back-office WordPress.

Ce qu'il fait :

• Scanne tes pages et articles depuis l'admin WordPress
• Affiche un score d'accessibilité et une liste de violations
• Utilise l'API Tenon.io comme moteur d'analyse
• Permet de programmer des scans réguliers

Limites :

• Nécessite une clé API Tenon.io (service payant)
• Les résultats sont en WCAG, pas en RGAA — la correspondance est à faire manuellement
• Couverture limitée aux critères automatisables (comme tout outil automatisé)

One Click Accessibility

Un plugin léger qui ajoute un widget d'accessibilité côté front-end, permettant aux visiteurs de :

• Agrandir la taille du texte
• Changer le contraste
• Souligner les liens
• Activer une police lisible

Attention : ce type de widget ne remplace pas la conformité RGAA. C'est un pansement, pas une solution. L'ARCOM considère que le site doit être accessible par défaut, pas via un overlay ou un widget opt-in. L'utilisation d'un tel widget ne te protège pas en cas de contrôle ou de sanction.

Plugins à éviter : les overlays d'accessibilité

Les plugins de type « overlay d'accessibilité » (accessiBe, UserWay, AudioEye) promettent de rendre ton site accessible « en une ligne de JavaScript ». C'est faux. Ces outils :

• Ne corrigent pas le HTML source — ils ajoutent une couche JavaScript qui tente de patcher les problèmes en temps réel
• Créent souvent plus de problèmes qu'ils n'en résolvent (conflits avec les lecteurs d'écran, modifications non souhaitées du DOM)
• Ne sont pas reconnus comme une solution de conformité par l'ARCOM ou les organismes de certification
• Font l'objet de nombreuses critiques de la communauté accessibilité et de plusieurs procès aux États-Unis

La conformité RGAA s'obtient en corrigeant le code source, pas en ajoutant une surcouche.

Les erreurs classiques d'accessibilité en WordPress

Erreur 1 : les images Featured sans texte alternatif

L'image à la une (Featured Image) d'un article WordPress est porteuse d'information — elle représente visuellement le contenu de l'article. Pourtant, de nombreux sites l'affichent sans attribut alt.

Pourquoi ça arrive : WordPress permet de définir un texte alternatif dans la médiathèque, mais beaucoup de rédacteurs ne remplissent pas le champ. Et certains thèmes affichent l'image à la une via the_post_thumbnail() sans vérifier que le alt est défini.

Comment corriger :

1. Va dans Médias → Bibliothèque et vérifie que chaque image a un texte alternatif renseigné.
2. Dans ton thème, assure-toi que l'appel the_post_thumbnail() récupère bien le alt défini dans la médiathèque. C'est le comportement par défaut de WordPress, mais certains thèmes écrasent l'attribut.
3. Si tu utilises un thème enfant, tu peux forcer un alt par défaut basé sur le titre de l'article :

// functions.php du thème enfant
function force_featured_image_alt($attr, $attachment, $size) {
    if (empty($attr['alt'])) {
        $attr['alt'] = get_the_title();
    }
    return $attr;
}
add_filter('wp_get_attachment_image_attributes', 'force_featured_image_alt', 10, 3);

Ce filtre est un filet de sécurité. L'idéal reste de remplir le champ alt manuellement avec une description pertinente, pas juste le titre de l'article. C'est le critère RGAA 1.1, détaillé dans notre guide des 106 critères.

Erreur 2 : Contact Form 7 sans labels accessibles

Contact Form 7 est le plugin de formulaires le plus utilisé sur WordPress (plus de 5 millions d'installations actives). Et sa syntaxe par défaut génère des formulaires sans labels HTML correctement associés.

Le code Contact Form 7 par défaut :

Ton nom
[text* your-name]

Ton email
[email* your-email]

Ton message
[textarea your-message]

[submit "Envoyer"]

Ce code génère un texte suivi d'un <input>, mais pas de <label for="..."> associé au champ. Le lecteur d'écran ne sait pas à quoi correspond le champ.

Le code conforme :

<label for="your-name">Ton nom</label>
[text* your-name id:your-name]

<label for="your-email">Ton email</label>
[email* your-email id:your-email]

<label for="your-message">Ton message</label>
[textarea your-message id:your-message]

[submit "Envoyer"]

Il faut ajouter manuellement les balises <label> avec un attribut for correspondant à l'id du champ. C'est le critère RGAA 11.1 : chaque champ de formulaire doit avoir un label associé.

Alternative : utilise le shortcode [label] de Contact Form 7 :

[label your-name "Ton nom"][text* your-name]

Erreur 3 : les sliders et carousels sans contrôle accessible

Les sliders (Revolution Slider, Slider Revolution, MetaSlider) sont omniprésents sur les sites WordPress. La quasi-totalité pose des problèmes d'accessibilité :

• Pas de bouton pause : le défilement automatique ne peut pas être arrêté — violation du critère RGAA 13.8 (contenu en mouvement).
• Navigation par flèches non focusable : les boutons précédent/suivant sont des <div> ou des <span>, pas des <button>.
• Pas d'annonce du changement de slide : quand la slide change, le lecteur d'écran n'est pas informé (pas de aria-live).
• Contenu textuel en image : le texte sur les slides est souvent intégré dans l'image elle-même, sans alternative textuelle.

Comment corriger :

1. Ajoute un bouton pause visible et focusable. C'est l'exigence minimale du RGAA pour tout contenu qui défile automatiquement.
2. Rends les contrôles navigables au clavier. Utilise des <button> natifs pour les flèches et les indicateurs de slide.
3. Ajoute aria-live="polite" sur le conteneur de slide pour annoncer les changements.
4. Ne mets pas de texte dans les images. Utilise des calques HTML par-dessus l'image.

Recommandation radicale : supprime le slider. Les études de conversion montrent que les visiteurs interagissent rarement avec les slides au-delà de la première. Un hero statique avec un message clair convertit mieux et est beaucoup plus accessible.

Erreur 4 : les titres en désordre

WordPress ne contrôle pas la hiérarchie des titres. Un rédacteur peut utiliser un <h4> parce que la taille de police lui plaît, sans se soucier de la structure sémantique. Résultat : des pages avec des sauts de niveau (h1 → h3 → h2 → h4), voire pas de <h1> du tout.

Le critère RGAA 9.1 exige une hiérarchie de titres cohérente et sans saut de niveau.

Comment corriger :

1. Forme tes rédacteurs : les titres ne sont pas un choix esthétique, c'est une structure sémantique. h1 = titre principal (un seul par page), h2 = sections principales, h3 = sous-sections, etc.
2. Utilise un plugin de validation : « Flavor » ou « Jenga » peuvent alerter quand la hiérarchie des titres est cassée.
3. Sépare le style de la sémantique : dans ton CSS, définis des classes (.heading-small, .heading-large) pour le style visuel, et réserve les balises <h1> à <h6> pour la structure.

Erreur 5 : le menu de navigation sans landmarks

De nombreux thèmes WordPress affichent le menu de navigation dans un <div> au lieu d'un <nav>. Le lecteur d'écran ne peut pas identifier la zone de navigation et proposer un raccourci pour y accéder.

Critère RGAA 12.6 : les zones de navigation principales doivent pouvoir être identifiées.

Comment corriger :

Dans header.php de ton thème (ou thème enfant), assure-toi que le menu est enveloppé dans un <nav> :

<nav aria-label="Navigation principale">
    <?php wp_nav_menu(array('theme_location' => 'primary')); ?>
</nav>

Le aria-label est obligatoire s'il y a plusieurs <nav> sur la page (navigation principale, fil d'Ariane, navigation de pied de page) pour les distinguer.

Comment auditer un site WordPress avec WebConforme

Étape 1 : le scan initial

Lance un scan sur la page d'accueil de ton site WordPress. En 30 secondes, WebConforme analyse la page et produit un rapport couvrant quatre modules :

• Accessibilité RGAA : images sans alt, formulaires sans labels, contrastes insuffisants, structure des titres, landmarks manquants, etc.
• RGPD : bannière de cookies, politique de confidentialité, mentions légales.
• SEO : méta-données, structure des titres, performance.
• Éco-conception : poids de la page, nombre de requêtes, score EcoIndex.

Étape 2 : les pages critiques

Après la page d'accueil, scanne les pages les plus importantes :

• La page de contact (formulaires)
• La page « Nos services » ou « Nos produits » (images, listes)
• Le blog / la page d'articles (structure des titres, images à la une)
• Le panier et le tunnel de commande si c'est un site e-commerce

Étape 3 : les corrections

Pour chaque violation détectée, WebConforme affiche :

• Le critère RGAA concerné
• L'élément HTML fautif (avec le sélecteur CSS)
• Le code avant (non conforme) et le code après (conforme)

Tu peux appliquer les corrections directement dans ton thème enfant, tes fichiers de template ou tes réglages de plugins.

Étape 4 : le suivi

Avec un plan WebConforme payant, programme des scans réguliers pour surveiller la conformité dans le temps. Les alertes de régression te préviennent si une mise à jour de thème ou de plugin casse l'accessibilité.

Checklist d'accessibilité WordPress

Thème

• Le thème a le tag « Accessibility Ready » ou a été audité
• Un lien d'évitement (skip link) est présent et fonctionne
• La navigation au clavier est fonctionnelle sur tous les éléments interactifs
• L'indicateur de focus est visible
• Les contrastes de couleur respectent les ratios RGAA (4.5:1 / 3:1)
• La structure HTML utilise les landmarks (<header>, <nav>, <main>, <footer>)

Contenu

• Chaque image informative a un texte alternatif pertinent
• Les images décoratives ont alt=""
• La hiérarchie des titres est cohérente (h1 → h2 → h3, sans saut)
• Un seul <h1> par page
• Les liens ont un intitulé explicite (pas de « cliquez ici » ou « en savoir plus » sans contexte)
• Les tableaux de données ont un <caption> et des <th> pour les en-têtes

Formulaires

• Chaque champ a un <label> correctement associé
• Les champs obligatoires sont identifiés
• Les messages d'erreur sont explicites et associés aux champs
• Le formulaire est navigable et soumissible au clavier

Médias

• Les vidéos ont des sous-titres
• Les contenus audio ont une transcription textuelle
• Les sliders ont un bouton pause et sont navigables au clavier

Conformité légale

• La déclaration d'accessibilité est publiée et accessible depuis toutes les pages
• Le schéma pluriannuel est disponible (secteur public)
• La page « Accessibilité » est liée depuis le footer

Les ressources WordPress et accessibilité

• Make WordPress Accessible : le groupe de travail officiel de WordPress dédié à l'accessibilité. Ses recommandations sont la référence.
• WordPress Accessibility Handbook : documentation officielle sur les standards d'accessibilité dans le développement de thèmes et plugins WordPress.
• RGAA 4.1 : le référentiel complet des 106 critères à respecter.

Conclusion

WordPress n'est ni un problème ni une solution pour l'accessibilité RGAA. C'est un outil neutre dont la conformité dépend entièrement de tes choix : le thème, les plugins, les pratiques de contenu et les tests. Un site WordPress bien configuré, avec un thème accessible, des plugins conformes et des rédacteurs formés, peut atteindre un bon niveau de conformité RGAA.

La clé, c'est de commencer par un diagnostic. Lance un test gratuit sur WebConforme et tu sauras en 30 secondes quelles sont les violations à corriger en priorité sur ton site WordPress. Pas besoin d'être expert RGAA — le rapport te donne le code corrigé, prêt à être appliqué.