Un thème WordPress accessibility-ready rend-il mon site conforme au RGAA ?

Non. Le label accessibility-ready signifie que le thème a passé des tests de base, mais il ne couvre ni vos contenus, ni vos images, ni les plugins que vous ajoutez. La conformité RGAA porte sur le site publié dans son ensemble, pas sur le thème seul.

Elementor ou Divi posent-ils des problèmes d'accessibilité ?

Souvent oui. Ces constructeurs facilitent le design mais génèrent fréquemment une structure pauvre en sémantique et des éléments interactifs difficiles à opérer au clavier. Ils peuvent être rendus plus accessibles, mais cela demande des réglages et des vérifications à chaque page.

Mon site WordPress est-il concerné par l'European Accessibility Act ?

Si vous vendez des produits ou services en ligne auprès de particuliers dans l'Union européenne, probablement oui. L'EAA s'applique depuis le 28 juin 2025. Un diagnostic permet de situer votre site par rapport aux exigences et de prioriser les corrections.

Accessibilité WordPress : ce qui compte vraiment pour votre conformité

WordPress fait tourner une grande partie du web, mais sa flexibilité est aussi son talon d'Achille en accessibilité. Entre le thème, les plugins et le contenu saisi par les rédacteurs, la conformité dépend de choix qui vous appartiennent. Voici ce qu'il faut surveiller pour viser le RGAA et l'European Accessibility Act.

WordPressest-il accessible par défaut ?

WordPress n'est ni accessible ni inaccessible par défaut : tout dépend du thème et des extensions installés. Le cœur de WordPress et l'éditeur de blocs Gutenberg produisent un HTML globalement correct, mais un thème commercial mal codé, un constructeur de pages (Elementor, Divi, WPBakery) ou une dizaine de plugins peuvent réintroduire des problèmes à chaque page. Aucun thème dit accessibility-ready ne garantit à lui seul la conformité, car il ne contrôle ni vos contenus ni les widgets ajoutés. En pratique, la conformité RGAA se joue sur la combinaison thème + plugins + contenu éditorial, pas sur le CMS lui-même.

Les atouts

Thèmes étiquetés accessibility-ready dans le répertoire officiel, audités sur des critères de base (contraste, navigation clavier, focus visible).
Éditeur Gutenberg qui propose une structure de titres et des outils pour le texte alternatif des images au moment de la publication.
Écosystème mature d'extensions et de vérificateurs d'accessibilité intégrés à l'éditeur pour repérer les manques avant publication.
HTML sémantique sous-jacent (landmarks, titres) facilement corrigeable car vous gardez la main sur le thème et le code.

Les points de vigilance

Constructeurs de pages (Elementor, Divi, WPBakery) qui génèrent souvent des div imbriquées sans sémantique, des titres uniquement décoratifs et des composants interactifs non opérables au clavier.
Thèmes du commerce vendus comme accessibles mais non audités, avec contrastes insuffisants, focus invisible et menus déroulants inaccessibles au clavier.
Multiplication des plugins (carrousels, popups, formulaires, cookies) qui injectent leur propre code et échappent au contrôle du thème, recréant des barrières à chaque mise à jour.
Texte alternatif des images mal géré par les rédacteurs via la médiathèque : alt vide, alt redondant ou champ confondu avec la légende et le titre.
Widgets d'overlay d'accessibilité installés via plugin qui donnent une fausse impression de conformité sans corriger les problèmes réels du code.

Checklist pour WordPress

Choisir un thème réellement audité et tester sa navigation entièrement au clavier (menus, focus visible, ordre logique).
Limiter les constructeurs de pages ou vérifier que chaque bloc génère une structure de titres et des composants opérables au clavier.
Imposer aux rédacteurs une règle claire sur le texte alternatif : décrire les images porteuses d'information, laisser vide les images décoratives.
Auditer chaque plugin à fort impact visuel (carrousel, popup, formulaire, bannière cookies) sur le contraste, le clavier et les messages d'erreur.
Vérifier les contrastes de couleurs du thème et des boutons par rapport au seuil WCAG, sans se fier à l'apparence.
Ne pas remplacer une correction du code par un widget d'overlay, qui ne suffit jamais à être conforme.

Un thème ou une extension « accessible » ne suffit jamais à rendre un site conforme. Seul un audit du site réel — avec vos contenus, vos modules et vos parcours — permet de viser la conformité (déclaration d'accessibilité, schéma pluriannuel). En savoir plus sur l'audit.

Testez l’accessibilité de votre site, gratuitement

Vérifiez en moins d'une minute les premiers écarts d'accessibilité de votre site WordPress.

Lancer le diagnostic gratuit

Pour aller plus loin

Questions sur l'accessibilité WordPress

Un thème WordPress accessibility-ready rend-il mon site conforme au RGAA ?: Non. Le label accessibility-ready signifie que le thème a passé des tests de base, mais il ne couvre ni vos contenus, ni vos images, ni les plugins que vous ajoutez. La conformité RGAA porte sur le site publié dans son ensemble, pas sur le thème seul.
Elementor ou Divi posent-ils des problèmes d'accessibilité ?: Souvent oui. Ces constructeurs facilitent le design mais génèrent fréquemment une structure pauvre en sémantique et des éléments interactifs difficiles à opérer au clavier. Ils peuvent être rendus plus accessibles, mais cela demande des réglages et des vérifications à chaque page.
Mon site WordPress est-il concerné par l'European Accessibility Act ?: Si vous vendez des produits ou services en ligne auprès de particuliers dans l'Union européenne, probablement oui. L'EAA s'applique depuis le 28 juin 2025. Un diagnostic permet de situer votre site par rapport aux exigences et de prioriser les corrections.