# Thèmes accessibility-ready sur WordPress.org : ce que garantit le tag

> Le tag accessibility-ready inspire confiance, mais il ne couvre qu'une partie du chemin vers un site réellement accessible. Voici ce qu'il vérifie, et ce qu'il laisse de côté.

- Auteur : Clément Hadrot
- Publié le : 2020-10-05
- Mis à jour le : 2020-10-05
- Catégorie : Accessibilité
- URL : https://wpmoderne.dev.wordpress-developpement.fr/accessibilite/tag-accessibility-ready-themes-wordpress/

## L’essentiel

- Le tag repose sur une revue manuelle de l'équipe thèmes
- Il couvre surtout le HTML du thème, pas le contenu ajouté
- Un thème conforme peut redevenir inaccessible après personnalisation

Dans le répertoire officiel des thèmes WordPress, un filtre permet d'afficher uniquement les thèmes marqués « accessibility-ready ». Ce tag rassure : il laisse penser qu'un choix a été validé une fois pour toutes, qu'il suffit de l'installer pour cocher la case accessibilité d'un projet. La réalité est plus nuancée, et mérite d'être expliquée avant de baser un cahier des charges entier sur ce seul critère.

Ce tag existe depuis 2015, porté par l'équipe Make WordPress Themes, avec une checklist publique consultable sur le Handbook des thèmes. Comprendre ce que cette checklist couvre, et surtout ce qu'elle ne couvre pas, permet d'utiliser ce filtre pour ce qu'il est : un bon point de départ, pas un certificat final.

## Comment un thème obtient le tag

Pour revendiquer le tag `accessibility-ready` dans son fichier `style.css`, un auteur de thème doit soumettre son travail à une revue manuelle réalisée par des bénévoles de l'équipe thèmes, spécifiquement formés sur ce point. Cette revue s'appuie sur une trentaine de critères techniques, allant du contraste des couleurs par défaut à la présence de liens d'évitement, en passant par la gestion du focus clavier sur les menus et la structuration correcte des titres.

La liste précise, maintenue dans le Theme Review Handbook, couvre notamment : un contraste minimum de 4,5:1 pour le texte courant, un lien d'évitement vers le contenu principal, une navigation entièrement utilisable au clavier, l'absence de contenu clignotant sans contrôle utilisateur, et des formulaires de recherche et de commentaires correctement étiquetés.

## Ce que le tag vérifie précisément

| Vérifié par la revue | Non couvert par la revue |
| --- | --- |
| Structure HTML du thème (header, footer, navigation) | Contenu ajouté par l'éditeur du site |
| Contraste des couleurs par défaut du thème | Couleurs modifiées via le Customizer ou une feuille de style enfant |
| Focus clavier visible sur les menus natifs | Comportement des plugins tiers installés ensuite |
| Skip link présent et fonctionnel | Structure des titres du contenu éditorial |
| Formulaires natifs du thème (recherche, commentaires) | Formulaires ajoutés par un plugin de contact |

> L'essentiel à retenir : Le tag repose sur une revue manuelle de l'équipe thèmes ; Il couvre surtout le HTML du thème, pas le contenu ajouté ; Un thème conforme peut redevenir inaccessible après personnalisation

## Un point de départ, pas un aboutissement

Le principal malentendu autour de ce tag concerne son périmètre : il évalue le code du thème tel qu'il est livré, pas le site final tel qu'un client va le construire dessus. Or la majorité des problèmes d'accessibilité rencontrés en production viennent justement de ce qui s'ajoute après l'installation : un carrousel importé via un plugin non testé, des couleurs de charte graphique appliquées sans vérifier leur contraste, des images sans texte alternatif ajoutées dans la médiathèque, ou un formulaire de contact tiers dont les champs ne sont pas correctement liés à leurs étiquettes.

Un thème accessibility-ready peut donc parfaitement aboutir à un site non conforme, sans que le tag ait menti : il a rempli son rôle, qui était de fournir une base saine, pas de garantir le résultat final.

### Les pièges les plus fréquents après installation

- Modifier les couleurs du thème dans le Customizer sans revérifier le contraste
- Ajouter un plugin de galerie ou de carrousel non testé pour l'accessibilité
- Remplacer le menu natif du thème par un mega-menu tiers moins soigné
- Écraser les styles de focus avec du CSS personnalisé, souvent par erreur
- Laisser des balises alt vides sur des images informatives ajoutées après coup

## Comment vérifier soi-même un thème candidat

Avant de retenir un thème sur la seule foi du tag, quelques vérifications rapides permettent de confirmer que la qualité annoncée tient la route en conditions réelles : naviguer sur une page de démonstration entièrement au clavier, passer un contrôleur de contraste sur les couleurs par défaut, et inspecter le code source d'un article pour vérifier la présence d'une hiérarchie de titres logique. Ces tests prennent une vingtaine de minutes et évitent bien des déconvenues.

> Un tag sur une fiche produit n'a jamais remplacé un test réel. Le tag accessibility-ready dit « la base est saine », il ne dit jamais « votre site le sera automatiquement ».

## En résumé

Le filtre accessibility-ready du répertoire WordPress.org reste un excellent réflexe pour démarrer un projet exigeant sur ce plan : il élimine d'entrée les thèmes truffés de mauvaises pratiques structurelles. Mais il ne dispense jamais d'un audit du site final, une fois le contenu, les couleurs de marque et les extensions en place. Traiter ce tag comme un point de départ solide plutôt que comme une certification définitive évite de découvrir, trop tard, qu'un site pourtant construit sur un « bon » thème échoue largement à l'audit RGAA.