Accessibilite WordPress : guide RGAA complet

1. WordPress et l'accessibilité

WordPress est bien plus qu'un simple outil de blog. Avec plus de 40% des sites web mondiaux construits sur cette plateforme, WordPress représente plus de 80% de parts de marché parmi les systèmes de gestion de contenu (CMS). Des sites gouvernementaux aux boutiques e-commerce, des blogs personnels aux portails d'entreprise, WordPress est partout.

Cette omniprésence pose un enjeu majeur : si WordPress n'est pas accessible, c'est une part considérable du web qui exclut les personnes en situation de handicap. La bonne nouvelle, c'est que WordPress dispose d'une équipe dédiée à l'accessibilité (WordPress Accessibility Team) qui travaille activement à améliorer le CMS. Le core de WordPress intègre des fonctionnalités d'accessibilité : landmarks ARIA, skip links dans les thèmes par défaut, gestion du focus dans l'interface d'administration, et support des lecteurs d'écran.

Cependant, l'arrivée de Gutenberg (l'éditeur de blocs) a soulevé des débats importants dans la communauté. Lors de son lancement en 2018, de nombreux problèmes d'accessibilité ont été signalés : navigation au clavier défaillante, manque de support pour les lecteurs d'écran, et complexité accrue de l'interface d'édition. Depuis, des améliorations significatives ont été apportées, mais des défis persistent, notamment avec les blocs tiers et les patterns complexes.

L'accessibilité d'un site WordPress dépend de trois facteurs : le core (généralement bon), le thème (variable), et les plugins (souvent problématiques). Ce guide couvre chacun de ces aspects pour vous aider à atteindre la conformité RGAA.

2. Erreurs courantes d'accessibilité sur WordPress

Avant d'aborder les bonnes pratiques, identifions les erreurs les plus fréquentes sur les sites WordPress. Les connaître vous permettra de les éviter ou de les corriger en priorité.

2.1 Choisir un thème non accessible

C'est l'erreur la plus impactante. Le répertoire WordPress.org propose des milliers de thèmes, mais seule une fraction porte le tag accessibility-ready. Un thème non accessible peut introduire des problèmes structurels difficiles à corriger : absence de skip links, contrastes insuffisants, navigation impossible au clavier, hiérarchie de titres cassée, absence de landmarks ARIA. Corriger ces problèmes dans un thème tiers implique souvent de surcharger massivement le CSS et les templates, ce qui revient presque à créer un thème enfant complet.

2.2 Plugins qui injectent du markup non accessible

Les plugins WordPress injectent du HTML directement dans le front-end. Un slider sans alternatives textuelles, un popup sans gestion du focus, un menu mega sans attributs ARIA, un chatbot sans accessibilité clavier — chaque plugin non accessible dégrade l'ensemble du site. Le problème est aggravé par le fait que la plupart des plugins ne sont pas audités pour l'accessibilité, et que les utilisateurs n'ont pas toujours les compétences pour évaluer la qualité du markup généré.

2.3 Contenu WYSIWYG sans structure

L'éditeur visuel de WordPress permet aux rédacteurs de formater du texte facilement. Mais trop souvent, la mise en forme est purement visuelle : du texte en gras au lieu de titres, des retours à la ligne au lieu de paragraphes, du texte coloré pour simuler des liens. Le contenu résultant manque de structure sémantique, ce qui le rend incompréhensible pour les lecteurs d'écran. Les titres sont utilisés pour leur apparence (grande taille) plutôt que pour leur rôle hiérarchique, cassant la structure du document.

2.4 Images sans texte alternatif dans la médiathèque

WordPress fournit un champ "Texte alternatif" dans la médiathèque, mais il n'est pas obligatoire. De nombreux contributeurs uploadent des images sans jamais remplir ce champ. Résultat : des centaines d'images avec un attribut alt vide ou absent, rendant le contenu visuel invisible pour les utilisateurs de lecteurs d'écran. Le problème est amplifié par les images mises en avant (featured images) qui sont rarement accompagnées d'un texte alternatif.

2.5 Formulaires de contact sans labels

Les formulaires sont un point critique de l'accessibilité. Beaucoup de sites WordPress utilisent des formulaires où les champs s'appuient uniquement sur des placeholders comme étiquettes visuelles, sans véritable élément <label> associé programmatiquement. Certains plugins génèrent des formulaires avec des <label> visuellement présents mais non reliés au champ par l'attribut for, ce qui rompt l'association pour les technologies d'assistance.

3. Bonnes pratiques

3.1 Choisir un thème accessible

Le choix du thème est la décision la plus structurante pour l'accessibilité de votre site. Sur le répertoire WordPress.org, filtrez par le tag accessibility-ready. Ce label garantit que le thème a passé une revue incluant les critères suivants :

• Navigation complète au clavier sans piège
• Présence de skip links (liens d'évitement)
• Contrastes de couleurs suffisants (ratio 4.5:1 minimum)
• Formulaires avec labels correctement associés
• Hiérarchie de titres logique (un seul h1, pas de saut de niveau)
• Landmarks ARIA ou éléments HTML5 sémantiques (header, nav, main, footer)
• Styles de focus visibles sur tous les éléments interactifs

Parmi les thèmes accessibility-ready reconnus : Twenty Twenty-Four (thème par défaut) et Flavor (starter theme minimaliste, disponible aussi en Blocktheme). Si vous développez un thème sur mesure, utilisez-les comme base.

3.2 Blocs Gutenberg et accessibilité

L'éditeur de blocs génère du HTML relativement propre pour les blocs natifs. Voici les bonnes pratiques à suivre :

Hiérarchie des titres : utilisez les blocs Titre en respectant la hiérarchie. Le h1 est réservé au titre de la page (géré par le thème). Commencez vos sections par h2, puis h3, etc. Ne sautez jamais un niveau (pas de h2 suivi d'un h4).

Images et texte alternatif : le bloc Image de Gutenberg propose un champ "Texte alternatif" dans le panneau latéral. Renseignez-le systématiquement. Si l'image est décorative, indiquez-le explicitement pour générer un alt="".

Blocs Liste : privilégiez les blocs Liste natifs plutôt que de simuler des listes avec des tirets dans un bloc Paragraphe. Le bloc Liste génère de vrais éléments <ul> ou <ol> qui sont correctement interprétés par les technologies d'assistance.

3.3 Menus de navigation accessibles

WordPress génère les menus via la fonction wp_nav_menu(). Par défaut, le balisage est correct mais minimaliste. Pour un menu pleinement accessible avec sous-menus, vous devez personnaliser le Walker class :

Ce pattern suit les recommandations du WAI-ARIA Authoring Practices Guide (Disclosure Navigation Menu). Le JavaScript associé doit : basculer aria-expanded au clic ou à l'appui sur Entrée/Espace, fermer le sous-menu avec Échap, et gérer le focus au clavier.

3.4 Formulaires accessibles : comparatif des plugins

Les formulaires sont un point critique du RGAA (thématique 11). Voici un comparatif des trois plugins les plus populaires :

Si vous utilisez Contact Form 7, ajoutez manuellement les attributs d'accessibilité :

3.5 Médiathèque : imposer le texte alternatif

Le texte alternatif n'est pas obligatoire par défaut dans WordPress. Pour l'imposer dans votre workflow, plusieurs approches sont possibles :

Approche plugin : installez WP Accessibility qui ajoute une alerte lorsqu'une image sans texte alternatif est inseree. Vous pouvez aussi utiliser le plugin Require Alt Text qui bloque purement et simplement la publication si des images n'ont pas de texte alternatif.

Approche code : ajoutez un filtre dans votre thème pour détecter les images sans alt :

Approche workflow : formez vos contributeurs à renseigner le texte alternatif au moment de l'upload plutôt qu'après coup. Intégrez cette étape dans votre charte éditoriale et votre processus de validation de contenu.

3.6 CSS personnalisé pour l'accessibilité

Même avec un thème accessibility-ready, des ajustements CSS sont souvent nécessaires. Voici les styles essentiels à ajouter ou vérifier :

Si votre thème ne propose pas de skip link, ajoutez-le manuellement dans le header.php de votre thème enfant, juste après l'ouverture du <body> :

4. Critères RGAA clés pour WordPress

Parmi les 106 critères du RGAA 4.1.2, certains sont particulièrement pertinents pour les sites WordPress. Voici les critères à vérifier en priorité :

5. Plugins recommandés

Ces plugins vous aident à améliorer et maintenir l'accessibilité de votre site WordPress :

6. Checklist accessibilité WordPress

Utilisez cette checklist pour vérifier l'accessibilité de votre site WordPress. Elle couvre les points les plus critiques liés au RGAA :