Un thème WordPress magnifique qui ignore l’accessibilité n’est, au fond, qu’un thème à moitié terminé. Chaque semaine, en auditant des thèmes pour des clients, je retrouve les mêmes erreurs : un contraste de texte insuffisant sur les boutons, un focus clavier invisible, des menus impossibles à parcourir au tabulateur. Ce ne sont pas des détails cosmétiques, ce sont des barrières concrètes pour une partie non négligeable des visiteurs.
Dans ce guide, je vous propose une checklist pratique, celle que j’utilise moi-même avant de livrer un thème à un client. Elle couvre les points vérifiés par le répertoire officiel des thèmes WordPress pour attribuer le tag accessibility-ready, et quelques bonnes pratiques supplémentaires issues du terrain.
Pourquoi l’accessibilité n’est pas une option
WordPress propulse une part considérable du web francophone, et un thème mal conçu peut exclure des utilisateurs malvoyants, des personnes qui naviguent uniquement au clavier, ou des utilisateurs de lecteurs d’écran comme NVDA ou JAWS. Au-delà de l’aspect éthique, il y a un enjeu très concret : un site public ou administratif peut être soumis au RGAA en France, et un thème inaccessible complique fortement la mise en conformité.
Le contraste des couleurs, première source d’erreurs
C’est de loin le problème que je rencontre le plus souvent. Un texte gris clair sur fond blanc, un bouton dont le libellé se fond presque dans sa couleur de fond : ces choix esthétiques cassent la lisibilité pour de nombreux visiteurs, pas seulement les malvoyants.
Les WCAG 2.1, niveau AA, exigent un ratio de contraste d’au moins 4.5:1 pour le texte courant et 3:1 pour le texte de grande taille (18pt ou 14pt en gras). Je vérifie systématiquement mes palettes avec un outil de contraste avant de les injecter dans style.css ou dans le customizer.
- Texte principal sur fond clair : viser un ratio supérieur à 7:1 quand c’est possible
- Liens : ne jamais s’appuyer uniquement sur la couleur pour les distinguer du texte
- États
:hoveret:focus: vérifier le contraste, pas seulement l’état par défaut
Navigation clavier et focus visible
Beaucoup d’utilisateurs naviguent exclusivement au clavier, que ce soit par choix, par handicap moteur, ou simplement parce qu’ils utilisent un lecteur d’écran qui s’appuie sur la tabulation. Un thème accessible doit permettre d’atteindre chaque lien, chaque bouton, chaque champ de formulaire avec la touche Tab, dans un ordre logique.
L’erreur classique consiste à supprimer l’indicateur de focus natif du navigateur avec outline: none; sans le remplacer par quelque chose d’équivalent. Voici ce que je mets systématiquement dans mes feuilles de style :
a:focus,
button:focus,
input:focus,
.menu-item a:focus {
outline: 2px solid #2271b1;
outline-offset: 2px;
}
Le menu de navigation mérite une attention particulière : les sous-menus doivent pouvoir s’ouvrir et se fermer au clavier, pas uniquement au survol de la souris. C’est souvent là que les thèmes premium échouent, malgré un rendu visuel irréprochable.
Les skip links, un vieux réflexe toujours utile
Un skip link (lien d’évitement) permet à un utilisateur clavier ou lecteur d’écran de sauter directement au contenu principal, sans devoir traverser tout le menu de navigation à chaque page. WordPress core en inclut un par défaut dans les thèmes générés par _s (Underscores), et c’est une pratique que je recommande de conserver, même dans un thème très moderne.
<a class="skip-link screen-reader-text" href="#content">
Aller au contenu principal
</a>
La classe screen-reader-text masque visuellement le lien tout en le gardant accessible, et il redevient visible au focus clavier grâce à quelques règles CSS ciblées sur :focus.
Balises sémantiques HTML5 et landmarks ARIA
Structurer un thème avec des balises sémantiques (header, nav, main, article, footer) donne gratuitement des points de repère aux technologies d’assistance. Ces balises créent des landmarks que les lecteurs d’écran permettent de parcourir directement, sans lire tout le contenu séquentiellement.
Quand la sémantique HTML5 ne suffit pas, les attributs ARIA viennent compléter :
role="navigation"etaria-labelpour distinguer plusieurs menus sur une même pagearia-expandedsur les boutons qui ouvrent un sous-menu ou un panneauaria-hidden="true"pour masquer aux lecteurs d’écran des éléments purement décoratifs
Mon conseil : testez votre thème au clavier seul, sans souris, pendant dix minutes avant chaque livraison. C’est le test le plus rapide et le plus révélateur des vrais problèmes d’accessibilité, bien avant n’importe quel audit automatisé.
Obtenir le tag accessibility-ready
Le répertoire officiel des thèmes WordPress propose un tag accessibility-ready attribué après revue manuelle par l’équipe d’accessibilité. Les critères couvrent notamment :
- Skip links fonctionnels vers le contenu principal
- Focus clavier visible sur tous les éléments interactifs
- Titres de page correctement structurés (
h1àh6) sans saut de niveau - Formulaires avec des
labelassociés à chaque champ - Contraste suffisant pour le texte et les éléments d’interface
Obtenir ce tag n’est pas obligatoire, mais viser ces critères, même pour un thème vendu en dehors du répertoire, garantit une base solide et rassure des clients de plus en plus sensibilisés au sujet, notamment dans le secteur public.
En résumé
L’accessibilité d’un thème WordPress se joue sur des détails techniques précis : contraste mesurable, focus visible, structure sémantique, navigation clavier complète. Aucun de ces points n’est complexe à implémenter isolément, mais leur addition demande de la rigueur et des tests réguliers, idéalement au clavier et avec un lecteur d’écran. C’est un investissement qui profite à tous les visiteurs, pas seulement à ceux qui utilisent une technologie d’assistance.
