L’accessibilité web est l’un des sujets où l’intention et la réalité divergent le plus. La majorité des propriétaires de sites WordPress savent que l’accessibilité est importante — pour les personnes en situation de handicap, pour la conformité légale au RGAA, et accessoirement pour le référencement naturel. Mais entre savoir que c’est important et savoir exactement quoi corriger sur son site, il y a un fossé que la plupart ne franchissent jamais.
Ce guide n’est pas un cours théorique sur les normes WCAG 2.1. C’est une liste des 10 erreurs d’accessibilité les plus fréquemment rencontrées sur les sites WordPress — avec pour chacune une explication claire de ce qui pose problème, qui est impacté, et comment corriger concrètement.
Chiffre clé : selon WebAIM, l’organisation qui analyse chaque année les 1 million de pages d’accueil les plus visitées, 96,3 % des pages présentent des erreurs d’accessibilité détectables automatiquement. Et les six types d’erreurs les plus fréquents — faible contraste, images sans texte alternatif, liens sans intitulé, champs de formulaire sans label, langue non déclarée, boutons vides — représentent à eux seuls 96 % de toutes les erreurs détectées. Ce sont précisément ces erreurs que ce guide adresse.
Erreur 1 — Images sans texte alternatif (ou avec un alt inutile)
C’est l’erreur numéro un selon WebAIM — présente sur 55,4 % des pages analysées. Sur WordPress, elle est particulièrement fréquente parce que la médiathèque ne force pas la saisie du texte alternatif.
Ce qui pose problème : les personnes malvoyantes utilisent des lecteurs d’écran (NVDA, JAWS, VoiceOver) qui lisent le contenu de la page à voix haute. Quand une image n’a pas d’attribut alt, le lecteur d’écran lit soit rien, soit le nom du fichier (« IMG_20240315_142300.jpg ») — ce qui n’apporte aucune information.
Les deux erreurs opposées :
- Image sans
altdu tout : le lecteur d’écran ignore l’image ou lit le nom du fichier - Image avec
alt="image"oualt="photo": le texte alternatif existe mais n’apporte aucune information
La correction sur WordPress : dans la médiathèque (Médias > Bibliothèque), renseignez le champ « Texte alternatif » pour chaque image porteuse d’information avec une description précise de son contenu. Pour les images purement décoratives, laissez l’attribut alt vide (alt="") — cela signale au lecteur d’écran de les ignorer.
Outil de vérification : l’extension Chrome WAVE affiche visuellement les images sans alt et les alt vides sur n’importe quelle page.
Erreur 2 — Contraste insuffisant entre le texte et le fond
Deuxième erreur la plus fréquente selon WebAIM — présente sur 81 % des pages analysées. Les designs modernes avec leurs textes gris clair sur fond blanc, leurs placeholders pâles dans les formulaires et leurs boutons aux couleurs pastel sont particulièrement concernés.
Ce qui pose problème : les personnes malvoyantes, daltonniennes ou qui utilisent leur téléphone en plein soleil ne peuvent pas lire un texte dont le contraste avec le fond est insuffisant. Le RGAA et les WCAG 2.1 exigent un ratio de contraste minimum de 4,5:1 pour le texte normal et de 3:1 pour le texte de grande taille (18px et plus en gras, ou 24px et plus).
Les cas les plus fréquents sur WordPress :
- Texte gris clair sur fond blanc (
#999999sur#FFFFFF= ratio 2,85:1 — non conforme) - Placeholder des champs de formulaire en gris très clair
- Boutons CTA avec texte blanc sur fond jaune ou orange clair
- Texte superposé à une image sans overlay suffisant
La correction : utilisez le Colour Contrast Checker de WebAIM pour tester chaque combinaison couleur/fond. Sur WordPress, modifiez les couleurs dans les réglages du thème ou via CSS personnalisé. Pour les thèmes Gutenberg, utilisez l’éditeur de site (Apparence > Éditeur) pour ajuster les palettes de couleurs globales.
Erreur 3 — Liens sans intitulé explicite
Ce qui pose problème : les utilisateurs de lecteurs d’écran naviguent souvent de lien en lien via la touche Tab pour explorer une page rapidement. Un lien intitulé « Cliquez ici », « En savoir plus » ou « Lire la suite » ne leur dit rien sur la destination. Quand une page contient cinq liens « En savoir plus », le lecteur d’écran liste cinq fois « En savoir plus » — sans aucun contexte.
Les cas fréquents sur WordPress :
- Boutons « Lire la suite » sur les archives de blog — générés automatiquement par WordPress sans contexte
- Liens « Ici » dans le corps du texte (« cliquez ici pour télécharger »)
- Icônes sociales sans texte visible ni attribut
aria-label - Images cliquables sans texte alternatif (l’image joue le rôle d’intitulé de lien)
La correction : reformulez les intitulés de liens pour qu’ils soient explicites hors contexte. « Lire la suite » devient « Lire la suite de l’article sur l’accessibilité WordPress ». Pour les icônes sans texte visible, ajoutez un attribut aria-label descriptif : <a href="..." aria-label="Notre page Facebook">.
Sur WordPress, le texte « Lire la suite » des archives peut être modifié dans Réglages > Lecture > « Texte à afficher pour le lien Lire la suite » (selon le thème) ou via un filtre dans functions.php.
Erreur 4 — Champs de formulaire sans label associé
Ce qui pose problème : un champ de formulaire sans <label> associé est inexploitable pour un utilisateur de lecteur d’écran — il ne sait pas ce qu’il doit saisir. Un placeholder en guise de label est insuffisant : il disparaît dès que l’utilisateur commence à taper, et les lecteurs d’écran ne lisent pas systématiquement les placeholders.
Les cas fréquents sur WordPress :
- Formulaires créés avec des constructeurs de pages qui génèrent des inputs sans labels
- Champs avec placeholder uniquement et sans label visible
- Formulaires de recherche sans label (« Rechercher » comme placeholder mais pas comme label)
La correction : sur WordPress, utilisez WPForms ou Gravity Forms qui génèrent nativement des labels correctement associés aux champs. Vérifiez que chaque <input> a soit un <label for="id-du-champ"> associé, soit un attribut aria-label si le label visible n’est pas souhaitable.
| Élément | Accessible | Non accessible |
|---|---|---|
| Label visible | <label for="email">Email</label><input id="email"> | <input placeholder="Email"> |
| Label caché | <input aria-label="Rechercher"> | <input placeholder="Rechercher"> |
| Icône seule | <button aria-label="Fermer">×</button> | <button>×</button> |
Erreur 5 — Absence de langue déclarée dans le HTML
Ce qui pose problème : les lecteurs d’écran utilisent la langue déclarée dans la balise <html> pour adapter la prononciation et la synthèse vocale. Sans déclaration de langue (lang="fr"), le lecteur d’écran utilise sa langue par défaut — et une page française lue avec la prononciation anglaise est incompréhensible.
La correction sur WordPress : WordPress gère normalement la langue automatiquement via les réglages (Réglages > Général > Langue du site). Vérifiez que votre thème inclut bien l’attribut lang dans la balise <html> en inspectant le code source de votre page (clic droit > Afficher le code source, chercher <html lang=). Si le thème ne l’inclut pas, ajoutez ce filtre dans functions.php :
add_filter('language_attributes', function($output) {
return 'lang="fr"';
});Pour les pages avec du contenu multilingue, utilisez l’attribut lang sur les éléments contenant du texte dans une autre langue : <span lang="en">Hello</span>.
Erreur 6 — Structure de titres incohérente ou absente
Ce qui pose problème : les utilisateurs de lecteurs d’écran naviguent dans une page en sautant de titre en titre (H1, H2, H3) pour comprendre la structure et accéder directement au contenu qui les intéresse — comme une table des matières. Une structure de titres incohérente (deux H1, un H3 qui suit directement un H1 sans H2 intermédiaire, ou absence totale de titres) rend cette navigation impossible.
Les erreurs fréquentes sur WordPress :
- Deux balises H1 sur la même page (titre de la page + titre du thème dans le header)
- Titres choisis pour leur apparence visuelle plutôt que leur niveau hiérarchique
- Texte mis en gras utilisé comme titre sans balise Hn
- Pages de constructeurs de pages avec une hiérarchie de titres cassée
La correction : auditez la structure de titres de chaque page avec l’extension HeadingsMap pour Chrome — elle affiche la hiérarchie complète des titres d’une page. Sur WordPress avec Gutenberg, utilisez le bloc « Titre » avec le niveau approprié, pas celui qui vous donne visuellement la taille souhaitée.
Erreur 7 — Navigation non accessible au clavier
Ce qui pose problème : les utilisateurs qui ne peuvent pas utiliser une souris (handicap moteur, utilisateurs avancés, personnes utilisant un interrupteur) naviguent exclusivement au clavier via la touche Tab. Si votre menu hamburger ne s’ouvre pas au clavier, si un modal ne peut pas être fermé avec Échap, ou si le focus clavier disparaît visuellement, ces utilisateurs sont bloqués.
Les cas fréquents sur WordPress :
- Menus déroulants qui ne fonctionnent qu’au survol de souris
- Modales et pop-ups qui piègent le focus ou ne peuvent pas être fermées au clavier
- Sliders et carrousels sans contrôles accessibles au clavier
- Ordre de tabulation illogique (Tab saute d’un élément à un autre de façon imprévisible)
La correction : testez votre site entièrement au clavier — naviguez uniquement avec Tab (avancer), Maj+Tab (reculer), Entrée (activer), Espace (activer les boutons) et Échap (fermer). Vérifiez que le focus visuel est toujours visible (outline) — ne supprimez jamais outline: none dans votre CSS sans proposer un style de focus personnalisé.
Erreur 8 — Vidéos sans sous-titres ni transcription
Ce qui pose problème : les personnes sourdes ou malentendantes ne peuvent pas accéder au contenu audio d’une vidéo sans sous-titres. Les personnes avec des troubles cognitifs bénéficient d’une transcription textuelle. Le RGAA impose des sous-titres synchronisés pour toute vidéo avec du contenu audio informatif.
La correction sur WordPress : pour les vidéos hébergées sur YouTube, activez les sous-titres automatiques (puis corrigez-les) dans l’interface YouTube Studio — ils sont intégrés automatiquement quand vous embarquez la vidéo. Pour les vidéos auto-hébergées, utilisez la balise HTML5 <track> avec un fichier de sous-titres au format VTT. Proposez toujours une transcription textuelle complète sous chaque vidéo informative.
Erreur 9 — Contenu qui bouge ou clignote sans contrôle
Ce qui pose problème : les animations automatiques, les contenus qui défilent et les éléments qui clignotent peuvent provoquer des crises d’épilepsie chez les personnes photosensibles (tout contenu clignotant plus de 3 fois par seconde est interdit par le RGAA) et distraire considérablement les personnes avec des troubles de l’attention (TDAH, autisme).
Les cas fréquents sur WordPress :
- Sliders qui défilent automatiquement sans possibilité de pause
- Animations CSS ou JavaScript qui jouent en boucle
- GIFs animés sans option d’arrêt
- Bannières promotionnelles clignotantes
La correction : tout contenu animé qui démarre automatiquement et dure plus de 5 secondes doit avoir un mécanisme de pause, d’arrêt ou de masquage. Utilisez la media query CSS @media (prefers-reduced-motion: reduce) pour désactiver les animations pour les utilisateurs qui ont activé l’option « Réduire les animations » dans leur système d’exploitation.
Erreur 10 — Documents PDF non accessibles
Ce qui pose problème : les PDF téléchargeables depuis votre site WordPress (guides, plaquettes, formulaires) sont souvent générés depuis Word ou InDesign sans configuration d’accessibilité — ils ne sont pas structurés pour les lecteurs d’écran et ne peuvent pas être lus correctement.
La correction : pour les nouveaux PDF, exportez depuis Word en activant l’option « Document structuré pour l’accessibilité » (Fichier > Exporter > Créer un PDF/XPS > Options > Balises de structure de document pour l’accessibilité). Vérifiez le résultat avec Adobe Acrobat Pro (Outils > Accessibilité > Vérification complète). Pour les PDF existants non corrigibles, proposez une alternative HTML de même contenu sur votre site WordPress — c’est souvent plus rapide que de corriger le PDF.
Récapitulatif : les 10 erreurs et leur niveau de correction
| Erreur | Impact utilisateur | Difficulté de correction | Priorité |
|---|---|---|---|
| Images sans alt | Très élevé (malvoyants) | Faible | Critique |
| Contraste insuffisant | Élevé (malvoyants, daltoniens) | Faible à moyenne | Critique |
| Liens sans intitulé | Élevé (lecteurs d’écran) | Faible | Élevée |
| Formulaires sans label | Très élevé (lecteurs d’écran) | Faible (WPForms) | Critique |
| Langue non déclarée | Élevé (lecteurs d’écran) | Très faible | Élevée |
| Structure titres cassée | Moyen (navigation clavier) | Moyenne | Élevée |
| Navigation clavier bloquée | Très élevé (handicap moteur) | Élevée | Critique |
| Vidéos sans sous-titres | Élevé (malentendants) | Moyenne | Élevée |
| Contenu animé sans pause | Moyen à élevé (épilepsie, TDAH) | Faible | Moyenne |
| PDF non accessibles | Moyen (lecteurs d’écran) | Élevée | Moyenne |
FAQ — Accessibilité WordPress : les vraies questions
Commencez par trois outils gratuits et complémentaires. L'extension Chrome WAVE analyse n'importe quelle page et affiche visuellement les erreurs directement sur la page — images sans alt, contraste insuffisant, labels manquants. L'extension axe DevTools intégrée dans les outils de développement Chrome identifie les violations WCAG avec des explications et des suggestions de correction. Et testez votre site entièrement au clavier (Tab, Maj+Tab, Entrée, Espace, Échap) pour identifier les blocages de navigation. Ces trois approches révèlent 70 à 80 % des erreurs d'accessibilité les plus impactantes sans nécessiter de formation spécialisée. Pour un audit complet conforme au RGAA, une intervention humaine professionnelle reste nécessaire sur les critères non automatisables.
Non — et c'est un malentendu fréquent. Un thème accessible fournit une base technique correcte : structure HTML sémantique, navigation clavier fonctionnelle, styles de focus visibles, déclaration de langue. Mais il ne peut pas contrôler le contenu que vous publiez — les textes alternatifs de vos images, les intitulés de vos liens, la hiérarchie de vos titres ou l'accessibilité de vos vidéos dépendent de vos choix éditoriaux, pas du thème. L'accessibilité est une responsabilité partagée entre le thème (technique), les plugins (composants) et l'éditeur (contenu). Des thèmes comme GeneratePress ou Kadence offrent une excellente base technique — le reste dépend de vous.
Ces widgets d'accessibilité ajoutent une barre d'outils qui permet aux utilisateurs d'ajuster l'affichage — augmenter le contraste, agrandir le texte, activer un mode lecture. Ils améliorent l'expérience pour certains profils d'utilisateurs et peuvent être utiles comme complément. Mais ils ne rendent pas un site conforme au RGAA ou aux WCAG 2.1 — les associations de personnes handicapées, notamment la NFB aux États-Unis, ont publiquement dénoncé ces outils comme insuffisants et parfois contre-productifs. La conformité RGAA nécessite des corrections dans le code et le contenu — pas une surcouche JavaScript qui tente de compenser des erreurs structurelles.
