Thème WordPress accessible : la liste de ce qu'il faut vérifier
Le thème décide d'une bonne part de l'accessibilité d'un site WordPress : structure des pages, menus, focus clavier, couleurs, typographie. Un contenu bien rédigé ne rattrapera pas un menu impossible à ouvrir au clavier. Voici ce que vérifie le répertoire officiel pour les thèmes qui se disent accessibles, et comment tester n'importe quel thème avant de l'adopter.
Ce que garantit l'étiquette « accessibility-ready »
L'équipe de revue des thèmes de WordPress.org publie la liste des points exigés pour l'étiquette. La page indique que les éléments suivants sont « requis pour obtenir l'approbation » : un lien d'évitement vers le contenu, la prise en charge de la navigation au clavier, des contrôles dotés de noms, rôles et états accessibles, des champs de formulaire étiquetés, une structure de titres cohérente, des contrastes suffisants pour le texte et les contrôles, des alternatives textuelles pour les images, des médias accessibles, des liens soulignés dans le texte et sans intitulé ambigu, des régions (landmarks) nommées, la prise en charge du redimensionnement, de la redistribution (reflow) et de l'espacement du texte, l'absence de changement de contexte inattendu, un avertissement avant l'ouverture d'un nouvel onglet, un contenu accessible au survol comme au focus, et la prise en charge du texte réservé aux lecteurs d'écran.
Indépendamment de cette étiquette, les règles générales du répertoire imposent à tous les thèmes deux exigences de base : un mécanisme permettant d'aller directement au contenu ou à la navigation, et une mise en évidence visuelle du focus clavier dans les menus, champs, boutons et liens.
La liste de vérification
Ces tests ne demandent aucun outil particulier, seulement un navigateur et un peu de méthode. Ils valent pour un thème blocs comme pour un thème classique.
Au clavier
- En appuyant sur Tab dès le chargement de la page, un lien « Aller au contenu » apparaît-il, et fonctionne-t-il ?
- Peut-on ouvrir chaque menu et sous-menu, puis le refermer avec Échap, sans souris ?
- Le focus est-il toujours visible, avec un contraste suffisant, et jamais caché sous un en-tête collant ou un bandeau ? C'est l'objet du critère 2.4.11 des WCAG 2.2.
- L'ordre de tabulation suit-il l'ordre visuel de la page ?
Structure et contenus
- Chaque page a-t-elle un seul titre de niveau 1, et des niveaux de titres qui se suivent sans sauter d'étape ?
- Les régions principales sont-elles balisées (
header,nav,main,footer), et nommées quand il y en a plusieurs du même type, comme deux menus ? - Les liens du texte sont-ils soulignés ou distingués autrement que par la couleur ? Les intitulés « Lire la suite » répétés sont-ils complétés d'un texte caché qui précise de quel article il s'agit ?
- Les images décoratives du thème ont-elles un attribut
altvide, et les images porteuses d'information une alternative ?
Formulaires
- Le champ de recherche, le formulaire de commentaires et celui de connexion ont-ils des étiquettes visibles ou, à défaut, des noms accessibles ?
- Les messages d'erreur sont-ils écrits en texte et associés au champ concerné, et pas seulement signalés par une bordure rouge ?
Affichage
- À 200 % de zoom, puis sur une largeur de 320 pixels, le contenu reste-t-il lisible sans défilement horizontal ?
- Si l'on augmente l'interlignage et l'espacement des lettres et des mots, le texte reste-t-il entier, sans chevauchement ni coupure ?
- Les couleurs du thème respectent-elles les seuils expliqués dans notre article sur les contrastes : 4,5:1 pour le texte courant, 3:1 pour les composants ?
- Les animations et carrousels peuvent-ils être mis en pause, et respectent-ils la préférence « réduire les animations » du système ?
Le cas des thèmes blocs
Les thèmes blocs simplifient certains points : les blocs de navigation, de recherche ou de commentaires du cœur de WordPress font l'objet d'un travail d'accessibilité continu, et un thème qui les utilise en hérite. Mais ils déplacent la responsabilité vers les personnes qui modifient le site. Dans l'éditeur de site, il est facile de transformer un titre de niveau 2 en paragraphe en gras, de choisir une couleur de texte illisible, ou de supprimer le lien d'évitement en remplaçant l'en-tête. D'où l'intérêt de limiter les options dans theme.json et de documenter, pour les rédacteurs, les quelques règles à respecter.
Les extensions, l'autre moitié du problème
Un thème irréprochable peut être dégradé par une extension : un bandeau de cookies qui piège le focus, un carrousel qui défile seul, un formulaire sans étiquettes, un « captcha » visuel. Les mêmes tests s'appliquent donc à chaque extension visible côté visiteur. Les exigences du répertoire vont dans ce sens : un thème « accessibility-ready » ne doit ni recommander ni exiger d'extension inaccessible.
Et ensuite ?
Ces vérifications ne remplacent pas un audit selon la méthode du RGAA, indispensable pour les organisations soumises à l'obligation légale, et utile pour toutes les autres. Elles permettent en revanche d'écarter rapidement un thème inadapté, et de corriger les défauts les plus visibles avant qu'ils ne gênent des visiteurs. Pour connaître les obligations et les documents à publier, voir notre article sur le RGAA et la loi française.
Un dernier test, souvent négligé, consiste à écouter le site avec un lecteur d'écran : VoiceOver est intégré aux appareils Apple, Narrateur à Windows, TalkBack à Android, et NVDA est un lecteur libre pour Windows. Quelques minutes suffisent pour entendre si les titres, les menus et les boutons sont annoncés de façon compréhensible.
Sources
- Make WordPress Themes, Theme Handbook, « Accessibility Required » (consulté le 27 octobre 2026).
- Make WordPress Themes, Theme Handbook, « Required » (consulté le 27 octobre 2026).
- W3C, « What's New in WCAG 2.2 » (consulté le 27 octobre 2026).
AccessibilitéLe RGAA et la loi
106 critères, une déclaration d'accessibilité, un schéma pluriannuel : ce que demande le référentiel français, et à qui.
AccessibilitéWCAG 2.2 : les nouveautés
Focus visible même sous un bandeau, cibles de 24 pixels, pas de casse-tête pour se connecter : ce que les WCAG 2.2 ont ajouté.
AccessibilitéLes contrastes de couleurs
4,5:1, 3:1, grand texte, composants d'interface : les seuils de contraste des WCAG et comment construire une palette qui les respecte.