L'essentiel à retenir : WCAG 2.2 AA est la norme technique vers laquelle pointe la plupart du droit européen de l'accessibilité, et elle se résume à quatre principes — perceptible, utilisable, compréhensible, robuste — mais en pratique, la plupart des sites WordPress échouent sur un petit ensemble reproductible de problèmes : contraste de couleur, texte alternatif manquant, lacunes de navigation au clavier, et hiérarchie de titres cassée.
Pourquoi cela compte maintenant, pas éventuellement
L'Acte européen sur l'accessibilité (Directive (UE) 2019/882) s'applique depuis le 28 juin 2025, exigeant que des catégories spécifiques de produits et services vendus aux consommateurs de l'UE — e-commerce, banque, livres électroniques, services de transport et télécommunications entre autres — respectent des exigences d'accessibilité. Ce n'est plus une échéance future ; c'est déjà une loi active dans les États membres de l'UE.
L'Acte fait référence à WCAG 2.2 au niveau de conformité AA comme la norme technique pratique que la plupart des organisations utilisent pour démontrer leur conformité, même là où l'EAA lui-même est rédigé dans un langage juridique plus large. Cela fait de WCAG 2.2 AA la cible concrète vers laquelle il vaut la peine de construire, indépendamment du fait qu'un site spécifique relève exactement du champ d'application de l'EAA.
Ce que WCAG 2.2 AA exige réellement
WCAG organise ses exigences autour de quatre principes, communément abrégés POUR (Perceptible, Utilisable, Compréhensible, Robuste) :
- Perceptible — le contenu doit être présentable de manières que les utilisateurs peuvent percevoir, couvrant des choses comme le texte alternatif pour les images et un contraste de couleur suffisant pour le texte.
- Utilisable — les composants d'interface doivent être utilisables uniquement au clavier, pas seulement à la souris, et les utilisateurs ont besoin de suffisamment de temps pour lire et interagir avec le contenu.
- Compréhensible — le contenu et le comportement de l'interface doivent être prévisibles et lisibles, y compris des étiquettes de formulaire claires et une navigation cohérente.
- Robuste — le contenu doit fonctionner de manière fiable à travers les technologies d'assistance comme les lecteurs d'écran, ce qui dépend fortement d'un HTML propre et sémantique et d'une utilisation correcte d'ARIA.
WCAG 2.2 a ajouté neuf nouveaux critères de succès par-dessus 2.1, plusieurs ciblant spécifiquement l'accessibilité mobile et cognitive — une taille minimale de cible pour les éléments cliquables, un placement cohérent des mécanismes d'aide à travers les pages, et des indicateurs de focus visibles plus clairs pour les utilisateurs de clavier.
Les erreurs d'accessibilité WordPress les plus courantes
Nous avons fait tourner un audit d'accessibilité complet axe-core plus Playwright sur ce site — 14 pages en mode sombre et clair — et c'est un échantillon réel utile de l'endroit exact où les sites WordPress ont tendance à échouer, puisque les problèmes trouvés étaient entièrement typiques plutôt que spécifiques au site.
- Contraste de couleur sur les éléments décoratifs. Les étiquettes de catégorie et les badges colorés utilisaient les couleurs hexadécimales de marque brutes directement comme couleur de texte sur des arrière-plans teintés, n'atteignant qu'environ 3,3-4,0:1 — sous le minimum de 4,5:1 pour le texte normal en AA. La correction a été de définir des tokens de couleur "texte-sûrs" séparés et conçus à cet effet plutôt que de réutiliser directement les couleurs de marque comme texte.
- Sauts de hiérarchie de titres. Une page de liste sautait d'un H1 directement à des sections H3 sans H2 entre les deux, ce qui est invisible visuellement mais casse le plan logique du document sur lequel s'appuient les utilisateurs de lecteurs d'écran pour naviguer.
- Liens distingués uniquement par la couleur. Les liens en ligne dans des blocs de texte plus longs étaient colorés différemment du texte environnant mais pas soulignés, ne respectant pas l'exigence que la distinction lien-vs-texte ne dépende pas uniquement de la perception des couleurs.
- Attributs ARIA manquants sur les composants interactifs personnalisés. Un accordéon FAQ personnalisé n'avait ni aria-expanded, ni aria-controls, ni role="region" — fonctionnel pour un utilisateur de souris, mais ambigu pour un utilisateur de lecteur d'écran sans aucun signal sur l'état de l'accordéon.
Aucun de ces problèmes n'a été détecté par un simple coup d'œil à la page — ils sont apparus grâce à une combinaison de scan automatisé et de révision manuelle, le schéma qui vaut la peine d'être reproduit sur tout site WordPress.
Un processus d'audit pratique
| Étape | Outil/Méthode | Détecte |
|---|---|---|
| Scan automatisé | Extension navigateur axe-core ou WAVE | Texte alternatif manquant, échecs de contraste, étiquettes de formulaire manquantes |
| Passage au clavier seul | Naviguer par tabulation sur toute la page sans souris | Ordre de focus cassé, éléments interactifs inatteignables |
| Contrôle ponctuel au lecteur d'écran | VoiceOver (Mac) ou NVDA (Windows) | ARIA ambigu, structure de titres confuse |
| Vérification manuelle du contraste | Outils de développement du navigateur ou un vérificateur de contraste | Problèmes de contraste dans les états que les outils automatisés manquent (survol, focus) |
| Les deux modes de couleur | Répéter tout ce qui précède en mode sombre et clair | Régressions de contraste qui n'apparaissent que dans un seul thème |
Points de friction courants spécifiques à WordPress
- Les réglages par défaut des thèmes et page builders viennent souvent avec des problèmes de contraste ou de structure de titres intégrés aux templates, qui se répètent ensuite sur chaque page utilisant ce template.
- Les widgets ajoutés par des plugins (curseurs, accordéons, onglets) manquent fréquemment d'attributs ARIA appropriés, car tous les auteurs de plugins ne testent pas avec des technologies d'assistance.
- Les images téléversées sans texte alternatif sont l'une des violations les plus courantes et les plus faciles à corriger — vérifier en masse une bibliothèque de médias pour le texte alternatif manquant détecte d'un coup des années de lacunes accumulées. Erdo Image Optimizer inclut un audit intégré qui signale les images sans texte alternatif dans toute une bibliothèque de médias, en plus de l'optimisation de la taille des fichiers que nous couvrons dans notre guide SEO des images.
- Les bannières et modales de consentement aux cookies sont couramment oubliées dans les tests de focus au clavier, car elles sont ajoutées après le chargement de la page principale et sortent facilement de l'ordre de tabulation habituel d'un site.
L'accessibilité est de la maintenance, pas un projet ponctuel
Un audit WCAG corrige ce qui existe au moment où il est exécuté ; chaque nouvel article de blog, chaque nouveau plugin et chaque changement de template est une nouvelle occasion de réintroduire un problème que cet audit avait déjà fermé. Traiter les vérifications d'accessibilité comme faisant partie du workflow régulier de publication et de développement — pas un projet marqué comme terminé une fois — est ce qui maintient un site conforme six mois plus tard, pas seulement le jour du lancement.
Erreurs courantes
- Se fier uniquement à un scanner automatisé, manquant les problèmes manuels de clavier et de lecteur d'écran qu'aucun scanner ne peut juger.
- Corriger le contraste uniquement en mode clair, alors qu'un site avec un basculement en mode sombre doit vérifier les deux indépendamment.
- Supposer qu'un thème ou page builder populaire est accessible par défaut, alors que les problèmes de contraste et de titres au niveau du template se répètent sur chaque page construite à partir de lui.
- Traiter un audit d'accessibilité comme une tâche ponctuelle plutôt qu'une vérification continue appliquée au nouveau contenu et aux nouvelles fonctionnalités à mesure qu'ils sont publiés.
- Oublier le texte alternatif sur les nouveaux téléversements d'images même après qu'un audit en masse a corrigé l'arriéré existant, laissant la lacune se reconstituer silencieusement.
En résumé
En bref, la conformité WCAG 2.2 AA pour un site WordPress se résume à une liste courte et reproductible de points de défaillance réels — contraste de couleur, texte alternatif manquant, navigation au clavier, structure des titres et utilisation d'ARIA sur les composants personnalisés — détectée de manière fiable uniquement par une combinaison de scan automatisé et de tests manuels, et maintenue par une habitude continue plutôt qu'un audit unique. Avec l'Acte européen sur l'accessibilité désormais en vigueur plutôt qu'en attente, le traiter comme une maintenance de routine plutôt qu'une tâche future fait la différence entre un site conforme et un risque juridique.