FR
Deutsch
English
Español
ItalianoEnviron 41,5 % de tous les sites web tournent sur WordPress ; aucun autre système ne s'en approche (W3Techs, juillet 2026). Pour l'accessibilité, c'est une bonne nouvelle : WordPress apporte déjà beaucoup de ce dont une page accessible a besoin, du HTML propre de l'éditeur de blocs au champ de texte alternatif de la médiathèque. Mais il ne garantit rien de tout cela. Qu'un site WordPress soit réellement accessible dépend du thème, des plugins et des habitudes de rédaction. Ce guide passe ces leviers en revue, à jour de 2026 : avec les WCAG 2.2 comme cible, pas la 2.1 d'avant-hier. Savoir où en est votre site prend deux minutes.
Test d'accessibilité web
Analyse votre site WordPress selon les WCAG 2.2 et montre chaque infraction avec son emplacement exact. Un sujet flou devient une liste de travail. Gratuit, sans inscription.
Pourquoi l'accessibilité WordPress a changé en 2026
La plupart des tutoriels d'accessibilité WordPress que vous trouverez aujourd'hui ont été écrits pour les WCAG 2.1. C'était très bien pendant des années, mais c'est dépassé : depuis octobre 2023, les WCAG 2.2 sont la recommandation actuelle du W3C, et la EN 301 549 révisée, la norme européenne derrière le BFSG allemand et la loi européenne sur l'accessibilité, est attendue pour 2026 avec les WCAG 2.2 AA comme référence. Qui remet son site à niveau maintenant a donc intérêt à viser directement la 2.2, sinon la prochaine tournée est déjà programmée. Ce que recouvrent les niveaux A, AA et AAA, notre guide sur la conformité WCAG l'explique.
Le passage de 2.1 à 2.2 n'est pas un recommencement, mais une poignée de nouveaux critères de succès. Six d'entre eux touchent en plein des habitudes typiques de WordPress :
| Critère | Ce qu'il exige | Où WordPress pèche typiquement |
|---|---|---|
| 2.4.11 Focus non masqué | L'élément qui a le focus ne doit pas être entièrement recouvert par d'autres contenus | En-têtes fixes et bandeaux cookies qui recouvrent le focus clavier |
| 2.5.7 Mouvements de glissement | Toute interaction par glisser exige une alternative sans glisser | Sliders et carrousels qui ne réagissent qu'au balayage ou au glisser |
| 2.5.8 Taille de cible (minimum) | Des commandes d'au moins 24x24 pixels CSS, ou assez d'espace autour | Icônes sociales, points de pagination et minuscules boutons de fermeture |
| 3.2.6 Aide cohérente | Les aides comme le contact ou le chat au même endroit sur chaque page | Un lien contact tantôt dans l'en-tête, tantôt dans le pied de page selon le gabarit |
| 3.3.7 Saisie redondante | Ne pas redemander dans le même parcours des données déjà saisies | Un paiement qui fait retaper l'adresse de facturation comme adresse de livraison |
| 3.3.8 Authentification accessible | Connexion sans casse-tête cognitif comme recopier des caractères déformés | Plugins de captcha sur les formulaires de connexion et de commentaire |
Ce qui frappe dans cette liste : l'essentiel se joue dans le thème ou les plugins, pas dans vos textes. Vous en restez pourtant responsable. Un scan mesure votre site, pas les bonnes intentions du développeur de votre thème. Après chaque mise à jour importante, vérifiez donc si un plugin n'a pas réintroduit discrètement l'un de ces travers.
Le cadre juridique en trois phrases
Si votre site WordPress ne fait qu'informer, le droit de l'accessibilité vous laisse dans la plupart des cas tranquille pour l'instant ; corriger les barrières reste payant, car chaque barrière coûte des visiteurs. Dès qu'on peut acheter, réserver ou souscrire sur le site, typiquement via WooCommerce ou un plugin de réservation, la loi européenne sur l'accessibilité s'applique dans toute l'UE, et pour la vente aux consommateurs allemands sa transposition locale activement contrôlée, le BFSG, avec inspections et amendes à la clé. Qui est couvert exactement et quelles exceptions jouent vraiment, notre guide sur le BFSG allemand le détaille.
WooCommerce veut dire : vous exploitez une boutique en ligne
Avec WooCommerce ou un plugin de réservation, votre site WordPress devient juridiquement un service de commerce électronique, avec toutes les obligations qui suivent, du paiement à la déclaration d'accessibilité. Les détails pour les boutiques qui vendent vers l'Allemagne, de l'exception microentreprise au piège du B2B, sont rassemblés dans notre guide BFSG pour boutiques en ligne.
Le socle : un thème qui ne travaille pas contre vous
Dans WordPress, l'accessibilité commence avant le premier contenu, avec le choix du thème. Le thème fixe les contrastes de couleurs, l'affichage du focus, les liens d'évitement et la structure HTML dont hérite chaque page. Un bon point de départ est le répertoire officiel des thèmes filtré par le tag accessibility-ready : une centaine de thèmes qui ont passé une revue selon des standards minimaux définis, plutôt que des dizaines de milliers jamais vérifiés.
accessibility-ready signifie vérifié, pas terminé
Le tag garantit des standards minimaux, pas une conformité WCAG complète. Et il ne répare rien de ce qui vient après : un seul plugin aux boutons sans étiquette, ou une séance de personnalisation finissant en couleurs pâles, sape aussitôt le socle vérifié. Traitez ce tag comme un ticket d'entrée, pas comme un diplôme.
Les thèmes premium hors répertoire ne portent pas ce tag. Trois tests rapides dans la démo aident alors avant l'achat : les couleurs par défaut sont-elles assez contrastées ? En parcourant la page à la touche Tab, voit-on toujours où se trouve le focus ? Et le premier arrêt de tabulation propose-t-il un lien d'évitement direct vers le contenu ? Dix minutes de test sur la démo épargnent des semaines de rafistolage en production.
Les huit chantiers du quotidien WordPress
Le thème posé, c'est le travail quotidien dans l'éditeur qui décide si le site reste accessible. Ces huit points couvrent l'essentiel de ce qui déraille régulièrement sur les sites WordPress :
- Vérifier la base du thème : contrastes, focus visible, lien d'évitement (voir plus haut). Qui économise ici lutte ensuite contre son propre socle à chaque point suivant.
- Traiter les titres comme une structure : dans l'éditeur de blocs, un H2 est un niveau de plan, pas une taille de police. Ne sautez pas de niveaux et ne choisissez pas un H4 parce qu'il est plus joli.
- Soigner les textes alternatifs dans la médiathèque : chaque image informative reçoit un texte alternatif ; les images purement décoratives restent volontairement vides pour que les lecteurs d'écran les sautent.
- Choisir des plugins de formulaire avec de vraies étiquettes : un texte indicatif dans le champ n'est pas une étiquette. L'étiquette doit être liée programmatiquement au champ et ne pas disparaître à la saisie.
- Contrôler les contrastes après chaque changement de couleur : le gris délicat sur fond blanc, si élégant dans l'outil de personnalisation, est la première chose qu'un scan signale.
- Prévoir un test clavier : parcourez vos pages principales à la touche Tab. Chaque menu, bouton et champ est-il atteignable, et peut-on ressortir de partout ?
- Vérifier le lien d'évitement : le premier arrêt de tabulation devrait être un lien direct vers le contenu. Les thèmes accessibility-ready l'apportent, beaucoup d'autres non.
- Éviter les sliders automatiques ou les rendre pausables : un carrousel qui défile tout seul exige au moins une commande de pause. Souvent, la meilleure solution est de le supprimer purement et simplement.
En pratique, le plus gros poste, ce sont presque toujours les textes alternatifs. WordPress rend l'oubli facile : le champ de la médiathèque est discret, et la page semble parfaite sans lui. Pour un utilisateur de lecteur d'écran, un texte alternatif manquant signifie : il y a une image ici, et personne ne dit ce qu'elle montre. À quoi ressemble un bon texte alternatif, le tutoriel images du W3C le décrit ; face à des centaines d'images existantes, un générateur vaut la peine pour le premier jet.
Générateur de texte alternatif
Trouve les images sans texte alternatif et propose des formulations en brouillon. Vous vérifiez chaque texte contre le contexte de la page, ajustez et validez.
Plugins : ce qui aide vraiment et ce qui rassure seulement
Les plugins utiles vérifient pendant que vous rédigez : ils signalent dans l'éditeur les textes alternatifs manquants ou les niveaux de titre sautés avant la mise en ligne. Ces assistants déplacent le contrôle qualité au bon endroit, avant la publication. Ce qui n'existe pas, c'est le plugin qui rend un site conforme automatiquement. La conformité naît du thème, des contenus et des routines, et aucun de ces trois ingrédients ne s'installe.
Soyez particulièrement sceptique face aux plugins overlay qui injectent un panneau de réglages par script et promettent l'accessibilité en un clic. Ils peuvent offrir aux visiteurs un confort d'affichage, rien de plus : formulaires sans étiquettes, parcours clavier cassés et textes alternatifs manquants subsistent tels quels en dessous. Pourquoi c'est techniquement inévitable, et comment experts et autorités jugent les overlays, notre guide sur les overlays d'accessibilité le montre.
Tester : d'abord en automatique, puis à la main
Un scan automatique est le bon point de départ, parce qu'il trouve les infractions détectables à la machine de façon fiable et répétable : contrastes trop faibles, textes alternatifs manquants, champs sans étiquette. Ce sont aussi les erreurs que n'importe qui d'autre voit en premier en pointant un outil sur votre site. Mais le scan n'est pas la fin : savoir si un texte alternatif convient vraiment, ou si le menu devient un piège au clavier, seul un humain le peut.
- À la touche Tab, parcourir la page d'accueil, une page de contenu et votre formulaire principal : tout est atteignable, le focus toujours visible ?
- Lien d'évitement : le premier arrêt de tabulation mène-t-il vraiment au contenu ?
- Sliders et animations : peut-on les mettre en pause, et tout fonctionne-t-il sans glisser ?
- Sondage sur cinq images : le texte alternatif dit-il ce que l'image apporte à cet endroit précis ?
- Envoyer un formulaire avec des erreurs volontaires : l'erreur est-elle expliquée en texte, et pas seulement colorée en rouge ?
Pour les questions de couleurs, pas besoin d'intuition. Le contraste est une valeur mesurable avec des seuils clairs, et la vérification prend quelques secondes.
Vérificateur de contraste
Vérifie en quelques secondes si vos combinaisons de couleurs respectent les seuils WCAG. Idéal après chaque retouche de couleurs du thème.
Questions fréquentes sur l'accessibilité de WordPress
Un thème avec le tag accessibility-ready est-il automatiquement accessible ?
Non. Le tag confirme que le thème a passé une revue selon des standards minimaux définis, pas une conformité WCAG complète. C'est la meilleure position de départ qu'offre le répertoire de thèmes, mais il ne remplace ni des contenus entretenus ni des plugins contrôlés. Un thème accessibility-ready plus des textes alternatifs manquants donne quand même un site avec des barrières.
Existe-t-il un plugin qui rend mon site accessible ?
Non, et méfiez-vous de quiconque promet exactement cela. Les plugins peuvent aider à vérifier, par exemple avec des alertes dans l'éditeur avant publication. La conformité elle-même naît du thème, des contenus et des méthodes de travail. Les plugins overlay aux promesses en un clic ne changent rien aux défauts sous-jacents ; les preuves sont réunies dans notre guide sur les overlays.
Mon site respecte les WCAG 2.1 AA. Dois-je passer à la 2.2 ?
Vous êtes bien placé, mais pas arrivé. Les WCAG 2.2 sont la recommandation actuelle du W3C depuis octobre 2023, et la EN 301 549 révisée se référant à la 2.2 AA est attendue pour 2026. Les nouveaux critères, comme la taille de cible minimale et le focus non masqué, restent gérables. Les prévoir maintenant vous épargne une seconde tournée de travaux.
Le BFSG allemand s'applique-t-il à mon site WordPress ?
Seulement si le site propose un service couvert, avant tout la vente ou la réservation à des consommateurs, par exemple via WooCommerce, et seulement si vous visez le marché allemand. Un pur site d'information sans boutique ni réservation reste en général en dehors. Les critères exacts, exception microentreprise comprise, sont dans notre guide BFSG ; la pratique boutique, dans le guide dédié.
Chaque image a-t-elle vraiment besoin d'un texte alternatif ?
Chaque image informative oui, les décoratives justement pas : elles reçoivent un attribut alt vide pour que les lecteurs d'écran les sautent. La règle simple : en retirant l'image, perdrait-on de l'information ? Alors le texte alternatif transmet exactement cette information, court et dans le contexte de la page où elle se trouve.
Un scan automatique suffit-il pour être tranquille ?
Non. Le scan trouve de façon fiable les infractions mesurables à la machine, celles que les outils de test tiers repèrent aussi en premier. Vérifier que les textes alternatifs ont du sens, que le clavier fonctionne de bout en bout et que les parcours restent compréhensibles, cela se fait à la main en complément. La combinaison des deux est la voie réaliste.
WordPress ne s'oppose pas à l'accessibilité ; il attend juste des instructions. Le champ de texte alternatif existe, les niveaux de titre existent, les thèmes vérifiés existent. Ce qui manque le plus souvent, c'est la vue d'ensemble des endroits où votre site pèche concrètement. C'est exactement ce que livre le scan du début de cet article : deux minutes, une liste de travail priorisée, et une vague intention devient un projet avec une fin.
Avertissement juridique
Cet article a une vocation purement informative et ne constitue pas un conseil juridique. Pour une réponse fiable à votre cas particulier, adressez-vous à un avocat. Mise à jour : juillet 2026.
Auteur
Redaktion accessibility-check.ai